关于cookies:记一次Chrome更新带来的登录Cookie问题

事件起因

环境

首先介绍下根本信息：公司的某个业务零碎是 h.xxx.com，登录走的通过iframe 嵌入的网页passport.xxx.com。

本地开发环境下，业务零碎只反对 http 协定，所以对应拜访地址为http://h.xxx.com，登录接口始终是https://passport.xxx.com。

这样就是一个跨协定的状况了。

问题

某一天，有同学登录零碎后始终提醒“你未登录，请先登录 B 站”，而且并不是所有人有该问题。

通过一系列排查，发现惟一的区别只有 Chrome 浏览器版本不统一（应用局部其余浏览器也是没有问题的）。

结案

从 v88 降级到 v89 后，Chrome浏览器内置的 schemeful-same-site 规定默认值改为启用，导致跨协定也被认定为跨站 (cross-site)，cookies 无奈传递。

长期解决方案：地址栏关上chrome://flags/#schemeful-same-site，将选项设置为Disabled。

在 Chrome 80 版本，SameSite的默认值被改为Lax。

Same-Site 的概念

eTLD+1局部统一就能够称之为same-site。

scheme和 eTLD+1 局部统一则被称为schemeful same-site

上面是一些 schemeful same-site 的案例：

Schemeful Same-Site

Schemeful Same-Site 是 same-site 的进阶版，通过协定 + 域名两个维度来定义，如果想深刻理解下，你能够浏览这篇文章：Understanding ‘same-site’ and ‘same-origin’。

这意味着 http://website.example 和 https://website.example 相互之间是跨站 (cross-site) 的。

如果你的网站曾经全副应用 HTTPS，那Schemeful Same-Site 不会有任何影响，否则应该尽快降级到HTTPS。

如果你的我的项目同时应用 HTTP 和HTTPS，那就很有必要理解相干规定，接下来将介绍一些场景以及与之对应的 cookie 行为。

以前能够通过设置 SameSite=None; Secure 来容许 跨协定 的cookies传输，原作者倡议不要应用这个长期解决方案，应该尽快全站部署HTTPS，事实上也的确是这样的，就像前文的登录问题，你永远不晓得浏览器给你的下一个“惊喜”是什么。

浏览器相干设置

Chrome和 Firefox 上提供了 schemeful-same-site 的配置入口。

• Chrome 86 开始，批改 chrome://flags/#schemeful-same-site 选项为 Enabled 即是启用。
• Firefox 79 开始，关上 about:config 批改 network.cookie.sameSite.schemeful选项为true。

在以前的浏览器更新中，为了避免跨站申请伪造 (CSRF) 攻打，曾经将 SameSite=Lax 设置为默认项。

然而攻击者还是能通过不平安的 HTTP 协定篡改 cookies，影响到也应用同样cookies 的HTTPS页面。

schemeful-same-site也就应运而生。

常见的跨协定场景

导航跳转

之前两个跨协定同域名的页面跳转是容许携带设为 SameSite=Strict 的cookies。

当初不同协定被认定为跨站 (cross-site)，所以设为SameSite=Strict 的cookies就被阻挡了。

加载子资源

支流浏览器都会阻止 active mixed content（主动型混合内容），如 scripts、iframe。Chrome 和Firefox浏览器正在尝试降级或阻止passive mixed content(被动型混合内容)。

子资源（subresources）包含图片，iframes 以及 XHR、Fetch申请

之前如果一个页面加载了跨协定的资源，他们之间是能够共享设为 SameSite=Strict、SameSite=Lax 的cookies。

然而当初两者通通被浏览器阻止，无奈传输共享。

另外即便 HTTPS 可能加载 HTTP 资源，所有的 cookies 还是会被阻止。

POST 表单提交

以前跨协定的 POST 申请是能够携带设为 SameSite=Lax 或SameSite=Strict的cookies。

当初只有设置为 SameSite=None 的cookies能够在表单申请时被发送。

如何在网页上测试

Chrome和 Firefox 上的开发者工具都曾经反对相干配置，并且会在控制台给出提醒。

Chrome 86版本开始，DevTools->Issue显示对于 Schemeful Same-Site 的高亮提醒。

Navigation issues:

• “Migrate entirely to HTTPS to continue having cookies sent on same-site requests”—A warning that the cookie will be blocked in a future version of Chrome.
• “Migrate entirely to HTTPS to have cookies sent on same-site requests”—A warning that the cookie has been blocked.

子资源加载issues：

• “Migrate entirely to HTTPS to continue having cookies sent to same-site subresources” or “Migrate entirely to HTTPS to continue allowing cookies to be set by same-site subresources”—Warnings that the cookie will be blocked in a future version of Chrome.
• “Migrate entirely to HTTPS to have cookies sent to same-site subresources” or “Migrate entirely to HTTPS to allow cookies to be set by same-site subresources”—Warnings that the cookie has been blocked. The latter warning can also appear when POSTing a form.

详情能够浏览 Testing and Debugging Tips for Schemeful Same-Site。

Firefox 79 版本开始，network.cookie.sameSite.schemeful设置为 true 后，控制台也会出现相干信息：

• “Cookie cookie_name will be soon treated as cross-site cookie against http://site.example/ because the scheme does not match.”
• “Cookie cookie_name has been treated as cross-site against http://site.example/ because the scheme does not match.”

FAQ

我的网页曾经应用HTTPS，为什么还会看到issues？

很可能是网页内的一些链接或资源还是指向不平安的地址。

其中一个解决办法就是应用 HTTP Strict-Transport-Security (HSTS) + includeSubDomain。

应用 HSTS + includeSubDomain 计划之后，即使你的页面里还存在不平安的链接，浏览器会主动替换平安的协定拜访。

如果我无奈降级到 HTTPS

能够调整 SameSite 的设置，放宽限度。

• 只有 SameSite=Strict 的cookies被阻止时，你能够调整为SameSite=Lax
• 设置为 Strict 或Lax的 cookies 均被阻止，同时 cookies 是发送到平安 URL 的，把设置为 None 后就能够失效。

如果 cookies 没有设置 SameSite 属性？

没有 SameSite 属性的 cookies，会被当成SameSite=Lax 解决。

WebSockets

Same-site:

• wss:// connection from https://
• ws:// connection from http://

Cross-site:

• wss:// connection from http://
• ws:// connection from https://

本文次要内容来自：Schemeful Same-Site

关注公众号：湖中剑，找到更多对于我的内容。