csrfs还是一回事吗

CSRF vulnerabilities happen when attackers can initiate forged state-changing requests from a foreign domain. This usually occurs because the user’s browser sends session cookies regardless of where the request originates from.

当攻击者可以从外部域发起伪造的状态更改请求时，就会发生CSRF漏洞 。 这通常是因为用户的浏览器发送会话cookie，无论请求来自何处。

Besides implementing CSRF tokens to ensure the authenticity of requests, another way of protecting against CSRF is SameSite cookies.

除了实现CSRF令牌以确保请求的真实性之外，防止CSRF的另一种方法是SameSite cookie。

SameSite饼干 (SameSite Cookies)

A web application instructs the user’s browser to set cookies via a Set-Cookie header. For example, this header will make the client browser set the value of the cookie PHPSESSID to UEhQU0VTU0lE:

Web应用程序指示用户的浏览器通过Set-Cookie标头Set-Cookie 。 例如，此标头将使客户端浏览器将Cookie PHPSESSID的值设置为UEhQU0VTU0lE ：

Set-Cookie: PHPSESSID=UEhQU0VTU0lE

Besides the basic “cookie_name=cookie_value” designation, the Set-Cookie header allows several optional flags you can use to protect your users’ cookies. One of them is the SameSite flag, which helps prevent CSRF attacks. When the SameSite flag on a cookie is set to Strict, the client’s browser will not send the cookie during cross-site requests.

除了基本的“ cookie_name = cookie_value”标识外， Set-Cookie标头还提供了几个可选标志，您可以使用这些标志来保护用户的cookie。 其中之一是SameSite标志，它有助于防止CSRF攻击。 当cookie上的SameSite标志设置为Strict ，客户端的浏览器将不会在跨站点请求期间发送该cookie。

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

Another possible setting for the SameSite flag is Lax. This setting tells the client’s browser to send a cookie only in GET requests that cause top-level navigation. This setting ensures that users still have access to the resources on your site if the cross-site request is intentional.

SameSite标志的另一个可能的设置是Lax 。 此设置告诉客户端的浏览器仅在导致顶级导航的GET请求中发送cookie。 此设置可确保在有意跨站点请求的情况下，用户仍然可以访问您站点上的资源。

For example, if you navigate to Facebook from a third-party site, your Facebook logins would 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 would not be sent.

例如，如果您从第三方站点导航到Facebook，则将发送您的Facebook登录名。 但是，如果第三方网站向Facebook发起POST请求或尝试将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, 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隐藏形式攻击毫无用处。

默认情况下为SameSite (SameSite by Default)

Earlier this year, Chrome and a few other browsers made SameSite=Lax the default cookie setting if it’s not explicitly set by the web application. This means that even if a web application does not implement CSRF protection, attackers will not be able to attack a victim using the Chrome browser using POST CSRF.

今年早些时候，Chrome和其他一些浏览器将SameSite=Lax设置为默认的cookie设置(如果Web应用程序未明确设置的话)。 这意味着即使Web应用程序未实现CSRF保护，攻击者也将无法使用POST CSRF使用Chrome浏览器攻击受害者。

So in the future, the efficacy of a classic CSRF attack will be greatly reduced since Chrome has the largest web browser market share.

因此，由于Chrome拥有最大的Web浏览器市场份额，因此将来经典CSRF攻击的功效将大大降低。

On Firefox, the SameSite by 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.

在Firefox上， SameSite by default ， SameSite by default设置是一项需要启用的功能。 您可以通过about:config并将network.cookie.sameSite.laxByDefault设置为true来启用它。

CSRF是否仍然可能？ (Is CSRF Still Possible?)

Yes. Even with browsers adopting the SameSite by default policy, CSRFs are still possible under some conditions.

是。 即使浏览器SameSite by default采用SameSite by default策略，在某些情况下CSRF仍然可行。

First, if the site allows state-changing requests with the GET HTTP method, then third-party sites can attack users by creating CSRF with a GET request.

首先，如果站点允许使用GET HTTP方法更改状态，则第三方站点可以通过使用GET请求创建CSRF来攻击用户。

For example, if the site allows you to change a password with a GET request, attackers could embed a link like this in forums to trick users into clicking on it:

例如，如果该站点允许您使用GET请求更改密码，则攻击者可以在论坛中嵌入这样的链接，以诱骗用户单击它：

https://email.example.com/password_change?new_password=abc123

In this case, since clicking on the 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

Another scenario is when 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, developers might explicitly set SameSite on a session cookie to None. When the SameSite attribute is set to None, sending the cookie cross-origin is allowed, so traditional CSRF attacks would still work.

另一种情况是网站将Cookie的SameSite属性手动设置为None 。 某些Web应用程序具有要求第三方站点发送跨站点的，经过身份验证的请求的功能。 在这种情况下，开发人员可以SameSite cookie上的SameSite显式设置为None 。 当SameSite属性设置为None ，允许发送cookie跨域，因此传统的CSRF攻击仍然有效。

Finally, if the victim is using a browser that does not set the SameSite attribute to Lax by default (like IE and Safari), traditional CSRF attacks would still work if the target application does not implement diligent CSRF protection.

最后，如果受害者使用的浏览器默认未将SameSite属性设置为Lax (例如IE和Safari)，那么如果目标应用程序未实施严格的CSRF保护，则传统的CSRF攻击仍然有效。

翻译自: https://medium.com/better-programming/are-csrfs-still-a-thing-7e16c09c951a