核心内容摘要
Spring Boot接口调试效率跃迁指南：Cool Request插件场景化应用
前言之前面试经常被问到 CSRF 跨站请求伪造大概流程比较简单 大概就是用户登录了A页面存下来登录凭证cookie 攻击者有诱导受害者打开了B页面 B页面中正好像A发送了一个跨域请求并把cookie进行了携带 欺骗浏览器以为是用户的行为进而达到执行危险行为的目的完成攻击上面就是面试时我们通常的回答 但是到底是不是真是这样呢? 难道这么容易伪造吗于是我就打算试一下能不能实现
实现接下来我们就通过node起两个服务 A服务端口3000和B服务端口4000 然后通过两个页面 A页面、和B页面模拟一下CSRF。
我们先约定一下 B页面是正常的页面 起一个 4000 的服务 然后 A页面为伪造者的网站 服务为3000先看B页面的代码, B页面有一个登录和一个获取数据的按钮 模拟正常网站需要登录后才可以获取数据body div 正常 页面 B button onclicklogin()登录/button button onclickgetList()拿数据/button ul classbox/ul div classtip/div /div /body script async function login() { const response await fetch(http://localhost:4000/login, { method: POST, }); const res await response.json(); console.log(res, writeCookie); if (res.data success) { document.querySelector(.tip).innerHTML 登录成功 可以拿数据; } } async function getList() { const response await fetch(http://localhost:4000/list, { method: GET, }); if (response.status
{ document.querySelector(.tip).innerHTML cookie失效请先登录; document.querySelector(.box).innerHTML ; } else { document.querySelector(.tip).innerHTML ; const data await response.json(); let html ; data.map((el) { html div${el.id} - ${el.name}/div; }); document.querySelector(.box).innerHTML html; } } /script在看B页面的服务端代码如下const express require(express); const app express(); app.use(express.json()); // json app.use(express.urlencoded({ extends: true })); // x-www-form-urlencoded app.use((req, res, next) { res.header(Access-Control-Allow-Origin, *); // 允许客户端跨域传递的请求头 res.header(Access-Control-Allow-Headers, Content-Type); next(); }); app.use(express.static(public)); app.get(/list, (req, res) { const cookie req.headers.cookie; if (cookie ! userallow) { res.sendStatus(
; } else { res.json([ { id: 1, name: zhangsan }, { id: 2, name: lisi }, ]); } }); app.post(/login, (req, res) { res.cookie(user, allow, { expires: new Date(Date.now() 86400 *
, }); res.send({ data: success }); }); app.post(/delete, (req, res) { const cookie req.headers.cookie; if (req.headers.referer ! req.headers.host) { console.log(should ban!); } if (cookie ! userallow) { res.sendStatus(
; } else { res.json({ data: delete success, }); } }); app.listen(4000, () { console.log(sever
; });B 服务有三个接口 登录、获取列表、删除。
再触发登录接口的时候会像浏览器写入cookie 再删除或者获取列表的时候都先检测有没有将指定的cookie传回如果有就认为有权限然后我们打开http://localhost:4000/B.html先看看B页面功能是否都正常我们看到此时 B 页面功能和接口都是正常的 cookie 也正常进行了设置每次获取数据的时候都是会携带cookie到服务端校验的那么接下来我们就通过A页面起一个3000端口的服务来模拟一下跨域情况下能否完成获取 B服务器数据调用 B 服务器删除接口的功能A页面代码body div 伪造者页面 A form actionhttp://localhost:4000/delete methodPOST input typehidden nameaccount valuexiaoming / /form script // 这行可以放到控制台执行便于观察效果 // document.forms[0].submit(); /script /div ul classbox/ul div classtip/div /bodyA页面服务端代码body div 伪造者页面 A form actionhttp://localhost:4000/delete methodPOST input typehidden nameaccount valuexiaoming / /form script // 这行可以放到控制台输入 // document.forms[0].submit(); /script script srchttp://localhost:4000/list/script /div /body于是在我们 访问http://localhost:3000/A.html页面的时候发现 发现list列表确实请求到了 控制台输入document.forms[0].submit()时发现确实删除也发送成功了 是不是说明csrf就成功了呢 但是其实还不是 关键的一点是 我们在B页面设置cookie的时候 domain设置的是localhost那么其实在A页面 发送请求的时候cookie是共享的状态 真实情况下肯定不会是这样 那么为了模拟真实情况 我们把http://localhost:3000/A.html改为http://
127.
0.
1:3000/A.html, 这时发现以及无法访问了 那么这是怎么回事呢 说好的cookie 会在获取过登录凭证下 再次访问时可以携带呢。
于是想了半天也没有想明白 难道是浏览器限制严格进行了限制 限制规避了这个问题难道我们背的面试题是错误的有知道的小伙伴欢迎下方讨论
sameSite 设置其实上面的问题无法实现 CSRF 是由于 SameSite 的设置问题 其实关键是要设置SameSiteNone简单看一下下面三个设置的区分None: 通常用于处理第三方提供的资源或服务白话就是不受域的限制不同域间可以传递身份验证凭证可以做单点登录 但是要配合Secure标志 即实用 HTTPS 协议Strict: 严格模式完全禁止只有自己网站的请求发送cookieLax浏览器的默认值 用户从外部导航到你的网站时可以发送cookie接下来我们就把上面的 B 服务进行改造 再设置cookie的时候 同时设置 sameSite 和 Secureapp.post(/login, (req, res) { res.cookie(user, allow, { expires: new Date(Date.now() 86400 *
, sameSite: none, secure: true, }); res.send({ data: success }); });然后再次打开http://
127.
0.
1:3000/A.html会发现 cookie 正常设置到了浏览器我们再次在控制台 输入document.forms[0].submit()发现删除操作也正常执行了如图我们就完成了 CSRF 攻击
四、
总结CSRF —— 跨域请求伪造 顾名思义攻击是发生在第三方页面 利用了浏览器在跨域的情况下在一些跨域的请求时如 script 、 img、 form 表单提交、 a标签等可以携带cookie的特性 使得一些伪造的构建请求可以执行成功 进而对正常网页造成危害的行为。
我们通过代码也能看出来 其实现代浏览器对跨域cookie的限制比较多了 但是在一些情况下依然可以发生 比如设置sameSite: None时虽然会增加安全风险 但是 samesite为 None 又有一些场景需要跨域下可以共享cookie比如单点登录、内嵌广告、资源时 所以无法完全禁止 由此我们就可以
总结一些避免CSRF攻击的手段了使用同源策略 限制不同来源直接资源共享检查 Refer 头部 设置白名单并不保险比如 a标签可以设置 rel“noreferrer” 绕开refer检查使用 CSRF Token 每个用户会话设置一个不可预测 唯一的 token每次请求校验尽量使用 POST 和 其他安全的HTTP方法 不在 GET 请求中实现数据写入操作敏感操作增加验证码二次验证服务端把 Cookie 的SameSite 属性设置为 Lax表单提交增加 csrfToken 隐藏字段额外由于CSRF攻击原理是浏览器自动携带 Cookie 如果放开跨站Cookie有CSRF 风险但是不放开又无法做单点登录 所以对于SPA应用来说 JWT 认证的方式更好一些token 会在Authorization头部进行传递网络安全学习路线学习资源网络安全的知识多而杂怎么科学合理安排下面给大家
总结了一套适用于网安零基础的学习路线应届生和转行人员都适用学完保底6k就算你底子差如果能趁着网安良好的发展势头不断学习日后跳槽大厂、拿到百万年薪也不是不可能初级网工
网络安全理论知识2天①了解行业相关背景前景确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。
非常重要
渗透测试基础一周①渗透测试的流程、分类、标准②信息收集技术主动/被动信息搜集、Nmap工具、Google Hacking③漏洞扫描、漏洞利用、原理利用方法、工具MSF、绕过IDS和反病毒侦察④主机攻防演练MS17-
MS08-
MS10-
MS
等
操作系统基础一周①Windows系统常见功能和命令②Kali Linux系统常见功能和命令③操作系统安全系统入侵排查/系统加固基础
计算机网络基础一周①计算机网络基础、协议和架构②网络通信原理、OSI模型、数据转发流程③常见协议解析HTTP、TCP/IP、ARP等④网络攻击技术与网络安全防御技术⑤Web漏洞原理与防御主动/被动攻击、DDOS攻击、CVE漏洞复现
数据库基础操作2天①数据库基础②SQL语言基础③数据库安全加固
Web渗透1周①HTML、CSS和JavaScript简介②OWASP Top10③Web漏洞扫描工具④Web渗透工具Nmap、BurpSuite、SQLMap、其他菜刀、漏扫等恭喜你如果学到这里你基本可以从事一份网络安全相关的工作比如渗透测试、Web 渗透、安全服务、安全分析等岗位如果等保模块学的好还可以从事等保工程师。
薪资区间6k-15k到此为止大概1个月的时间。
你已经成为了一名“脚本小子”。
那么你还想往下探索吗【“脚本小子”成长进阶资源领取】
脚本编程初级/中级/高级在网络安全领域。
是否具备编程能力是“脚本小子”和真正黑客的本质区别。
在实际的渗透测试过程中面对复杂多变的网络环境当常用工具不能满足实际需求的时候往往需要对现有工具进行扩展或者编写符合我们要求的工具、自动化脚本这个时候就需要具备一定的编程能力。
在分秒必争的CTF竞赛中想要高效地使用自制的脚本工具来实现各种目的更是需要拥有编程能力.零基础入门建议选择脚本语言Python/PHP/Go/Java中的一种对常用库进行编程学习 搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP IDE强烈推荐Sublime ·Python编程学习学习内容包含语法、正则、文件、 网络、多线程等常用库推荐《Python核心编程》不要看完 ·用Python编写漏洞的exp,然后写一个简单的网络爬虫 ·PHP基本语法学习并书写一个简单的博客系统 熟悉MVC架构并试着学习一个PHP框架或者Python框架 (可选) ·了解Bootstrap的布局或者CSS。
超级网工这部分内容对零基础的同学来说还比较遥远就不展开细说了贴一个大概的路线。
感兴趣的童鞋可以研究一下不懂得地方可以【点这里】加我耗油跟我学习交流一下。
网络安全工程师企业级学习路线如图片过大被平台压缩导致看不清的话可以【点这里】加我耗油发给你大家也可以一起学习交流一下。
一些我自己买的、其他平台白嫖不到的视频教程需要的话可以扫描下方卡片加我耗油发给你都是无偿分享的大家也可以一起学习交流一下。
网络安全学习路线学习资源结语网络安全产业就像一个江湖各色人等聚集。
相对于欧美国家基础扎实懂加密、会防护、能挖洞、擅工程的众多名门正派我国的人才更多的属于旁门左道很多白帽子可能会不服气因此在未来的人才培养和建设上需要调整结构鼓励更多的人去做“正向”的、结合“业务”与“数据”、“自动化”的“体系、建设”才能解人才之渴真正的为社会全面互联网化提供安全保障。
特别声明此教程为纯技术分享本书的目的决不是为那些怀有不良动机的人提供及技术支持也不承担因为技术被滥用所产生的连带责任本书的目的在于最大限度地唤醒大家对网络安全的重视并采取相应的安全措施从而减少由网络安全而带来的经济损失