CSRF （跨站点请求伪造）问题的示例分析

今天就跟大家聊聊有关 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

看完上述内容，你们对 CSRF （跨站点请求伪造）问题的示例分析有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注行业资讯频道，感谢大家的支持。