Cookie的SameSite属性，如何影响cookie的传递？

我们相信：世界是美好的，你是我也是。 来玩一下解压小游戏吧！

说起csrf攻击的问题，就引申出了cookie的一个属性samesite。很久之前，古老版本的浏览器里面，这个属性默认值是none，导致很多csrf攻击现象的发生。而现在的主流浏览器里面，cookie的samesite默认值是lax，从浏览器层面上就阻止了绝大多数的csrf攻击情况。

苏南大叔的“程序如此灵动”博客，记录苏南大叔的代码编程经验总结。测试环境：win10，chrome@135.0.7049.41。本文的主要观点是：对于普通的“网站之间做a连接”的情况，cookie的samesite属性，如何影响cookie的传递，进而影响登陆鉴权。

samesite取值

Cookie的SameSite属性‌，用于防范CSRF攻击和用户追踪。该属性有三个值：Strict、Lax和None。

*‌ Strict‌：严格限制第三方Cookie，跨站点时任何情况下都不会发送cookie，只有在当前网页的URL与请求目标一致时才会带上Cookie。这种设置过于严格，可能会导致用户体验不佳，例如在点击链接跳转到其他网站时，用户可能会失去登录状态。

*‌ Lax‌：在大多数情况下禁止获取cookie，除非是通过链接、预加载或GET请求（如链接、预加载、GET表单）导航到目标网址时才会发送。这种设置可以有效防范CSRF攻击，同时减少对用户体验的影响。

‌* None‌：没有限制，但必须配合Secure属性使用。这意味着目标站点必须是https的，而恶意站点无此要求。这种设置允许Cookie在跨站点请求中发送，但需要确保使用HTTPS以防止中间人攻击。

一般来说，程序员是不会设置这个SameSite属性的。历史上的原因：

• 以前的时候，浏览器该属性的默认值是None，对目标站点的情况，任何时候无条件的都会带上cookie。
• 而现在其默认值是Lax，意思是有条件有选择性的带上cookie。
• 很少有人设置strict，这个比较严格，不符合常理。

测试场景：普通链接

两个站点之间控制数据流动的方式，有很多种。本文先抛开csrf这个概念，先来说说最常见最普通最正常的情况：链接<a>。

三个页面：
0，站点v的登陆检测页面，实际上就是用于检测cookie是否被传递。
1，站点v执行登陆动作，设置cookie，然后链接到登陆检测页面。
2，站点b做连接到登陆检测页面，等待用户点击。

两种协议：
本文的测试环境，站点v配置了http和https两种。除了None的情况，其它选项下，并不影响实验结果。

测试方式：
为了更好的控制逻辑，v/login页生成cookie之后，再通过f12修改cookie的SameSite属性变化。

Strict【最异常】

在这个SameSite='Strict'的检测过程中，在同一个浏览器内，v登陆后：

• 站点h打开v/check页面，无论如何都检测不到登陆状态。
• 但是，通过站点v打开v/check页面后，无论什么样的访问方式（包括通过站点h打开），都是登陆状态。

Lax【默认】

在这个SameSite='Lax'的检测过程中，在同一个浏览器内，v登陆后：

• 站点h打开v/check页面，可检测到登陆状态。
• 站点v打开v/check页面，可检测到登陆状态。

None【需要https】

现在浏览器要求SameSite为None的时候，必须搭配secure为1，间接要求站点使用https协议。

在这个SameSite='None'的检测过程中，在同一个浏览器内：

• 站点v使用https协议，恒定能检测到登陆状态。
• 站点v使用http协议，无法生成None的cookie，【恒定】检测不到登陆状态，相当于cookie恒定失效。

结论

本文的SameSite的概念，和cookie的httponly属性，是有些相似的。参考文章：

• https://newsn.net/say/cookie-httponly.html

如果本文对您有帮助，或者节约了您的时间，欢迎打赏瓶饮料，建立下友谊关系。
本博客不欢迎：各种镜像采集行为。请尊重原创文章内容，转载请保留作者链接。