绕过CSRF token验证
翻译
原文：https://portswigger.net/web-security/csrf/bypassing-token-validation
- name: 翻译
desc: 原文：https://portswigger.net/web-security/csrf/bypassing-token-validation
bgColor: '#F0DFB1'
textColor: 'green'
2
3
4
# 绕过CSRF token验证
在本节中，我们将解释什么是 CSRF tokens、它们如何防范 CSRF 攻击，以及如何绕过这些防御。
# 1什么是CSRF token？
CSRF 令牌是由服务器端应用程序生成，并与客户端共享的、唯一的、秘密且不可预测的值。当发出执行敏感操作的请求（例如提交表单）时，客户端必须包含正确的 CSRF 令牌。否则，服务器将拒绝执行请求的操作。
与客户端共享 CSRF 令牌的常见方法，将其作为隐藏参数并包含在 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>
2
3
4
5
6
提交此表单会导致以下请求：
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
2
3
4
5
6
如果实施正确，CSRF 令牌将使攻击者 难以从受害者视角构建有效请求，从而帮助防止 CSRF 攻击。由于攻击者无法预测 CSRF 令牌的正确值，因此他们无法将其包含在恶意请求中。
笔记
CSRF 令牌不必作为POST请求中的隐藏参数发送。例如，一些应用程序将 CSRF 令牌放置在 HTTP 标头中。令牌的传输方式 对整个机制的安全性 有着重大影响。更多详细信息，请参阅如何防范CSRF漏洞 (opens new window)。
# 2CSRF token验证中的常见缺陷
CSRF 漏洞通常是由于 CSRF 令牌的验证中存在缺陷而产生的。在本节中，我们将介绍一些 使攻击者能够绕过这些防御 的最常见问题。
# 2.1CSRF token的验证取决于请求方法
某些应用程序在使用POST方法时正确验证令牌，但在使用GET方法时跳过验证。
在这种情况下，攻击者可以切换到GET方法来绕过验证并传递CSRF攻击 (opens new window)：
GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
2
3
- name: 实验室-从业者
desc: CSRF-令牌验证取决于请求方法 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/csrf/bypassing-token-validation/lab-token-validation-depends-on-request-method
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
# 2.2CSRF token的验证取决于token是否存在
当令牌存在时，某些应用程序会正确验证令牌，但如果不携带令牌，则会跳过验证。
在这种情况下，攻击者可以删除包含令牌的整个参数（而不仅仅是其值）来绕过验证并传递CSRF攻击 (opens new window)：
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
email=pwned@evil-user.net
2
3
4
5
6
7
- name: 实验室-从业者
desc: CSRF-令牌验证取决于令牌是否存在 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/csrf/bypassing-token-validation/lab-token-validation-depends-on-token-being-present
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
# 2.3CSRF token未绑定到用户会话
某些应用程序不会验证令牌 是否与发出请求的用户属于同一会话。相反，应用程序维护它已颁发的令牌全局池，并接受出现在该池中的任何令牌。
在这种情况下，攻击者可以使用 自己的帐户 登录到应用程序，获取自己的有效令牌，然后在 CSRF 攻击中将该令牌提供给受害用户。
- name: 实验室-从业者
desc: CSRF-令牌未绑定到用户会话 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/csrf/bypassing-token-validation/lab-token-not-tied-to-user-session
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
# 2.4CSRF token绑定到非会话cookie
在上述漏洞的变体中，某些应用程序确实将 CSRF 令牌绑定到 cookie，但不绑定到用于跟踪会话的同一 cookie。当应用程序使用两个不同的框架时，很容易发生这种情况，一个用于会话处理，另一个用于 CSRF 保护，这两个框架没有集成在一起：
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv
csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&email=wiener@normal-user.com
2
3
4
5
6
7
这种情况虽然更难利用，但其仍然很脆弱。如果网站包含 允许攻击者在受害者的浏览器中设置 cookie 的行为，则可能受到攻击。攻击者可以使用自己的帐户登录到应用程序，获取有效的令牌和关联的 cookie，利用 cookie 设置行为将其 cookie 放入受害者的浏览器中，并在 CSRF 攻击中将自己的令牌提供给受害者。
- name: 实验室-从业者
desc: CSRF-令牌绑定到非会话cookie >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/csrf/bypassing-token-validation/lab-token-tied-to-non-session-cookie
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
笔记
cookie 设置行为甚至不需要位于与 CSRF 漏洞相同的 Web 应用程序中。如果受控的 Cookie 具有合适的范围，则可以潜在地利用同一个整体 DNS 域内的任何其他应用程序，从而在目标应用程序中设置 Cookie。例如，可以利用staging.demo.normal-website.com上的 cookie 设置功能来放置提交给secure.normal-website.com的 Cookie。
# 2.5CSRF token仅在Cookie中复制
在上述漏洞的进一步变体中，一些应用程序不维护已颁发令牌的任何服务器端记录，而是在 Cookie 和请求参数中复制接收到的每个令牌。当验证后续请求时，应用程序只需验证 在请求参数中提交的令牌是否与 Cookie 中提交的值匹配。这有时被称为针对 CSRF 的 “双重提交” 防御，之所以提倡这样做，是因为它易于实现，并且不需要任何服务器端状态：
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa
csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=wiener@normal-user.com
2
3
4
5
6
7
在这种情况下，如果网站包含任何 cookie 设置功能，则攻击者可以执行 CSRF 攻击。在这里，攻击者不需要获取自己的有效令牌。他们只需要编造一个令牌（根据所需的检查格式），利用 cookie 设置行为将他们的 cookie 放入受害者的浏览器中，并在 CSRF 攻击中将他们的令牌提供给受害者。
- name: 实验室-从业者
desc: CSRF-令牌仅在Cookie中复制 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/csrf/bypassing-token-validation/lab-token-duplicated-in-cookie
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6