Schemeful Same-Site

“同站”的定义正在演变,以纳入网址 scheme,因此站点的 HTTP 版本和 HTTPS 版本之间的链接现在被视为跨站点请求。默认情况下升级到 HTTPS,以尽可能避免问题,或者继续阅读以详细了解需要哪些 SameSite 属性值。

采用网址的“同源”会将网站的定义从仅包含可注册网域修改为包含网址 + 可注册网域。如需了解更多详情和示例,请参阅了解“同网站”和“同源”

好消息是:如果您的网站已完全升级到 HTTPS,则无需担心任何事项。对您而言,一切都不会改变。

如果您尚未全面升级网站,则应优先完成此操作。不过,如果您的网站访问者在 HTTP 和 HTTPS 之间切换,本文后面会介绍其中一些常见场景以及相关的 SameSite Cookie 行为。

您可以在 Chrome 和 Firefox 中启用这些更改以进行测试。

  • 从 Chrome 86 开始,启用 about://flags/#schemeful-same-site。您可以在 Chrome 状态页面上跟踪进度。
  • 从 Firefox 79 开始,请通过 about:confignetwork.cookie.sameSite.schemeful 设置为 true。使用 Bugzilla 问题跟踪进度。

SameSite=Lax 更改为 Cookie 的默认值的一个主要原因是防范跨站请求伪造 (CSRF)。不过,不安全的 HTTP 流量仍然会给网络攻击者可乘之机,让他们篡改将在网站的安全 HTTPS 版本上使用的 Cookie。在 scheme 之间创建此额外的跨网站边界可进一步防范这些攻击。

常见的跨架构场景

以前,在网站的不同架构版本之间导航(例如,从 http://site.example 链接到 https://site.example)时,系统会允许发送 SameSite=Strict Cookie。这现在会被视为跨网站导航,这意味着 SameSite=Strict Cookie 将被屏蔽。

通过在网站的不安全 HTTP 版本上点击指向安全 HTTPS 版本的链接而触发的跨架构导航。阻止 SameSite=Strict Cookie,允许 SameSite=Lax 和 SameSite=None; Secure Cookie。
从 HTTP 到 HTTPS 的跨架构导航。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 已屏蔽 ⛔ 已屏蔽
SameSite=Lax ✓ 允许 ✓ 允许
SameSite=None;Secure ✓ 允许 ⛔ 已屏蔽

加载子资源

在您升级到完全采用 HTTPS 之前,您在此处进行的任何更改都应仅被视为临时解决方法。

子资源示例包括图片、iframe 和使用 XHR 或 Fetch 发出的网络请求。

以前,在网页上加载跨架构子资源会允许发送或设置 SameSite=StrictSameSite=Lax Cookie。现在,系统会将其视为与任何其他第三方或跨网站子资源一样,这意味着系统会屏蔽所有 SameSite=StrictSameSite=Lax Cookie。

此外,即使浏览器允许在安全网页上加载来自不安全架构的资源,这些请求中的所有 Cookie 也会被屏蔽,因为第三方 Cookie 或跨网站 Cookie 需要 Secure

由于不安全 HTTP 版本的网站包含来自安全 HTTPS 版本的资源而导致的跨架构子资源。阻止 SameSite=Strict 和 SameSite=Lax Cookie,并允许 SameSite=None; Secure Cookie。
包含通过 HTTPS 的跨架构子资源的 HTTP 网页。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 已屏蔽 ⛔ 已屏蔽
SameSite=Lax ⛔ 已屏蔽 ⛔ 已屏蔽
SameSite=None;Secure ✓ 允许 ⛔ 已屏蔽

通过 POST 提交表单

以前,在网站的跨架构版本之间发布内容时,系统允许发送使用 SameSite=LaxSameSite=Strict 设置的 Cookie。现在,系统会将其视为跨网站 POST,并且只能发送 SameSite=None Cookie。您可能会在默认显示不安全版本的网站上遇到这种情况,但在用户提交登录表单或结账表单后,会将用户升级到安全版本。

与子资源一样,如果请求是从安全上下文(例如 HTTPS)到不安全上下文(例如 HTTP),则系统会阻止这些请求中的所有 Cookie,因为第三方 Cookie 或跨网站 Cookie 需要 Secure

由于网站的不安全 HTTP 版本中的表单提交到安全 HTTPS 版本,而导致的跨架构表单提交。阻止 SameSite=Strict 和 SameSite=Lax Cookie,并允许 SameSite=None; Secure Cookie。
从 HTTP 到 HTTPS 的跨架构表单提交。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 已屏蔽 ⛔ 已屏蔽
SameSite=Lax ⛔ 已屏蔽 ⛔ 已屏蔽
SameSite=None;Secure ✓ 允许 ⛔ 已屏蔽

如何测试我的网站?

Chrome 和 Firefox 中提供开发者工具和消息功能。

从 Chrome 86 开始,DevTools 中的“问题”标签页将包含 Schemeful Same-Site 问题。您可能会看到系统突出显示的针对您网站的以下问题。

导航问题:

  • “请完全迁移到 HTTPS,以便继续在同源请求中发送 Cookie”- 警告,提示该 Cookie 在 Chrome 的未来版本中被屏蔽。
  • “请完全迁移到 HTTPS,以便在同站点请求中发送 Cookie”- 警告称 Cookie 被屏蔽。

子资源加载问题:

  • “请完全迁移到 HTTPS,以便继续将 Cookie 发送到同站点子资源”或“请完全迁移到 HTTPS,以便继续允许同站点子资源设置 Cookie”- 警告,表示在未来版本的 Chrome 中,系统屏蔽该 Cookie。
  • “完全迁移到 HTTPS 以将 Cookie 发送到同站点子资源”或“完全迁移到 HTTPS 以允许同站点子资源设置 Cookie”- 警告称 Cookie 被屏蔽。在 POST 表单时,也可能会出现后一种警告。

如需了解详情,请参阅 Schemeful 同源测试和调试提示

从 Firefox 79 开始,如果通过 about:confignetwork.cookie.sameSite.schemeful 设置为 true,控制台将显示 Schemeful 同源问题消息。您可能会在自己的网站上看到以下内容:

  • “Cookie cookie_name 很快就会被视为针对 http://site.example/ 的跨网站 Cookie,因为架构不匹配。”
  • “Cookie cookie_name 被视为与 http://site.example/ 跨网站,因为架构不匹配。”

常见问题解答

我的网站已全面改用 HTTPS,为什么我会在浏览器的开发者工具中看到问题?

您的部分链接和子资源可能仍指向不安全的网址。

解决此问题的一种方法是使用 HTTP 严格传输安全 (HSTS) 和 includeSubDomain 指令。使用 HSTS + includeSubDomain 后,即使您的某个网页意外包含不安全的链接,浏览器也会自动改用安全版本。

如果我无法升级到 HTTPS,该怎么办?

虽然我们强烈建议您将网站完全升级为 HTTPS 以保护用户,但如果您无法自行完成升级,建议您与您的托管服务提供商联系,看看他们能否提供此选项。如果您自行托管,则 Let's Encrypt 提供了多种工具来安装和配置证书。您还可以考虑将您的网站移至可提供 HTTPS 连接的 CDN 或其他代理后面。

如果仍无法解决问题,请尝试对受影响的 Cookie 放宽 SameSite 保护。

  • 如果仅阻止 SameSite=Strict Cookie,您可以将保护级别降低到 Lax
  • 如果 StrictLax Cookie 都被屏蔽,并且您的 Cookie 被发送到(或从)安全网址设置,您可以将保护级别降低到 None
    • 如果您要发送 Cookie 的网址(或设置 Cookie 的网址)不安全,此解决方法将失败。这是因为 SameSite=None 要求 Cookie 具有 Secure 属性,这意味着这些 Cookie 不得通过不安全的连接发送或设置。在这种情况下,您将无法访问该 Cookie,除非您的网站升级到 HTTPS。
    • 请注意,这只是暂时性的,因为最终第三方 Cookie 将被完全淘汰。

如果我未指定 SameSite 属性,这对我的 Cookie 有何影响?

没有 SameSite 属性的 Cookie 会被视为指定了 SameSite=Lax,并且相同的跨架构行为也适用于这些 Cookie。请注意,针对不安全方法的临时例外情况仍然适用,如需了解详情,请参阅 Chromium SameSite 常见问题解答中的“宽松 + POST”缓解措施

WebSocket 会受到什么影响?

如果 WebSocket 连接的安全性与网页相同,则仍会被视为同一网站。

Same-Site:

  • 来自 https://wss:// 连接
  • 来自 http://ws:// 连接

跨网站:

  • 来自 http://wss:// 连接
  • 来自 https://ws:// 连接

照片由 Julissa Capdevilla 拍摄,选自 Unsplash