java 跨站点伪造请求_你已经不再需要 CSRF 了（跨站点请求伪造）

最新推荐文章于 2023-06-29 15:15:33 发布

餘弦Inverse

最新推荐文章于 2023-06-29 15:15:33 发布

阅读量156

点赞数

文章标签： java 跨站点伪造请求

本文链接：https://blog.csdn.net/weixin_36027743/article/details/114080326

版权

安全研究员Scott Helme介绍了如何利用SameSite cookie特性防止CSRF攻击。SameSite默认设置即将在Chrome浏览器中启用，成为保护用户安全的默认行为。网站开发者需注意，若要跨站设置cookie，需明确设置SameSite=None并添加Secure标志。

摘要由CSDN通过智能技术生成

本文作者：Scott Helme，安全研究员，国际演讲者和本博客的作者。也是 securityheaders.com 和 report-uri.com 的创始人。

不久前，我写了一篇“CSRF 死了”的文章。这篇文字主要介绍 SameSite cookie 这一个强大而简单的功能，可以保护您的网站免受 CSRF 攻击。不过尽管 SameSite cookie 很强大，并且它让你不再需要 CSRF，但前提是必须在你的网站上启用它，这就是问题所在。现在，我们来解决这个问题。

SameSite Cookies

要了解CSRF的问题以及SameSite Cookies提供的解决方案，您应该首先阅读我的原始博客 Cross-Site Request Forgery已经死了！。如果您想了解有关cookie保护的更多详细信息，您还应阅读Tough Cookies。您应该采取强有力的保护措施来保护您的用户/访问者，所以必须开启 SameSite cookie，不过它是可选特性。在实际的环境中，您可以通过在 cookie 中添加SameSite=Lax来启用SameSite ，就像Secure或HttpOnly标记一样。

如下所示：

Set-Cookie: __Host-session=123; path=/; Secure; HttpOnly; SameSite=Lax

可实际情况并没有多少网站将SameSite=Lax标志添加到他们的cookie中。

默认启用 SameSite

当 SameSite 首次问世时，没有人想让它成为默认设置。因为它会破坏原有事物，改变预期(遗留)功能，这会导致开发人员对此有所顾虑。所以 SameSite 设置是一个可选项，但这种情况正在发生变化。

上图中的 Mike 在 Chrome 上工作。我很高兴看到他提到的 SameSite 将作为 cookie 的默认设置启用。你可以检查 Chrome 平台的默认设置SameSite = Lax，并且你将可以在 Chrome 76(已经发布)以及后面的版本看到这一点，并且将很快登陆Chrome 78(很快)。默认情况下，网站运营商无需为SameSite提供强大的保护，但他们可能希望现在使用了 Chrome 这一测试特性后，一切仍然按预期工作：chrome://flags/#same-site-by-default-cookie

更安全

如上面的链接所述，如果需要或想要，网站可以选择退出SameSite保护。为此，网站可以设置SameSite=None其Cookie，Chrome会尊重设置，但有一项要求。cookie 必须设置Secure标志！您可以跟踪 Chrome 的Reject insecure SameSite=None cookies状态，但它可以在 Chrome 76(现在)中显示，并且看起来将在今年晚些时候登陆Chrome 80。这里面的逻辑是有道理的，其目的是保护跨网站请求中发送的cookie，这些cookie可以在网络上跟踪和查看，而不是通过HTTP等不安全的通道发送。同样，网站运营商可以使用该标志测试是否会产生任何影响：chrome://flags/#cookies-without-same-site-must-be-secure

一个更好的方法

我喜欢并同意这样的安全功能成为默认功能的立场。如果网站经营者不希望这样，然后他们可以轻松地选择关闭，但这种方法会让更多的网站在避免更多潜在的安全问题。