各位网络安全爱好者，今天咱们来聊聊一个老生常谈但又不得不防的安全漏洞——CSRF (Cross-Site Request Forgery)，也就是跨站请求伪造。别看它名字挺唬人，其实理解起来一点都不难。保证你看完这篇文章，就能像躲避老板突击检查一样，轻松应对 CSRF 攻击！
温馨提示：网络安全测试需谨慎，切记要在测试环境中进行，避免在生产环境中误操作！
啥是 CSRF？
简单来说，CSRF 就像是黑客偷偷借用了你的浏览器，冒充你向网站发起请求。攻击者通过一些手段，让你的浏览器去访问你之前登录过，且令牌还没失效的网站，并执行你原本没打算执行的操作。
举个栗子，如果某个网站存在 CSRF 漏洞，攻击者精心构造的 payload 可能会让你在不知不觉中：
- 修改账号绑定的邮箱
- 修改账号密码
- 甚至直接转账！
通过这些骚操作，攻击者就能完全控制你的账号。如果受害者恰好是系统管理员，那后果简直不堪设想！
CSRF 攻击的前置条件
想要成功发起 CSRF 攻击，需要满足以下几个条件：
- 目标网站有值得攻击的功能： 比如修改邮箱、密码、转账等高危操作。退一步讲，起码得有增删改的功能吧。如果网站只是用来展示数据的，那 CSRF 攻击就毫无意义，因为你啥也偷不走。
- 基于 Cookie 的会话管理： 网站只通过 Cookie 来验证用户身份，没有其他更安全的会话跟踪和用户验证机制。
- 缺少不可预测的参数： 比如修改密码时需要输入验证码或原密码。这些参数攻击者既不知道，也猜不到，那 CSRF 攻击就很难成功。
CSRF 漏洞的测试方法
CSRF 的测试方法其实so easy：
- 打开 Burp Suite (网络安全测试必备神器)
- 找到你要测试的那个请求
-
右键点击，选择 "Engagement tools" -> "Generate CSRF PoC"
4. 根据实际情况修改 POC 代码
5. 点击 "Test in browser" -> "copy"
6. 打开浏览器，把刚才复制的 URL 粘贴到地址栏
7. 如果执行成功，恭喜你，发现了一个 CSRF 漏洞！
8. 如果失败了，别灰心，看看报错信息，分析是 POC 的问题还是真的不存在 CSRF 漏洞。具体问题具体分析，才是安全测试的精髓。
CSRF 的利用方式
CSRF 的传播方式和反射型 XSS 基本一致，都是想方设法诱导用户点击恶意链接：
- 攻击者把恶意代码放在自己控制的网站上，诱导受害者访问。
- 通过邮件、短信、社交软件等渠道传播恶意链接。
- 把恶意链接放在存在漏洞的网站上，等待有缘人上钩，比如在评论区里搞事情。
CSRF vs XSS：傻傻分不清楚？
CSRF 和 XSS 经常被放在一起比较，但它们之间有本质区别：
- XSS 允许攻击者在受害者的浏览器上执行 JS 代码；而 CSRF 只能冒充用户发起请求，不能执行任意代码。
- XSS 可以通过窃取 Cookie 来接管账号，但如果网站使用了 HttpOnly，就没辙了；CSRF 则是利用浏览器自动携带 Cookie 的特性，即使有 HttpOnly 也能发起攻击。
- XSS 的危害通常更大。攻击者如果成功实施 XSS 攻击，几乎可以使用受害者在该网站的所有功能；而 CSRF 只能攻击特定的存在漏洞的功能。
- CSRF 无法让攻击者获取服务器返回的数据，因为响应最终还是发送到了受害者的浏览器；而 XSS 可以通过 JS 代码将任何数据发送到攻击者的服务器，比如 Cookie。
CSRF 的防御方法：安全三板斧
- 【最稳妥】CSRF Token： 服务器生成一个唯一的、不可预测的 Token，发送给客户端。当用户执行敏感操作时，要求客户端在请求中携带这个 Token。这样攻击者就很难伪造有效的请求，从而有效防止 CSRF 攻击。
-
SameSite Cookie： 这个属性可以指定 Cookie 是否允许跨站请求使用。它有三个可选值：
- Strict（严格模式）： Cookie 在任何跨站请求中都不会被发送，可以有效防止 CSRF 攻击。但可能会导致某些功能受限。
- Lax（宽松模式）： Cookie 只在顶级导航（比如从外部网站链接进入）以及 GET 方法的跨站请求中发送。POST、PUT、DELETE 等请求不会发送 Cookie。
- None（无限制模式）： Cookie 在任何情况下都会被发送，即使是跨站请求。注意：使用 None 模式时，必须同时设置 Secure 属性（仅通过 HTTPS 传输）才能生效，且存在一定的安全风险和隐私问题，应谨慎使用。
3. 【可能有坑】校验 Referer 头： 网站通过验证请求的 Referer 头是否来自自己的域名来防御 CSRF 攻击。但在某些情况下，这种验证可能失效。
CSRF 攻防实战案例
接下来，我们通过几个真实的实验案例，深入了解 CSRF 攻击与防御的各种姿势。
案例一：修改邮箱的 CSRF 漏洞
任务简报
这个实验存在一个修改邮箱的 CSRF 漏洞，你的任务是制作一个 POC 来修改受害者的邮箱。
任务过程
-
使用提供的账号密码登录实验室 wiener:peter
2. 可以看到默认邮箱是 wiener@normal-user.net，随便修改一个抓包，比如修改成 111@normal-user.net。
3. 可以看到，这里只提交了一个修改后的邮箱。使用 Burp Suite 自带的功能生成 POC。
4. 将邮箱修改成我们自己的 13333333333@qq.com，只需要修改 value 中的值。
5. 点击 "Test in browser" -> "copy"，然后在同一个浏览器打开，模拟受害者点击我们传播的 URL。
6. 此时邮箱已经被改变了。回到第 4 步，把邮箱改回 111@normal-user.net，以便下面的演示。
7. 将修改后的 POC 复制到实验室对应的利用服务器上。
8. 将 HTML 复制到 body 中，同时点击 store 保存。
9. 模拟受害者在登录了 web-security-academy.net 这个网站的时候，受到攻击者诱导，在攻击者的网站 exploit-server.net 上点击了一个功能 (View exploit)，然后浏览器自动发起修改 web-security-academy.net 上用户绑定邮箱的场景。点击 View exploit。
10. 可以看到，网站自动跳转到 web-security-academy.net 并将邮箱从 111@normal-user.net 修改为了 13333333333@qq.com。点击 deliver exploit to victim 将你的 POC 传播给受害者们，就可以通过这个实验室了。
CSRF Token 绕过：见招拆招
接下来，我们来深入研究各种绕过 CSRF Token 的方法。
绕过姿势一：未限制请求方法
这种漏洞的出现，是因为开发者没有严格限制请求方法，导致可以使用 GET 方法绕过 POST 方法的 CSRF Token 校验。
任务简报
这个实验在修改邮箱的地方存在 CSRF 漏洞，并且它试图通过 CSRF Token 来阻止 CSRF 攻击。
任务过程
-
省略前面的步骤，直接看修改邮箱的功能是如何实现的。
2. 可以看到存在一个 CSRF Token。尝试删除它，看看会发生什么。
3. 很遗憾，删除 CSRF Token 后请求失败。但不要放弃，尝试使用 GET 方法来修改邮箱。
4. 惊喜！居然成功了。删除 CSRF Token 参数，看看处理逻辑有没有变化。
5. GET 方法居然没有校验 CSRF Token！继续生成 POC，保存到利用服务器，就搞定了。
6. 收工下班！
绕过姿势二：未校验参数是否存在
这种漏洞的出现，是因为开发者没有校验参数的完整性，导致可以直接删除 CSRF Token 参数绕过校验。
任务简报
这个实验在修改邮箱的地方存在 CSRF 漏洞，并且它试图通过 CSRF Token 来阻止 CSRF 攻击。
任务过程
-
看修改邮箱的请求。
2. 和上面的案例类似，删除 CSRF Token 参数。
3. 哈！更简单了，直接干！右键生成 POC，上传利用服务器，就完事了。
绕过姿势三：使用公共的 CSRF Token 池
这种情况是因为应用没有将用户的 Session 和 CSRF Token 进行绑定，而是使用了一个公共的 CSRF Token 池。攻击者可以登录自己的账号获取 Token，然后用于攻击其他用户。
任务简报
这个实验在修改邮箱的地方存在 CSRF 漏洞，并且它试图通过 CSRF Token 来阻止 CSRF 攻击。
任务过程
- 这个演示需要两个账号：wiener:peter 和 carlos:montoya。
-
先登录 wiener，看看修改邮箱是如何实现的。
3. 请求包还是一样的。尝试上面的两种方法，看看是否还能绕过（当然不行）。
4. 记录 wiener 的 Token 值 roVAju4ZU5DLlKwBO9n0GzqvERfXumk8，然后登出当前账号，重新登录 carlos，看看刚才的 Token 还能不能使用。
5. 使用 Intercept 拦截修改 CSRF 的值，发现是无效的。可能有以下几种情况：
* Token 和 Session 绑定，不能使用别人的 Token 绕过校验。
* Token 是一次性的，用后即焚。
* 是公共 Token 池，但是用后即焚。
6. 第一种可能已经验证过了，验证第二种。修改一下邮箱，看看服务器有没有下发新的 CSRF Token，或者看看两次传递的 Token 是不是一样的。
7. 居然是一次性的！只能试试第三种情况。保存现在的 Token (不要用它)，然后登出 carlos，登录 wiener，在修改邮箱的时候替换 CSRF 的值，看看结果如何。
8. 成功了！它的逻辑很清楚：用户每次修改邮箱的时候需要一个服务器下发的一次性 CSRF Token，但这个 Token 并没有与 Session 绑定，而是从公共 Token 池中提取的。可以通过自己的账号来获取一个有效的 CSRF Token 绕过校验。每次有用户上钩之后需要刷新这个 Token 值。
9. 思路清晰之后，重复上面的过程就可以了。
绕过姿势四：CSRF Token 直接在 Cookie 中获取
这种情况下，想要利用还需要有 CRLF 漏洞配合，或者有其他的可以注入 Cookie 的漏洞，使得可以控制 Cookie 的数据，进而控制 CSRF Token 的数据。
防御思路是通过 Cookie 和请求体参数双重提交 Token，服务器判断两个值是否相等来防御 CSRF 漏洞。这样做的好处是服务器不需要进行多余的计算、保存 CSRF Token 值，在生成 Cookie 的时候就可以一起完成。但是，当用户可以定义 Set-Cookie 的时候，这种做法就不再安全了。
任务简报
这个实验在修改邮箱的地方存在 CSRF 漏洞，并且它试图通过双重提交 CSRF Token 来阻止 CSRF 攻击。
任务过程
-
看修改邮箱是如何实现的。
2. 这里可以看出它们是相同的。需要一个地方来想办法注入 Set-Cookie。巧的是，在搜索这里存在一个 CRLF 漏洞：payload %0d%0aSet-Cookie:%20csrf=123456%3b%20SameSite=None
3. 在自己的服务器上（exploit-server.net）构造一个响应，让它去请求 web-security-academy.net 上的资源，然后发起一个请求来实现 CRLF 注入，之后再发送请求去修改邮箱。
4. 生成一个 CSRF 的 POC。
5. 修改 POC，利用 img 标签去请求 web-security-academy.net 上的一个不存在的图片。当它发送这个请求的时候，web-security-academy.net 的 Cookie 中的 csrf 键将被设置为 csrf=123456。当请求失败的时候，就会提交 CSRF 代码来修改邮箱。html <html> <head> <title>CSRF PoC</title> </head> <body> <img src="https://0a5b003404675754805b547c00ba00c1.web-security-academy.net/feedback?search=%0d%0aSet-Cookie:%20csrf=123456%3b%20SameSite=None"> <form action="https://0a5b003404675754805b547c00ba00c1.web-security-academy.net/my-account/change-email" method="POST"> <input type="hidden" name="email" value="hacker@evil.com"> <input type="hidden" name="csrf" value="123456"> <input type="submit" value="Change email"> </form> </body> </html>
6. 看看效果。
7. 攻击完成。
绕过 Referer 头校验
有些网站通过校验 Referer 头来判断请求是否来自自己的网站，以此来防御 CSRF 漏洞。但这种防御方法在某些情况下也可能会被绕过。
绕过姿势一：删除 Referer 头
这种情况存在于开发人员在写代码的时候没有考虑到 Referer 头不存在的情况下的处理逻辑，导致绕过了 Referer 校验。
任务简报
本实验室在修改账号邮箱的地方存在 CSRF 漏洞，但是网站通过 Referer 头进行 CSRF 防御，通过 exploit-server 修改账号的邮箱来通关本实验室。
任务过程
-
看修改邮箱的请求。
2. 成功修改的话会自动跳转，同时请求包里有 Referer 头。修改一下会是什么响应。
3. 报错无效的 Referer。删除它会有什么响应。
4. 可以看到同样修改成功了！如何在 POC 里让它不发送 Referer 头？使用 meta 标签。html <meta name="referrer" content="never">
5. 还是生成一个 POC。
6. 这样的 POC 发送的请求是含有 Referer 头的。加上 meta 标签。
7. Referer 头没有了！绕过成功！
绕过姿势二：包含目标网址的域名
对方的校验逻辑太过简单，比如检验 Referer 是否以自己的域名开始，或者是否包含自己的域名。
这两种都可以用一种简单的办法绕过，那就是买一个域名，然后自己添加一个含有目标站点的子域名，比如 www.baidu.com.test.cn，其中的 www.baidu.com 就是子域名。
对于后面的查看 Referer 是否包含自己的域名，可以有一个简单的办法，比如在 URI 里加上它的值就好了，比如 history.pushState('', '', '/?www.baidu.com')
任务简报
本实验室在修改账号邮箱的地方存在 CSRF 漏洞，但是网站通过 Referer 头进行 CSRF 防御，通过 exploit-server 修改账号的邮箱来通关本实验室。
任务过程
-
直接看修改邮箱的请求包。
2. 看看 Referer 是怎么校验的吧（删掉不好使）。
3. 上面的两种方法都能绕过，说明是校验 Referer 中是否含有域名。生成 POC，然后稍微修改一下 payload：history.pushState("", "", "/?0afc003404932ab58ac96e4e005700a5.web-security-academy.net")
4. 虽然加上了history.pushState("", "", "/?0afc003404932ab58ac96e4e005700a5.web-security-academy.net")，但是它请求的时候 Referer 并没有包含其中自定义的 URI。这是因为浏览器出于安全考虑会在请求的时候删除 Referer 中的查询字段。不过，可以通过租个服务器，设置响应头
Referrer-Policy: unsafe-url来解决这个问题，这样再次请求的时候就不会删掉 Referer 中的查询值了。
5. 使用靶场自带的利用服务器来演示。
资料目录
-
成长路线图&学习规划
-
配套视频教程
-
SRC&黑客文籍
-
护网行动资料
-
黑客必读书单
-
面试题合集
282G《网络安全/黑客技术入门学习大礼包》，可以扫描下方二维码免费领取！
1.成长路线图&学习规划
要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。
对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图&学习规划。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。
2.视频教程
很多朋友都不喜欢晦涩的文字，我也为大家准备了视频教程，其中一共有21个章节，每个章节都是当前板块的精华浓缩。
3.SRC&黑客文籍
大家最喜欢也是最关心的SRC技术文籍&黑客技术也有收录
SRC技术文籍：
黑客资料由于是敏感资源，这里不能直接展示哦！
4.护网行动资料
其中关于HW护网行动，也准备了对应的资料，这些内容可相当于比赛的金手指！
5.黑客必读书单
6.面试题合集
当你自学到这里，你就要开始思考找工作的事情了，而工作绕不开的就是真题和面试题。
更多内容为防止和谐，可以扫描获取~
朋友们需要全套共282G的《网络安全/黑客技术入门学习大礼包》，可以扫描下方二维码免费领取！
扫一扫
2829
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
