SameSite cookie属性与同步器令牌模式

Question

最近，大多数浏览器增加了对SameSite cookie属性的支持，以防止CSRF攻击：https://www.owasp.org/index.php/SameSite。

如果支持，我们是否应该实现同步器令牌模式来防止CSRF攻击？https://www.owasp.org/index.php/Cross-Site_请求_伪造_(CSRF)_预防_作弊_Sheet#Synchronizer_令牌_模式

SameSite是否能防止至少与同步器令牌模式相同的CSRF攻击？

我知道SameSite选项是strict和lax，我们可能会使用lax值。

添加的

如果我们只在支持设置( SameSite )的浏览器中使用SameSite设置(没有同步器令牌模式)，那么CSRF攻击是可能的吗？

什么是可能的攻击场景？

(这个问题与XSS攻击无关，只与CSRF攻击有关)

Answer 1

如果支持它，我们是否应该实现同步器令牌模式来防止CSRF攻击？

但是，No!绝对不应该使用GET相似的请求方法来进行状态更改操作。

SameSite是否能防止至少与同步器令牌模式相同的CSRF攻击？

Yes!由于忽略了向来自第三个域的请求发送cookie(标记的SameSite)，跨站点请求不能发出经过身份验证的请求。因此，这就阻止了CSRF。但是，SameSite cookie并不会阻止所有类型的GET请求。例如，链接预分发程序请求是一些例外，很可能不会添加到列表中。因此，不使用GET请求进行状态更改操作是非常重要的。

如果我们只在支持设置的浏览器中使用SameSite设置(没有同步器令牌模式)，那么CSRF攻击是否可能？

简短的回答:不，有可能覆盖曲奇。然而，这并不使它易受CSRF的影响。若要覆盖cookie，攻击者必须提供一个值。在这种情况下，如果S/他已经知道cookie的价值，S/他已经可以访问受害者的帐户。但是，现场请求伪造 (如注释中提到的)总是一个例外。

什么是可能的攻击场景？

没有任何漏洞，除非与其他漏洞相结合。

编辑：插件启动请求(Flash、PDF等)可能不像你期望的那样。他们可能会也可能不会SameSite cookie。因此，atm与SameSite cookie一起使用令牌。

Answer 2

一个老问题的新答案，但请容忍我。

不管您考虑的是哪种类型的反CSRF令牌实现(无论是同步器令牌模式还是另一种)，请注意，SameSite cookie属性不是反CSRF令牌的插入替代；SameSite和反CSRF令牌对相同的攻击向量的保护并不相同。

cookie属性被命名为"SameSite“而不是"SameOrigin”是有原因的。将站点和来源混为一谈是有误导性的，并可能诱使您对SameSite提供的针对跨源攻击的保护级别产生错误的安全感。

特别是，与反CSRF令牌相反，SameSite不能保护您的用户免受跨源、相同站点的攻击。这是正确的:请求(因此，也就是攻击)可以是跨源但相同的站点；请参见这个web.dev帖子。

如果您完全依赖SameSite，那么最好仔细检查所有子域的安全级别:在同一站点的一个子域上的单个子域接管或XSS实例(或者可能是HTML )足以绕过SameSite提供的保护。(我最近给博客写了这篇文章。)