跨站请求伪造(CSRF)
翻译
原文：https://portswigger.net/web-security/csrf
- name: 翻译
desc: 原文：https://portswigger.net/web-security/csrf
bgColor: '#F0DFB1'
textColor: 'green'
2
3
4
# 0跨站请求伪造（CSRF）
在本节中，我们将解释什么是跨站请求伪造，描述一些常见的 CSRF 漏洞示例，并说明如何防范 CSRF 攻击。
# 1什么是CSRF？
跨站请求伪造（也称为 CSRF）是一种 Web 安全漏洞，允许攻击者诱使用户执行他们本不打算执行的操作。它允许攻击者规避部分同源策略，该策略旨在不同的网站之间防止相互干扰。
实验室
如果您已经熟悉 CSRF 漏洞背后的基本概念，并且只想在一些实际的、易受攻击的目标上练习和利用它们，那么您可以从下面的链接访问本主题中的所有实验室。
# 2CSRF攻击的影响是什么？
在成功的 CSRF 攻击中，攻击者会导致受害用户无意中执行某个操作。例如，这可能是更改其帐户上的电子邮件地址、更改密码或进行资金转账。
根据操作的性质，攻击者可能能够 获得对用户帐户的完全控制权。假如，受攻击的用户在应用程序中具有特权角色，则攻击者可能能够 完全控制应用程序中的所有数据和功能。
# 3CSRF是如何工作的？
要使 CSRF 攻击成为可能，必须满足三个关键条件：
- 存在相关操作。在应用程序中，存在攻击者有理由诱导的操作。这可能是特权操作（例如 修改其他用户的权限）或对用户特定数据的任何操作（例如 更改用户自己的密码）。
- 基于Cookie的会话处理。执行该操作涉及发出一个或多个 HTTP 请求，并且应用程序仅依靠会话 cookie 来识别发出请求的用户。除此之外没有其他机制 来跟踪会话或验证用户请求。
- 没有不可预测的请求参数。执行该操作的请求中，不包含攻击者无法确定 或 猜测其值的任何参数。例如，当导致用户更改其密码时，如果攻击者需要知道现有密码的值，则该功能不易受到攻击。
例如，假设应用程序包含一个功能，该功能允许用户更改其帐户上的电子邮件地址。当用户执行此操作时，他们会发出如下所示的 HTTP 请求：
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
email=wiener@normal-user.com
2
3
4
5
6
7
这符合 CSRF 所需的条件：
- “更改用户帐户上的电子邮件地址”，攻击者对这个操作很感兴趣。执行此操作后，攻击者通常能够触发密码重置，然后完全控制用户帐户。
- 应用程序使用会话 Cookie 来识别发出请求的用户，没有其他令牌或机制来跟踪用户会话。
- 攻击者可以轻松地确定 执行操作所需的请求参数和值。
满足这些条件后，攻击者可以构建包含以下 HTML 的网页：
<html>
<body>
<form action="https://vulnerable-website.com/email/change" method="POST">
<input type="hidden" name="email" value="pwned@evil-user.net" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
2
3
4
5
6
7
8
9
10
如果受害用户访问攻击者的网页，将发生以下情况：
- 攻击者的网页 将触发对易受攻击网站的 HTTP 请求。
- 如果用户已经登录到易受攻击的网站，则他们的浏览器将自动在请求中包含他们的会话 Cookie（假设其未使用SameSite cookies (opens new window)）。
- 易受攻击的网站将以正常方式处理请求，将其视为 由受害用户发出的正常请求，并更改其电子邮件地址。
笔记
尽管 CSRF 通常与 “基于cookie的会话处理” 有关，但它也时常出现在 “应用程序自动向请求添加一些用户凭据” 的其他上下文中，例如 HTTP 基本身份验证和基于证书的身份验证。
# 4如何构建CSRF攻击
手动创建 CSRF 漏洞载荷所需的 HTML 可能会很麻烦，尤其是 当所需的请求中包含大量参数，或请求中存在其他怪异的情况下。构建 CSRF 漏洞载荷的最简单方法是使用Burp Suite Professional (opens new window)内置的CSRF PoC生成器 (opens new window)：
- 在 Burp Suite Professional 中的任意位置，选中要测试或利用的请求。
- 从右键单击上下文菜单中，选择 “Engagement tools / Generate CSRF PoC”。
- Burp Suite 将生成一些 HTML 来触发所选的请求（减去Cookie，这将由受害者的浏览器自动添加）。
- 你可以调整 CSRF PoC生成器 中的各种选项，以微调攻击的各个方面。在某些异常情况下，你可能才需要微调，以处理该请求的古怪特性。
登录到易受攻击的网站，将生成的 HTML 复制到网页中并在浏览器中查看它，测试预期的请求是否成功发出，所需的操作是否发生。
- 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/lab-no-defenses
bgColor: '#001350'
textColor: '#39d50c'
2
3
4
5
6
# 5如何传递CSRF漏洞载荷
跨站请求伪造攻击 的传递机制与反射型XSS (opens new window)基本相同。通常，攻击者会将恶意 HTML 放置到他们控制的网站上，然后诱使受害者访问该网站。这可以通过电子邮件 或 社交媒体消息，向用户提供网站的链接来完成。或者，如果将攻击放置在一个流行的网站（例如，在用户评论中），则他们可能只是等待用户访问该网站。
请注意，一些简单的 CSRF 漏洞载荷采用了 GET 方法，并且可以在易受攻击的网站上使用单个 URL 实现完全自包含。在这种情况下，攻击者可能不需要使用外部站点，可以直接向受害者提供 易受攻击域 上的恶意 URL。在前面的示例中，如果可以使用 GET 方法执行更改电子邮件地址的请求，则自包含攻击将如下所示：
<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">
# 6针对CSRF的常见防御措施
如今，发现并成功利用 CSRF 漏洞通常涉及绕过反 CSRF 措施，这一般在“目标网站、受害者浏览器，或两端同时”部署了措施。你即将遇到的、最常见的防御措施如下：
- CSRF tokens — CSRF 令牌是由服务器端应用程序生成，并与客户端共享的、唯一的、秘密且不可预测的值。当尝试执行敏感操作（例如提交表单）时，客户端必须在请求中包含正确的 CSRF 令牌。这使得攻击者很难以受害者视角 来构建有效的请求。
- SameSite cookies — SameSite 是一种浏览器安全机制，用于确定何时将网站的 cookies 包含在来自其他网站的请求中。由于执行敏感操作的请求通常需要经过身份验证的会话 Cookie，因此适当的 SameSite 限制可以阻止攻击者触发这些跨站点的操作。自 2021 年起，Chrome 默认强制执行名为
Lax的 SameSite 限制。由于这是拟议的标准，我们希望其他主流浏览器将来也会采用这种行为。 - 基于Referer的验证 — 一些应用程序尝试使用 HTTP Referer 标头来防御 CSRF 攻击，原理是 验证请求是否来自应用程序自己的域。该措施通常不如 CSRF 令牌验证有效。
有关这些防御措施的更详细描述，以及如何绕过它们，请查看以下材料。其中含有交互式实验室，可以让你在实际的、故意易受攻击的目标上练习所学的知识。
学习更多
有关 “如何正确实施这些防御措施，以在你自己的网站上防止出现这些问题” 的详细信息，请参阅如何防范CSRF漏洞 (opens new window)。