关于http:SameSite-那些事

3次阅读

共计 5016 个字符，预计需要花费 13 分钟才能阅读完成。

在《Web 安全漏洞之 CSRF》中咱们理解到，CSRF 的实质实际上是利用了 Cookie 会主动在申请中携带的个性，诱使用户在第三方站点发动申请的行为。除了文中说的一些解决形式之外，规范还专门为 Cookie 减少了 SameSite 属性，用来躲避该问题。Chrome 于 2015 年 6 月反对了该属性，Firefox 和 Safari 紧随其后也减少了反对。SameSite 属性有以下几个值：

SameSite=None：无论是否跨站都会发送 Cookie
SameSite=Lax：容许局部第三方申请携带 Cookie
SameSite=Strict：仅容许同站申请携带 Cookie，即以后网页 URL 与申请指标 URL 完全一致

该属性适宜所有在网页下的申请，包含但不限于网页中的 JS 脚本、图片、iframe、接口等页面内的申请。能够看到 None 是最宽松的，和之前的行为无异。而 Lax 和 Strict 都针对跨站的状况下做了限度。其中 Strict 最为严格，不容许任何跨站状况下携带该 Cookie。Lax 则绝对宽松一点，容许了一些显式跳转后的 GET 行为携带。以下是一个带有 SameSite 属性的规范 Cookie 响应示例：

Set-Cookie: name=lizheming; SameSite=None; Secure

须要留神的是，浏览器做了仅针对 HTTPS 域名才反对 SameSite=None 配置。所以如果你要设置 SameSite=None 的话，则必须还要携带 Secure 属性才行。

Same Site 直译过去就是同站，它和咱们之前说的同域 Same Origin 是不同的。两者的区别次要在于判断的规范是不一样的。一个 URL 次要有以下几个局部组成：

能够看到同域的判断比拟严格，须要 protocol, hostname, port 三局部完全一致。相对而言，Cookie 中的同站判断就比拟宽松，次要是依据 Mozilla 保护的公共后缀表（Pulic Suffix List）应用无效顶级域名(eTLD)+ 1 的规定查找失去的一级域名是否雷同来判断是否是同站申请。

例如 .org 是在 PSL 中记录的无效顶级域名，imnerd.org 则是一级域名。所以 https://blog.imnerd.org 和 https://www.imnerd.org 是同站域名。而 .github.io 也是在 PSL 中记录的无效顶级域名，所以 https://lizheming.github.io 和 https://blog.github.io 失去的一级域名是不一样的，他们两个是跨域申请。

在相似 GitHub/GitLab Pages, Netlify, Vercel 这种提供子域名给用户建站的第三方服务中，eTLD 的这种同站判断个性往往十分有用。通过将本来是一级域的域名增加到 eTLD 列表中，从而让浏览器认为配有用户名的残缺域名才是一级域，无效解决了不同用户站点的 Cookie 共享的问题。

eTLD 的全称是 effective Top-Level Domain，它与咱们平常了解的 Top-Level Domain 顶级域名有所区别。eTLD 记录在之前提到的 PSL 文件中。而 TLD 也有一个记录的列表，那就是 Root Zone Database。RZD 中记录了所有的根域列表，其中不乏一些奇奇怪怪形形色色的后缀。

eTLD 的呈现次要是为了解决 .com.cn, .com.hk, .co.jp 这种看起来像是一级域名的但其实须要作为顶级域名存在的场景。这里还能够分享一个乏味的事件，2020 年 5 月份呈现了一起阿里云所有 ac.cn 后缀网站解析全副挂掉的事件。起因就是 ac.cn 是中科院申请在册的 eTLD 域名。而阿里云的检测域名备案的脚本不理解标准，没有应用 PSL 列表去查找一级域名，而是应用了 . 宰割的模式去查找的。最终所有 *.ac.cn 的域名因为 ac.cn 这个域名没有进行备案导致解析全副挂掉。而咱们当初晓得 ac.cn 这个域名是 eTLD 域名，它必定是无奈备案的。

在 Chrome 86/Firefox 79 中，浏览器减少了一个 Schemeful Same Site 的选项，将协定也减少到了 Same Site 的判断规定中。然而并不是齐全的不等判断，能够了解是否有 SSL 的区别。例如 http:// 和 https:// 跨站，但 wss:// 和 https:// 则是同站，ws:// 和 http:/ 也算是同站。

Chrome 能够浏览器输出 chrome://flags/#schemeful-same-site 找到配置并开启。

咱们晓得互联网广告通过在固定域 Cookie 下标记用户 ID，记录用户的行为从何达到精准举荐的目标。随着寰球隐衷问题的整治，同时也是为了更好的躲避 CSRF 问题，在 Chrome 80 中浏览器将默认的 SameSite 规定从 SameSite=None 批改为 SameSite=Lax。设置成 SameSite=Lax 之后页面内所有跨站状况下的资源申请都不会携带 Cookie。因为不会为跨站申请携带 Cookie，所以 CSRF 的跨站攻打也无从谈起，广告商也无奈固定用户的 ID 来记录行为。

对用户来说这必定是一件坏事。然而对咱们技术同学来说，这无疑是上游给咱们设置的一个阻碍。因为业务也的确会存在着多个域名的状况，并且须要在这些域名中进行 Cookie 传递。例如多站点应用 SSO 登录、接入对立的验证码服务、前端和服务端接口属于两个域名等等状况，都会因为这个批改受到影响。

这个批改影响面宽泛，须要网站维护者花大量的工夫去批改适配。而 Chrome 80 于 2020 年 2 月公布后寰球就开始面临新冠疫情的影响。思考到疫情问题后续的版本里又临时先回退了这个个性（相干链接），最终是在 Chrome 86 进行了全量操作。

针对因为此次个性受到影响的网站，能够抉择以下一些适配方法：

应用 JWT 等其它非 Cookie 的通信形式
为 Cookie 减少 SameSite=None;Secure 属性配置
所有的跨域接口减少 Nginx 代理，使其和页面放弃同域

每一种办法都须要一些取舍。第一种更换 Cookie 的形式革新老本十分高，特地是在有内部业务对接的状况下根本不可能。第三种形式通过将跨域变为同域的转发形式可能会带来线上流量的成倍增加，也是须要思考的因素。第二种设置成 None 看起来是比较简单的方法，不过也有着诸多的限度。

SameSite=None;Secure 因为仅反对 HTTPS 页面，所以如果有 HTTP 的场景须要思考跳转至 HTTPS 或者抉择其余计划；
因为 SameSite 属性是起初才退出的，一些老浏览器（其实就是 IE）会疏忽带有这些属性的 Cookie，所以须要同时下发未配置 SameSite 属性和配置 SameSite 属性的两条 Set-Cookie 响应头，这样反对和不反对的会各取所需；
在 Safari 的某些版本中会将 SamteSite=None 等同于 SameSite=Strict 所以局部 Safari 场景须要非凡解决不进行下发（相干链接）；

综上应用代理转发的形式是我比拟举荐的形式，除了不那么绿色之外兼容问题解决还是不错的。

SameSite=None 断了咱们跨站传递 Cookie 的念想，但理论业务上的确有这种场景。例如 Google 本人就有十分多的域名，这些域名如果都须要共享登录 Cookie 的话可能就会十分艰难了。针对这种某个实体领有多个域名须要共享 Cookie 的状况，就有人（那其实就是 Google 的同学）提出了 [SameParty](
https://github.com/cfredric/s… 的概念。

该提案提出了 SameParty 新的 Cookie 属性，当标记了这个属性的 Cookie 能够在同一个主域下进行共享。那如何定义不同的域名属于同一主域呢？次要是依赖了另外一个个性 first-party-set 第一方汇合。它规定在每个域名下的该 URL /.well-known/first-party-set 能够返回一个第一方域名的配置文件。在这个文件中你能够定义以后域名从属于哪个第一方域名，该第一方域名下有哪些成员域名等配置。

当然应用固定 URL 会产生额定的申请，对页面的响应造成影响。也能够间接应用 Sec-First-Party-Set 响应头间接指定归属的第一方域名。

不过 W3C TAG 小组曾经强烈回绝了该提案（起源）。W3C 认为该提案从新定义了网站沙箱的边界，带来的影响可能不仅仅只是 Cookie 共享这么简略，包含麦克风、摄像头、地理信息等隐衷设置都须要去从新评估影响。

同时该提案可能会和用户的预期不统一，如果 Google 和 Youtube 被定义成第一方网站进行共享的话，那 Google 就能很轻松的获取到用户在 Youtube 上的行为，可能用户并不想要这样。

W3C TAG 小组全称是 Technical Architecture Group，即 W3C 技术架构组。TAG 是 W3C 专一于 Web 架构治理的非凡小组。其使命是为 Web 架构的设计准则寻求共识，且在必要时梳理并廓清这些设计准则，帮忙协调 W3C 外部及内部逾越不同技术的架构定义与研发工作。根本能够认为它是 Web 根底标准定义的小组。另外万维网之父 Tim Berners-Lee 也在 TAG 小组中。

不过 W3C 说的有理没理，都阻挡不了 Chrome 去实现这个性能。在 Chrome 89 中曾经减少了 SameParty 的相干逻辑，只是目前没有默认开启。目前在 DevTools 中是能够看到 Cookie 的 SameParty 属性列的。Edge 因为应用了 Chromium 也在同版本反对了该性能。只主持了标准，没有主持实现，当某一方浏览器实现了“霸权”的状况下，W3C 的处境就变得难堪了起来。

SameSite 除了影响单实体多域名共享 Cookie 的状况，最大的问题其实就是互联网广告获取用户行为了。因为广告挂载页面和广告不在同域，所以广告无奈取得用于标记用户 ID 从而对用户行为进行聚类。为了解决这个问题，有人（其实也是 Google 的同学）提出了 Federated Learning of Cohorts 同盟学习队列提案。

有别于之前应用 Cookie ID 标记间接将用户行为数据传递到广告商网站解决的形式。它提出了 document.interestCohort() 这个新的 API，将用户的行为在本地转换成了不带个人隐私的关键词，既躲避了用户隐衷问题，同时又解决了广告的精准投放问题。

不过这看似美妙的货色却受到了各大网站和浏览器的强力抵制，brav、Vivaldi、duckduckgo、GitHub 以及 Edge，Firefox，Safari（起源）都纷纷发表了回绝反对的观点和口头。

社区次要的放心点在于，新的个性的减少可能会减少特征值为隐衷嗅探提供了更广大的入口。而且通过该 API 能获取到之前碍于权限无奈程序获取的用户浏览数据。目前 Chrome 曾经反对了这个性能，不过须要开启 Flag 能力反对。amIFLoCed 是一个用来检测你的浏览器是否开启了 FLoC 追踪个性的网站，能够应用它检测你的浏览器是否利用该个性。

为了解决 CSRF 问题，Chrome 强推了 SameSite=Lax 作为默认配置。随之而来的，不仅是寰球开发者的配合批改，还造成了已有场景的无奈满足。而为了满足现有场景，又提出了 SameParty 和 FLoC 两个计划。这种行为不知是否成为浏览器的内卷行为？

SameSite 属性自身是没有什么问题的，但集体认为它应该是一种 CSRF 问题的抉择计划，浏览器将其默认批改成 SameSite=Lax 就有点好受了。大部分企业我的项目里都曾经采纳其余 CSRF 防备形式躲避了该问题，而 Lax 配置又存在着兼容性问题，不能让咱们齐全免顾 CSRF 之忧。

随着寰球隐衷问题的白热化，不晓得还有什么新的提案搞进去须要咱们寰球开发者为其买单。

参考资料：