Question

The best way to prevent CSRFs is to use CSRF tokens . Applications can embed these random and unpredictable strings in every form on their website, and browsers will send this string along with every state-changing request. When the request reaches the server, the server can validate the token to make sure the request indeed originated from its website. This CSRF token should be unique for each session and/or HTML form so attackers can’t guess the token’s value and embed it on their websites. Tokens should have sufficient entropy so that they cannot be deduced by analyzing tokens across sessions.

防止 CSRF 的最佳方法是使用 CSRF 令牌。应用程序可以将这些随机和不可预测的字符串嵌入其网站上的每个表单中，浏览器将随着每个状态更改请求发送该字符串。当请求到达服务器时，服务器可以验证令牌，以确保该请求确实源于其网站。这个 CSRF 令牌应该对于每个会话和/或 HTML 表单都是唯一的，这样攻击者就无法猜测令牌的值并嵌入它们的网站上。令牌应具有足够的熵，以便不能通过分析跨会话的令牌来推断出它们的价值。

The server generates random CSRF tokens and embeds correct CSRF tokens in forms on the legitimate site. Notice the new input field used to specify a CSRF token:

服务器会生成随机的 CSRF 令牌，并将正确的 CSRF 令牌嵌入到合法网站的表单中。请注意，新的输入字段用于指定 CSRF 令牌：

<form method="POST" action="https://twitter.com/send_a_tweet">
  <input type="text" name="tweet_content" value="Hello world!">
      <input type="text" name="csrf_token" value="871caef0757a4ac9691aceb9aad8b65b"> 
  <input type="submit" value="Submit">
</form>

Twitter’s server can require that the browser send the correct value of the csrf_token POST parameter along with the request for it to be successful. If the value of csrf_token is missing or incorrect, the server should see the request as fake and reject it.

Twitter 的服务器可能会要求浏览器在请求时发送正确的 csrf_token POST 参数值才能成功。如果 csrf_token 的值缺失或不正确，服务器应该将请求视为伪造并拒绝它。

Here is the resulting POST request:

这是产生的 POST 请求：

POST /send_a_tweet
Host: twitter.com
Cookie: session_cookie=YOUR_TWITTER_SESSION_COOKIE

(POST request body)
tweet_content="Hello world!"&    csrf_token=871caef0757a4ac9691aceb9aad8b65b

Many frameworks have CSRF tokens built in, so often you can simply use your framework’s implementation.

许多框架都内置了 CSRF 令牌，因此通常您可以直接使用框架的实现。

Besides implementing CSRF tokens to ensure the authenticity of requests, another way of protecting against CSRF is with SameSite cookies. The Set-Cookie header allows you to use several optional flags to protect your users’ cookies, one of which is the SameSite flag. When the SameSite flag on a cookie is set to Strict , the client’s browser won’t send the cookie during cross-site requests:

除了实现 CSRF 令牌以确保请求的真实性，另一种防止 CSRF 的方法是使用 SameSite cookie。 Set-Cookie 标头允许您使用几个可选标志来保护用户的 cookie，其中之一是 SameSite 标志。当同站点标志的 cookie 被设置为“严格”时，客户端的浏览器不会在跨站点请求期间发送该 cookie。

Set-Cookie: PHPSESSID=UEhQU0VTU0lE; Max-Age=86400; Secure; HttpOnly; SameSite=Strict

Another possible setting for the SameSite flag is Lax , which tells the client’s browser to send a cookie only in requests that cause top-level navigation (when users actively click a link and navigate to the site). This setting ensures that users still have access to the resources on your site if the cross-site request is intentional. For example, if you navigate to Facebook from a third-party site, your Facebook logins will be sent. But if a third-party site initiates a POST request to Facebook or tries to embed the contents of Facebook within an iframe, cookies won’t be sent:

另一种可能的 SameSite 标志设置为 Lax，告诉客户端浏览器仅在引起顶级导航的请求中发送 cookie（当用户积极点击链接并导航到网站时）。此设置确保用户仍然可以访问您网站上的资源，如果跨站请求是有意的。例如，如果您从第三方网站导航到 Facebook，则会发送您的 Facebook 登录信息。但是，如果第三方网站发起 POST 请求到 Facebook 或尝试将 Facebook 内容嵌入 iframe 中，则不会发送 cookie。

Set-Cookie: PHPSESSID=UEhQU0VTU0lE; Max-Age=86400; Secure; HttpOnly; SameSite=Lax

Specifying the SameSite attribute is good protection against CSRF because both the Strict and Lax settings will prevent browsers from sending cookies on cross-site form POST or AJAX requests, and within iframes and image tags. This renders the classic CSRF hidden-form attack useless.

指定 SameSite 属性是对抗 CSRF 的良好保护，因为严格（Strict）和宽松（Lax）设置都可以防止浏览器发送跨站表单 POST 或 AJAX 请求、iframe 和图像标签中的 cookie。这使得经典的 CSRF 隐藏表单攻击无效。

In 2020, Chrome and a few other browsers made SameSite=Lax the default cookie setting if it’s not explicitly set by the web application. Therefore, even if a web application doesn’t implement CSRF protection, attackers won’t be able to attack a victim who uses Chrome with POST CSRF. The efficacy of a classic CSRF attack will likely be greatly reduced, since Chrome has the largest web browser market share. On Firefox, the SameSite default setting is a feature that needs to be enabled. You can enable it by going to about:config and setting network.cookie.sameSite.laxByDefault to true .

在 2020 年，Chrome 和少数其他浏览器将 SameSite=Lax 作为默认的 Cookie 设置，如果它未被 Web 应用程序明确设置。因此，即使 Web 应用程序不实现 CSRF 保护，攻击者也无法攻击使用 Chrome 进行 POST CSRF 的受害者。经典 CSRF 攻击的功效可能会大大降低，因为 Chrome 拥有最大的网络浏览器市场份额。在 Firefox 上，SameSite 默认设置是需要启用的功能。您可以通过转到 about：config 并将 network.cookie.sameSite.laxByDefault 设置为 true 来启用它。

Even when browsers adopt the SameSite- by-default policy, CSRFs are still possible under some conditions. First, if the site allows state-changing requests with the GET HTTP method, third-party sites can attack users by creating CSRF with a GET request. For example, if the site allows you to change a password with a GET request, you could post a link like this to trick users into clicking it: https://email.example.com/password_change?new_password=abc123 .

即使浏览器采用了 SameSite-by-default 政策，在某些情况下仍然可能存在 CSRF 攻击。首先，如果网站允许使用 GET HTTP 方法进行状态更改请求，第三方网站就可以通过 GET 请求创建 CSRF 攻击来攻击用户。例如，如果网站允许您使用 GET 请求更改密码，您可以发布此链接来欺骗用户单击它:https://email.example.com/password_change?new_password=abc123.

Since clicking this link will cause top-level navigation, the user’s session cookies will be included in the GET request, and the CSRF attack will succeed:

由于单击此链接将导致顶层导航，用户的会话 cookie 将包含在 GET 请求中，从而使 CSRF 攻击成功。

GET /password_change?new_password=abc123
Host: email.example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE

In another scenario, sites manually set the SameSite attribute of a cookie to None . Some web applications have features that require third-party sites to send cross-site authenticated requests. In that case, you might explicitly set SameSite on a session cookie to None , allowing the sending of the cookie across origins, so traditional CSRF attacks would still work. Finally, if the victim is using a browser that doesn’t set the SameSite attribute to Lax by default (including Firefox, Internet Explorer, and Safari), traditional CSRF attacks will still work if the target application doesn’t implement diligent CSRF protection.

在另一种情况下，站点手动设置了 SameSite 属性为 None 的 cookie。一些 Web 应用程序具有需要第三方站点发送跨站身份验证请求的功能。在这种情况下，您可以明确地将 SameSite 设置为 None 并在会话 cookie 上，允许跨源发送 cookie，因此传统 CSRF 攻击仍然有效。最后，如果受害者使用的浏览器不会默认将 SameSite 属性设置为 Lax（包括 Firefox、Internet Explorer 和 Safari），则如果目标应用程序没有实施认真的 CSRF 保护，则传统的 CSRF 攻击仍然有效。

We’ll explore other ways of bypassing CSRF protection later in this chapter. For now, just remember: when websites don’t implement SameSite cookies or other CSRF protection for every state-changing request, the request becomes vulnerable to CSRF if the user is not using a SameSite -by-default browser. CSRF protection is still the responsibility of the website despite the adoption of SameSite -by-default.

我们将在本章后面探索绕过 CSRF 保护的其他方法。目前，只需记住：当网站对于每个状态改变请求都没有实施 SameSite cookie 或其他 CSRF 保护时，如果用户没有使用 SameSite-by-default 浏览器，该请求将变得容易受到 CSRF 攻击。尽管采用 SameSite-by-default，但 CSRF 保护仍然是网站的责任。