Cookie与同站

发表于 2020-12-18 更新于 2024-09-17 分类于 Security Waline：

最近在重新看cookie的配置的时候，发现了它的一个新的配置，叫做sameSite。

这个sameSite的中文翻译就是同站。

我们今天就来看一下这个同站是什么，它和同源有什么区别，为什么cookie明明都有domain和path来规定作用域了还需要sameSite这个属性。

同源和同站

同源：协议（scheme）+ 主机名（hostname）+ 端口号（port）完全一致。
同站：eTLD+1 完全一致。

TLD 表示顶级域名，例如 .com、.org、.cn 等等，不过顶级域名并不是一成不变的，会随着时间推移增加，

TLD+1 表示顶级域名和它前面二级域名的组合，例如网址是：

1	https://www.example.com:443/foo

那么：

TLD 是 .com
TLD+1 是 example.com

但是，这种表示方式是有缺陷的，例如对于下面的网址：

1	https://www.example.com.cn

如果按照上面的规则，它的 TLD+1 就是 com.cn，并不能表示这个站点，真正能表示这个站点的应该是 example.com.cn 才对，所以衍生出 eTLD 的概念，即有效顶级域名：

eTLD：com.cn
eTLD+1：example.com.cn

注意，同源与跨域同级的概念
同站与跨站是相同的概念，比如著名的XSS和CSRF，都是跨站攻击

Cookie的作用域

Cookie有两个很重要的属性:Domain和Path，用来指示此Cookie的作用域：

Domain 告诉浏览器当前要添加的 Cookie 的域名归属，如果没有明确指明，则默认为当前域名，比如通过访问 www.baidu.com 添加的 Cookie 的域名默认就是www.baidu.com，通过访问[www.baidu.com 所生成的 Cookie 的域名就是www.baidu.com

Path 告诉浏览器当前要添加的Cookie的路径归属，如果没有明确指明则默认为当前路径，比如通过访问 www.baidu.com/java/hotspot.html 添加的 Cookie 的默认路径就是/java/,通过 www.baidu.com/java/hotspot.html 生成的 Cookie 的路径也是 /java/

浏览器提交的Cookie需要满足以下两点：

当前域名或者父域名下的Cookie；
当前路径或父路径下的Cookie

CSRF

搞明白了同站和Cookie的作用域是什么，我们再来看看CSRF的攻击方式。

Cookie是我们用来应对HTTP无状态的一种解决方案，通过将一些用户信息存储在浏览器，然后在接下来的请求中自动携带cookie来达到让HTTP请求携带状态的目的。

Cookie 往往用来存储用户的身份信息，恶意网站可以设法伪造带有正确 Cookie 的 HTTP 请求，这就是 CSRF 攻击。

举例来说，用户登陆了银行网站your-bank.com，银行服务器发来了一个 Cookie。

1	Set-Cookie:id=afasdfafa;

用户后来又访问了恶意网站evil.com，上面有一个表单。

1
2
3

<form action="your-bank.com/transfer" method="POST">
  ...
</form>

用户一旦被诱骗发送这个表单，由于请求的目标是银行，所以就会自动携带上cookie中在银行的domain和path下的内容，银行网站就会收到带有正确 Cookie 的请求。为了防止这种攻击，表单一般都带有一个随机 token，告诉服务器这是真实请求。

<form action="your-bank.com/transfer" method="POST">
  <input type="hidden" name="token" value="dad3weg34">
  ...
</form>

这种第三方网站引导发出的 Cookie，就称为第三方 Cookie。它除了用于 CSRF 攻击，还可以用于用户追踪。

比如，Facebook 在第三方网站插入一张看不见的图片。

1	<img src="facebook.com" style="visibility:hidden;">

浏览器加载上面代码时，就会向 Facebook 发出带有 Cookie 的请求，从而 Facebook 就会知道你是谁，访问了什么网站。

SameSite属性

Chrome 51 开始，浏览器的 Cookie 新增加了一个SameSite属性，用来防止 CSRF 攻击和用户追踪。

但是既然cookie已经有了domain和path，为什么还需要一个sameSite呢？

其实是因为sameSite限制的并不是cookie的作用域，作用域限制的是当我一个请求想要携带cookie时，它能获取到什么cookie，这个叫作用域，而sameSite限制的是如果从我的页面发出去一个请求，我是否允许它携带cookie

举个例子，我自己的博客页面有一条指向淘宝的链接，无论这条链接是我自己贴的，还是被XSS注入的，反正有这么条连接，如果我在我的博客点击了这条链接，由于我的博客和淘宝是不同站的，所以sameSite的限制根本就不会允许这个请求携带cookie，如果没有sameSite的限制，才会进一步去根据作用域看看有什么允许的cookie。

Cookie 的SameSite属性用来限制第三方 Cookie，从而减少安全风险。

它可以设置三个值。

Strict
Lax
None

Strict

Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。

1	Set-Cookie: CookieName=CookieValue; SameSite=Strict;

这个规则过于严格，可能造成非常不好的用户体验。比如，当前网页有一个 GitHub 链接，用户点击跳转就不会带有 GitHub 的 Cookie，跳转过去总是未登陆状态。

Lax

Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。

1	Set-Cookie: CookieName=CookieValue; SameSite=Lax;

导航到目标网址的 GET 请求，只包括三种情况：链接，预加载请求，GET 表单。详见下表。

请求类型	示例	正常情况	Lax
链接	`<a href="..."></a>`	发送 Cookie	发送 Cookie
预加载	`<link rel="prerender" href="..."/>`	发送 Cookie	发送 Cookie
GET 表单	`<form method="GET" action="...">`	发送 Cookie	发送 Cookie
POST 表单	`<form method="POST" action="...">`	发送 Cookie	不发送
iframe	`<iframe src="..."></iframe>`	发送 Cookie	不发送
AJAX	`$.get("...")`	发送 Cookie	不发送
Image	`<img src="...">`	发送 Cookie	不发送

设置了Strict或Lax以后，基本就杜绝了 CSRF 攻击。当然，前提是用户浏览器支持 SameSite 属性。

None

Chrome 计划将Lax变为默认设置。这时，网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。

下面的设置无效。

1	Set-Cookie: widget_session=abc123; SameSite=None

下面的设置有效。

1	Set-Cookie: widget_session=abc123; SameSite=None; Secure

参考链接：

https://juejin.cn/post/6877496781505200142

https://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html