Schemeful Same-Site

“同站点”的定义正在演变为包含 URL 架构，因此站点 HTTP 和 HTTPS 版本之间的链接现在被视为跨站点请求。默认情况下升级到 HTTPS 以尽可能避免问题，或继续阅读以了解所需的 SameSite 属性值详情。

Steven Bingler
Rowan Merewood

Schemeful Same-Site 修改了（Web）站点的定义，从仅限可注册域名更改为架构 + 可注册域名。您可以在了解“同站点”和“同源”中找到更多详细信息和示例。

好消息是：如果您的网站已完全升级到 HTTPS，则无需担心任何事情。对于您来说，一切都不会改变。

如果您尚未完全升级您的网站，那么这应该是首要任务。但是，如果您的网站访问者会在 HTTP 和 HTTPS 之间跳转，那么本文稍后将概述一些常见场景和相关的 SameSite Cookie 行为。

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

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

将 SameSite=Lax 更改为 Cookie 默认值的主要原因之一是为了防止跨站请求伪造 (CSRF)。但是，不安全的 HTTP 流量仍然为网络攻击者篡改 Cookie 提供了机会，这些 Cookie 随后将在站点的安全 HTTPS 版本上使用。在架构之间创建此额外的跨站点边界可以进一步防御这些攻击。

常见的跨架构场景

在网站的跨架构版本之间导航（例如，从 http://site.example 链接到 https://site.example）以前允许发送 SameSite=Strict Cookie。现在这被视为跨站点导航，这意味着 SameSite=Strict Cookie 将被阻止。

A cross-scheme navigation triggered by following a link on the insecure HTTP version of a site to the secure HTTPS version. SameSite=Strict cookies blocked, SameSite=Lax and SameSite=None; Secure cookies are allowed.
从 HTTP 到 HTTPS 的跨架构导航。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 已阻止 ⛔ 已阻止
SameSite=Lax ✓ 允许 ✓ 允许
SameSite=None;Secure ✓ 允许 ⛔ 已阻止

加载子资源

您在此处进行的任何更改都应仅被视为临时修复，同时您努力升级到完全 HTTPS。

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

在页面上加载跨架构子资源以前允许发送或设置 SameSite=Strict 或 SameSite=Lax Cookie。现在，这被视为与任何其他第三方或跨站点子资源相同的方式，这意味着任何 SameSite=Strict 或 SameSite=Lax Cookie 都将被阻止。

此外，即使浏览器允许从不安全架构加载资源到安全页面上，所有 Cookie 也将在这些请求中被阻止，因为第三方或跨站点 Cookie 需要 Secure。

A cross-scheme subresource resulting from a resource from the secure HTTPS version of the site being included on the insecure HTTP version. SameSite=Strict and SameSite=Lax cookies blocked, and SameSite=None; Secure cookies are allowed.
HTTP 页面通过 HTTPS 包含跨架构子资源。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 已阻止 ⛔ 已阻止
SameSite=Lax ⛔ 已阻止 ⛔ 已阻止
SameSite=None;Secure ✓ 允许 ⛔ 已阻止

POST 表单

在网站的跨架构版本之间进行 POST 操作以前允许发送使用 SameSite=Lax 或 SameSite=Strict 设置的 Cookie。现在，这被视为跨站点 POST——只能发送 SameSite=None Cookie。您可能会在默认情况下呈现不安全版本，但在提交登录或结帐表单时将用户升级到安全版本的站点上遇到这种情况。

与子资源一样，如果请求来自安全上下文（例如 HTTPS）到不安全上下文（例如 HTTP），则所有 Cookie 都将在这些请求中被阻止，因为第三方或跨站点 Cookie 需要 Secure。

A cross-scheme form submission resulting from a form on the insecure HTTP version of the site being submitted to the secure HTTPS version. SameSite=Strict and SameSite=Lax cookies blocked, and SameSite=None; Secure cookies are allowed.
从 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”——警告 Cookie 在未来的 Chrome 版本中将被阻止。
  • “完全迁移到 HTTPS 以将 Cookie 发送到同站点子资源”或“完全迁移到 HTTPS 以允许同站点子资源设置 Cookie”——警告 Cookie 已被阻止。后一个警告也可能在 POST 表单时出现。

更多详细信息请参见Schemeful Same-Site 的测试和调试技巧。

从 Firefox 79 开始，通过 about:config 将 network.cookie.sameSite.schemeful 设置为 true 后，控制台将显示 Schemeful Same-Site 问题的消息。您可能会在您的站点上看到以下内容

  • “Cookie cookie_name 即将被视为针对 http://site.example/ 的跨站点 Cookie，因为架构不匹配。”
  • “Cookie cookie_name 已被视为针对 http://site.example/ 的跨站点 Cookie，因为架构不匹配。”

常见问题解答

我的站点已完全在 HTTPS 上可用，为什么我在浏览器的 DevTools 中看到问题？

可能是您的一些链接和子资源仍然指向不安全的 URL。

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

如果我无法升级到 HTTPS 怎么办？

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

如果仍然不可能，请尝试放宽受影响 Cookie 的 SameSite 保护。

  • 在仅阻止 SameSite=Strict Cookie 的情况下，您可以将保护级别降低到 Lax。
  • 在 Strict 和 Lax Cookie 都被阻止，并且您的 Cookie 被发送到（或从）安全 URL 设置的情况下，您可以将保护级别降低到 None。
    • 如果您要将 Cookie 发送到（或从中设置）的 URL 不安全，则此解决方法将失败。这是因为 SameSite=None 需要 Cookie 上的 Secure 属性，这意味着这些 Cookie 可能不会通过不安全连接发送或设置。在这种情况下，在您的站点升级到 HTTPS 之前，您将无法访问该 Cookie。
    • 请记住，这只是暂时的，因为最终将完全淘汰第三方 Cookie。

如果我没有指定 SameSite 属性，这将如何影响我的 Cookie？

没有 SameSite 属性的 Cookie 被视为已指定 SameSite=Lax，并且相同的跨架构行为也适用于这些 Cookie。请注意，不安全方法的临时例外情况仍然适用，有关更多信息，请参阅 Chromium SameSite 常见问题解答中的Lax + POST 缓解措施。

WebSocket 如何受到影响？

如果 WebSocket 连接与页面的安全性相同，则仍将被视为同站点。

同站点

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

跨站点

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

图片来源：Julissa Capdevilla，来自 Unsplash