文章总结： 本文以通俗语言介绍浏览器SameSitecookie机制，解释Strict、Lax、None三个属性对跨站请求携带cookie的影响。重点指出Lax为Chrome默认值，能有效防御多数CSRF攻击；而部分开发者将敏感cookie设为None留下漏洞，赏金猎人可据此测试CSRF。文章强调检查cookie的SameSite属性是评估站点CSRF防护水平的关键细节，并提供可操作建议。 综合评分： 80 文章分类： web安全,渗透测试,安全意识,实战经验,漏洞分析

赏金猎人的SameSite扫盲贴：别再因为看不懂Cookie错失漏洞

原创

升斗安全XiuXiu 升斗安全XiuXiu

升斗安全

2026年7月14日 07:52 广东

在小说阅读器读本章

去阅读

【文章说明】

• 目的：本文内容仅为网络安全技术研究与教育目的而创作。
• 红线：严禁将本文知识用于任何未授权的非法活动。使用者必须遵守《网络安全法》等相关法律。
• 责任：任何对本文技术的滥用所引发的后果自负，与本公众号及作者无关。
• 免责：内容仅供参考，作者不对其准确性、完整性作任何担保。

阅读即代表您同意以上条款。

哥们儿，今天咱们来聊个在挖洞时特别实用，但又被很多人忽略的浏览器安全机制【SameSite】。别看它名字听起来挺唬人，其实弄懂之后，你在测试CSRF漏洞时心里会更有底。

SameSite 这玩意儿到底是干啥的？

简单说，在没有 SameSite 之前，浏览器就跟个憨憨似的，不管是谁让你发请求，只要你浏览器里有目标网站的 Cookie，它就毫不犹豫地给你带上。比如说，你正逛着某个论坛，后台悄悄加载了一张图片，这图片的链接其实指向你的银行转账接口。这时候，浏览器二话不说就把你之前在浏览器中使用过的银行的登录凭证（Cookie）也一并送过去了，后果你懂的。

SameSite 的出现，就是给这个“憨憨”加了个看门大爷，让开发者可以自己决定：哪些跨站请求能带 Cookie，哪些不行。这样一来，攻击者想靠伪造请求来搞事的难度就大多了。

现在主流的浏览器都支持三个档位的 SameSite 限制，咱们一个个看，我用人话给你翻译翻译。

Strict（铁面无私档）

一旦 Cookie 被设成 SameSite=Strict，浏览器就彻底跟它杠上了：只要不是从原站点发起的请求，管你是点链接、加载图片还是发 AJAX，通通不给带 Cookie。

比如你在浏览器地址栏里看到的是 forum.com，这时候如果有任何请求是发往 bank.com 的，那 bank.com 设了 Strict 的 Cookie 压根不会出现在请求里，就好像它根本不存在。

这档位最安全，适合那种“碰一下就能改密码、转账”的高危 Cookie。但代价也很明显，有时候用户体验会打折扣，比如你从邮件里点个链接跳过去，可能会发现自己是未登录状态，因为那个 Cookie 没带上。

Lax（睁一只眼闭一只眼）

这是现在 Chrome 的默认档位，也是平衡性最好的一档。Lax 的规则很简单，它允许带 Cookie 的情况只有两个条件同时满足：

• 请求方法是 GET（也就是读操作，不改数据）。
• 这个请求是用户主动点的链接导航（顶级导航）。

说白了，你从别处点个链接跳到目标网站，GET 请求会带上 Cookie，让你不至于一过去就是登录页，体验保住了。但是，那些藏在背后的请求，比如  加载、iframe 里的小动作、script 发起的请求，还有所有 POST 请求，统统不给带。

为啥要卡 POST？因为按照最佳实践，删数据、改密码、转账这些操作都应该用 POST，而 POST 恰恰是 CSRF 攻击的重灾区。所以 Lax 这招，等于直接把 CSRF 最常用的大门给焊死了大半扇。

None（大门敞开档）

SameSite=None 就相当于彻底躺平，不设防。只要请求是发往签发站点的，不管是从哪来的、用什么方法，Cookie 都照发不误。

在 Chrome 之外的一些浏览器里，默认行为其实就是这个档位。虽然听起来很危险，但有时候确实有正当理由，比如那些跨站用的追踪 Cookie，它们本身不涉及敏感数据，就是用来记录用户行为的。

不过，咱们挖洞的时候要特别留个心眼儿：当年 Chrome 刚把默认行为改成 Lax 的时候，好多网站的老功能直接崩了。于是有些开发者图省事，干脆一刀切，把所有 Cookie 都设成 None，包括那些本该严加看管的会话 Cookie。这就给咱们赏金猎人留下了可乘之机，碰到这种 Cookie，不妨多测测 CSRF，说不定有惊喜。

另外记住一点：设 SameSite=None 必须同时带上 Secure 属性，强制走 HTTPS，不然浏览器直接拒绝这个 Cookie。所以你会看到这样的响应头：

Set-Cookie: trackingId=0F8tgdOhi9ynR1M9wa3ODa; SameSite=None; Secure

最后还得泼盆冷水：SameSite 虽然能防住一大票常规 CSRF 攻击，但它不是无敌盾。后面我会分享更多的案例，看看在某些精巧构造的场景下，SameSite 是怎么被绕过的。学完理论再实操，这感觉才到位。

搞懂了 SameSite 的这三档设置，下次你在做渗透测试或者挖 SRC 的时候，看到一个 Cookie，先瞅瞅它的 SameSite 属性，心里大概就能判断出这站点的 CSRF 防护底子在什么水平了。是铁板一块，还是有缝可钻，往往就在这些细节里。

如果今天这篇内容让你对 SameSite 的理解清晰了那么一点，别藏着掖着，点个赞、点个“在看”，让更多一起挖洞的兄弟看到。也欢迎转发给身边的赏金猎人朋友，好东西一起分享，挖洞路上不孤单。还没关注的赶紧关注一波，后续我会持续输出更多这种“人话版”的安全硬货，带你扎扎实实地把技术底子打牢。咱们下篇见！

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：升斗安全 升斗安全XiuXiu 升斗安全XiuXiu《赏金猎人的SameSite扫盲贴：别再因为看不懂Cookie错失漏洞》