cookie的samesite机制

站点和源站的区别在于它们的范围；站点包含多个域名，而源站只包含一个域名。

|---------------------------|--------------------------------|-------------|---------|
| 请求来自 | 请求 | 同一地点？ | 同源？ |
| https://example.com | https://example.com | 是的 | 是的 |
| https://app.example.com | https://intranet.example.com | 是的 | 否：域名不匹配 |
| https://example.com | https://example.com:8080 | 是的 | 否：端口不匹配 |
| https://example.com | https://example.co.uk | 否：eTLD 不匹配。 | 否：域名不匹配 |
| https://example.com | http://example.com | 否：方案不匹配 | 否：方案不匹配 |

如果发出 cookie 的网站没有明确设置SameSite属性，Chrome 默认会自动Lax应用限制。这意味着 cookie 只会在符合特定条件的跨站请求中发送，即使开发者从未配置过此行为。由于这是一个拟议的新标准，我们预计其他主流浏览器未来也会采用这种行为。

SameSite你可以把它理解成：

浏览器给 Cookie 加的一道"跨网站使用限制"。

比如你登录：

bank.example

浏览器拿到：

Set-Cookie: session=ABC123; SameSite=Lax

现在你打开另一个网站：

evil.example

evil.example 想让你的浏览器请求：

https://bank.example/my-account/change-email

这时候就产生了：

evil.example
       ↓
bank.example

这是一个跨站请求。

浏览器就会问：

"bank.example 的 session Cookie 是 SameSite=Lax，我现在这个请求属于什么类型？我要不要带 Cookie？"

这就是 SameSite 发挥作用的地方。

SameSite 有三个主要级别

Strict 最严格，Lax 放行部分安全的跨站 GET，None 基本不限制跨站发送。

SameSite	跨站请求是否带 Cookie	典型特点
Strict	❌ 基本不带	最严格
Lax	⚠️ 部分情况带	跨站 GET 顶级导航通常可以带
None	✅ 可以带	允许跨站使用，但必须 Secure

1. SameSite=Strict

Set-Cookie: session=abc; SameSite=Strict

可以理解成：

同站请求 → Cookie ✅
跨站请求 → Cookie ❌

即使用户从其他网站点击链接进入目标网站，也不会在这个跨站导航请求中带上这个 Cookie。

---

2. SameSite=Lax

Set-Cookie: session=abc; SameSite=Lax

这是你刚才那个 CSRF Lab 的关键。

大致记：

跨站 POST → Cookie ❌
跨站 fetch → Cookie ❌
跨站 GET 顶级导航 → Cookie ✅

例如：

location = "https://victim.com/account"

这是顶级导航，因此浏览器可以带上 victim.com 的 Lax Cookie。

所以你那个 Lab 才能利用：

GET
+
顶级导航
+
SameSite=Lax

拿到登录状态。

---

3. SameSite=None

Set-Cookie: session=abc; SameSite=None; Secure

意思基本是：

跨站请求 → 允许发送 Cookie ✅

但是现代浏览器要求：

SameSite=None
        +
Secure

也就是通常必须通过 HTTPS 使用。