SameSite深度拆解：从概念到绕过，赏金挖洞必备

原创

升斗安全XiuXiu
升斗安全XiuXiu

升斗安全

2026年7月13日 07:58
广东

在小说阅读器读本章

去阅读

【文章说明】

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

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

当SameSite这道“安全门”形同虚设

想象一下，你正盯着目标站点的请求记录，发现一个有趣的接口，它允许修改用户的关键设置，但Cookie上赫然标着SameSite=Lax。你叹了口气，准备放弃。

别急。这道墙，其实有很多扇没锁好的窗。

在正式开始玩转这些绕过技巧之前，咱们得先把SameSite这个“门卫”的脾气摸透。说实话，我刚接触这玩意儿的时候也觉得它绕来绕去特别烦，但搞明白之后，你会发现它留的“后门”比想象中多得多。

SameSite到底是什么？

简单说，SameSite是浏览器里一个管Cookie的规矩，它决定你从A站向B站发请求时，B站的Cookie要不要跟着过去。这本来是用来防CSRF这类跨站攻击的，相当于浏览器在说：“不是你本站发起的请求，别想带我的Cookie进门。”

自2021年起，Chrome就立了条规矩：你要是不明说SameSite设成啥，我就默认给你上Lax。其他浏览器也差不多都跟进了。所以现在搞渗透测试，不懂这个机制的弯弯绕绕，会错过不少好东西。

“站点”到底怎么算？不是你想的那样

在SameSite这套话语体系里，“站点”不是随便说说的。它指的是顶级域名再加一级，俗称TLD+1。比如example.com是一个站点，app.example.com和intranet.example.com在这个定义下，属于同一个站点。

还有一点容易被忽略：协议也算。http://app.example.com向https://app.example.com发请求，浏览器眼里这是跨站，不是同站。

另外你可能会看到“eTLD”（有效顶级域名）这种说法，这是为了处理.co.uk这种“一个顶俩”的后缀。知道有这回事就行，不影响咱们实操。

站点 vs 源：搞混了会出大问题

这俩词新手特别容易混着用，但它们的安全含义完全不同。

• 同源：协议、域名、端口，三位一体完全一样，才算同源。
• 同站：只看协议和TLD+1，宽松得多。

看几个例子你就明白了：

看出门道了吗？跨源不一定是跨站，但跨站一定是跨源。 这个特性可以直接拿来玩。

假如你在app.example.com上找到一个XSS漏洞，能执行任意JavaScript，那你就可以拿它当跳板，向同一个站点下的intranet.example.com发起“同站”请求。从SameSite的角度看，这是合法的，Cookie会乖乖带上。等于你攻破一个子域，就能横向打到整个站点内的其他应用。

我们后面会分享复现这种的打法，到时候你会更直观地感受到这个技巧有多香。

说到这，SameSite的基础脉络应该清晰了。记住，它防的是跨站请求里夹带Cookie，但“站点”的定义本身就留了不少操作空间。下次挖洞遇到带着SameSite标记的Cookie，别急着跳过，先看看目标的域名结构，说不定你手里的某个子域漏洞，就是打开主站的钥匙。

觉得有收获的话，点赞、在看、转发三连走起，别让这篇文章躺在收藏夹里吃灰。推荐给一起挖洞的兄弟，下次出高危别忘了回来报喜。