在本文中，我剖析了有关SameSite Cookie属性的常见误解，并探讨了它对Web安全的潜在影响。
毫无疑问，您会听说过SameSite cookie属性。当2020年2月，Chrome开始推出对SameSite默认行为的更改时，它就成为头条新闻；几个月后，Firefox紧随其后。
自从2016年问世以来，SameSite就一直是处于休眠状态的，旨在防御跨站点攻击的深度防御机制，例如跨站点请求伪造（CSRF）和跨站点脚本包含（XSSI）。 。
SameSite在2020年初的激活要求某些网站进行费力的调整以维护第三方访问权限，但被广泛赞誉为浏览器防御的可喜补充。基于对SameSite在浏览器中的激活的预期和反应，帖子开始在整个Web博客上泛滥成灾关于“新” Cookie属性的机制的字眼。
其中一些帖子的精确度令人钦佩，例如Rowan Merewood的web.dev标题为“ SameSite Cookie的解释”。不幸的是，关于SameSite的帖子相对较少，是为了澄清站点的概念，而其中相同站点的概念请求和跨站点请求当然是派生的。
此外，许多帖子，包括由Infosec社区有影响力的成员撰写的帖子，似乎互换使用或至少在某种程度上宽松地使用了“起源”和“站点”一词。
SameSite属性是一个相当新的属性，可为CSRF攻击提供出色的保护。如果Cookie使用SameSite属性，则Web浏览器将确保使用Cookie发出的请求来自该Cookie的原始来源。
Infosec超级巨星Troy Hunt本人在2020年1月上旬发表的题为“滥发饼干及其通过SameSite策略造成的死亡”的开创性文章中，对不同SameSite属性值的影响进行了如下描述：
几个月后，在另一个令人着迷的后期分析中，SameSite的出现是如何影响黑客所怀有的一系列漏洞的，Reconless团队写道：
更新后，所有没有显式SameSite属性的cookie都将被视为具有SameSite = Lax。这意味着跨域请求不再携带cookie（顶级导航除外）。
域，主机，来源，站点…在非正式交流中轻松地使用这些术语是很自然的；这种术语使用上的松懈是可以原谅的，而且如果您自己对此感到内，那就意味着您是一家好公司。
或者，如果“地点”和“原产地”之间确实存在真正的区别，那么对从业者来说重要吗？
您可能已经猜到了这篇帖子标题的答案：“站点”在SameSite中具有非常技术性的含义，但是被过分忽略了；站点和起源之间的区别确实很重要，但是这两个概念经常出现混在一起。
术语的失误并不能使所有人逃脱。谷歌的Web开发者倡导者Kitamura认为，有必要专门撰写一篇有关“起源”和“站点”之间区别的博客文章，这是在Chrome激活SameSite仅仅几个月后才发现的。
为了了解区别的重要性，您首先需要了解原产地和产地之间的区别。
如果您使用Web技术，则至少要熟悉“同源策略”（SOP），它可以说是Web安全性的主要支柱之一。URI的概念当然是SOP的核心，因此这样，它是相对容易理解的。 RFC 6454的3.2节将原点定义为三元组：
粗略地说，如果两个URI具有相同的方案，主机和端口，则它们是同一来源的一部分（即代表相同的主体）。
端口是可选的；如果未指定，则表示与方案关联的默认端口（例如，http的端口为80，https的端口为443）。 MDN Web Docs提供了一系列有用的示例。
在“现场”这个痛苦的通用术语后面隐藏着一个根本上比起源更难理解的概念。一方面，“现场”一词并不总是一个技术性的术语：它早于SOP并在攻击时被普遍使用。就像跨站点脚本的出现一样。此外，现代站点概念充满了技术难题。它与主机的可注册域（URL Living Standard定义为：
[…]由最具体的公共后缀组成的域，以及紧随其后的域标签（如果有）。
（主机的可注册域也称为“ eTLD + 1”，是“有效顶级域加一”的缩写。）
在最简单的情况下，起源站点仅对应于起源主机的可注册域（如果有）。
https://www.example.org的网站为example.org，因为org是主持人的最特定的公共后缀，因此example.org是主持人的eTLD + 1。
https://jub0bs.github.io的站点是jub0bs.github.io，因为github.io是主机的最特定的公共后缀，因此jub0bs.github.io是主机的eTLD + 1。
但是，值得注意的是，可注册域的概念是一个不稳定的概念，因为它依赖于“公共后缀列表”，该列表并非一成不变，而是会随着时间的推移而变化。更不用说不同的浏览器可能不会必须以相同的速度跟上“公共后缀”列表的变化。
技术还不止于此！当web.dev警告我们时，网站的概念仍在不断发展，并将很快纳入该计划。此更改目前在Chrome中是一个标志，但很快将被推广。但是，可以避免这种困难并延长本文的相关性，在下文中，我将只考虑其方案为https的起源。
现在我们已经处理了站点的概念，我们终于可以讨论相同站点和跨站点请求的概念。给定的请求可以是相同站点或跨站点的。请求是相同站点还是跨站点的-site取决于请求的源来源和目标来源之间的比较：
从https://foo.example.org发送到https://bar.example.org的请求是同一站点，因为两个来源的站点都是example.org。
来自https：//foo.github.ioto https://bar.github.io的请求是跨站点的，因为第一个起源的站点是foo.github.io，而第二个起源的站点是bar .github.io。
从https://foo.bar.example.org发送到https://bar.example.org的请求是同一站点，因为两个来源的站点都是example.org。
如果您在目前的职位上做得这么远，我感谢您的耐心。请放心：回报已近！
所有跨站点请求都必须是跨源的；这很明显。但是，如上面的第一个和第三个示例所示，并非所有跨域请求都是跨站点的。
SameSite cookie属性仅与跨站点请求有关;它对碰巧是同一站点的跨源请求没有影响，这就是为什么区分源站点和站点站点很重要的原因。
为了证明我的观点，我从特洛伊·亨特（Troy Hunt）的帖子中汲取了灵感，并将一个简单的Go服务器部署到了由两个简单端点组成的samesitedemo.jub0bs.com。端点/ setcookie设置SameSite = Strict cookie，如下所示
端点/ readcookie会打印附加到请求的cookie（如果有）。我还设置了两个“攻击”页面：
导航至https://jub0bs.github.io/samesitedemo-attacker-foiled并单击该页面上的链接，因为攻击URI的站点（jub0bs.github.io）与目标URI的站点（jub0bs.com）不同），浏览器不会将cookie附加到由于链接导致的请求中，并且响应中不会打印出cookie。 SameSite = Strict可以按预期工作，并且“攻击”被挫败。
现在导航到https://samesitedemo-attacker.jub0bs.com/并点击该页面上的链接。由于攻击URI（jub0bs.com）的站点与目标URI（jub0bs.com）的站点相同，因此浏览器确实将cookie附加到跟随链接所导致的请求上，并且cookie确实在响应中打印出来。SameSite cookie属性根本不适用，在这种情况下，“攻击”成功了。
暗示将SameSite应用于所有跨域请求是有害的，因为它可能导致从业者错误地认为SameSite保护其用户免受所有跨域滥用。
这种误解对于忽视审查其子域的安全级别的从业者尤其危险。
在同一站点的子域上，足够绕过SameSite提供的相对保护。
子域接管是一种由Detectify于2014年流行的攻击，它利用子域上悬挂的DNS记录来控制该子域提供的部分或全部内容，攻击者可能会利用子域接管到各种目的：破坏，网络钓鱼等……但还有跨域攻击，否则将无法实现！
例如，如果攻击者能够接管https://vulnerable.example.org，则他或她可能可以将来自易受攻击子域提供的前端代码的恶意请求发送到https://example.org（或的任何子域）；并且此类请求在同一个站点中将携带所有相关的Cookie，无论其SameSite属性的值如何！
此类跨域相同站点攻击甚至可能不需要子域接管。同一站点子域中存在XSS漏洞可能是攻击者发送恶意跨域相同站点请求所需要的。
注意：在上述两种情况下，“跨站点请求伪造”都是用词不当，因为攻击站点和目标站点是相同的；“跨域请求伪造”（CORF？）更适合描述这种情况攻击，但我怀疑它能否实现通用。
我发现令人着迷的是，SameSite可能比过去更集中于精明的攻击者对您的子域和同级域的关注，因为这些域正迅速成为针对经过坚决战争的网站进行跨来源攻击的唯一避难所。
相反，这种误解也可能减慢Strict值对Lax的支持，确实有人积极劝阻从业者不使用Strict，因为他们认为Strict实际比实用性更大，例如，在Dareboost博客中，您可以读到
如果我们在dareboost.com上使用Strict Same-Site，则单击此链接，无论是否连接，都不会检测到您已登录。
该陈述是不正确的：相关链接位于https://blog.dareboost.com上，并指向https://www.dareboost.com；因此，通过单击该链接触发的请求将是同一站点并携带所有Cookie的范围为www子域或父域。
对于最终用户而言，此行为可能会造成混淆，因此您更喜欢使用Lax模式。
这只是贬低Strict值的一个示例，但是我敢肯定，您可以在网络上的其他地方找到更多信息。
我已经联系了我上面引用的所有人，他们认为他们对SameSite的力学描述不准确。我寄希望于特洛伊·亨特（Troy Hunt）的帖子发表公开评论，但他还没有回复我；我已经在Twitter上与Dareboost进行了联系，但我尚未对此发表强烈评论。听听他们的回音。
请记住：SameSite是一种强大的纵深防御机制，可保护用户免受跨站点攻击，但对跨源同站点攻击无能为力。请不要错过这一精妙之处！否则，如果您处于防御方面，则可能会陷入一种虚假的安全感，并且可能因您原本认为不可能的攻击而蒙蔽了双眼；如果您处于防御方面，则可能会错过漏洞调查结果，甚至还有相当大的错误赏金。
自从这篇文章的第一篇出版物发表以来，我发现在描述SameSite的机制时，更多地使用“起源”和“站点”一词是值得注意的例子。我没有尝试联系下面引用的文章的作者。
早在2016年，Qbit Cyber Security的Web应用程序黑客Sjoerd Langkemper在他的博客中写道：
下表显示了使用跨域请求发送的Cookie。您可以看到始终发送不具有相同站点属性[...]的Cookie。严格的cookie永远不会发送。宽松的cookie只与顶级get请求一起发送。
2018年5月，来自Google的Artur Janc和Mike West发布了一份报告（PDF），标题为“我们如何停止跨来源溢出豆类？”，您可以阅读以下内容：
SameSite cookie不会直接阻止攻击者加载跨域资源，但会导致此类请求在没有凭据的情况下发送，从而使攻击者获得的价值很小。 如果将此属性设置为“ strict”，则cookie将仅在相同来源的请求上发送，从而使CSRF无效。 我要感谢Detectify的Fredrik N. Almroth，他同意在发布之前审查此帖子的草稿。