Schemeful Same-Site

“同网站”的定义在不断发展,纳入了网址协议,因此网站的 HTTP 和 HTTPS 版本之间的链接现在会被计为跨网站请求。默认升级到 HTTPS,尽可能避免出现问题;您也可以继续阅读,详细了解需要哪些 SameSite 属性值。

史蒂文·宾格勒
Steven Bingler

Schemeful Same-Site 只会将(网站)网站的定义从可注册网域修改为 scheme + 可注册网域。如需了解更多详情和示例,请参阅了解“同网站”和“同源”

好消息是:如果您的网站已经完全升级到 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 流量仍可能会让网络攻击者有机会篡改 Cookie,之后 Cookie 便会在安全的 HTTPS 版本上使用。在方案之间创建这种额外的跨网站边界,可以进一步防御这些攻击。

常见的跨架构场景

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

在不安全的 HTTP 版本网站上点击指向安全 HTTPS 版本的链接,从而触发跨架构导航。SameSite=Strict Cookie 被阻止,SameSite=Lax 和 SameSite=None;允许使用安全 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 需要 Secure

跨架构子资源,来源于非安全 HTTP 版本中所含网站的安全 HTTPS 版本。已阻止 SameSite=Strict 和 SameSite=Lax Cookie,并且 SameSite=None; 允许使用安全 Cookie。
一个通过 HTTPS 包含跨架构子资源的 HTTP 网页。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 已屏蔽 ⛔ 已屏蔽
SameSite=Lax ⛔ 已屏蔽 ⛔ 已屏蔽
SameSite=None;Secure ✓ 允许 ⛔ 已屏蔽

发布表单

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

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

跨方案表单提交,是因为系统将不安全 HTTP 版本网站的表单提交到了安全 HTTPS 版本。已阻止 SameSite=Strict 和 SameSite=Lax Cookie,并且 SameSite=None; 允许使用安全 Cookie。
从 HTTP 到 HTTPS 的跨架构表单提交。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ 已屏蔽 ⛔ 已屏蔽
SameSite=Lax ⛔ 已屏蔽 ⛔ 已屏蔽
SameSite=None;Secure ✓ 允许 ⛔ 已屏蔽

如何测试我的网站?

Chrome 和 Firefox 支持开发者工具和消息功能。

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

导航问题:

  • “完全迁移到 HTTPS 以继续在同网站请求中发送 Cookie”- 一条警告,提示 Cookie 在未来版本的 Chrome 中将被阻止。
  • “完全迁移到 HTTPS 以便在同网站请求时发送 Cookie”- 警告 Cookie 已被阻止。

子资源加载问题:

  • “完全迁移到 HTTPS 以继续将 Cookie 发送到同网站子资源”或“完全迁移到 HTTPS 以继续允许同网站子资源设置 Cookie”- 用于警告相应 Cookie 将在未来版本的 Chrome 中阻止。
  • “完全迁移到 HTTPS 以将 Cookie 发送到同网站子资源”或“完全迁移到 HTTPS 以允许同网站子资源设置 Cookie”- 警告 Cookie 已被阻止。发布表单时也可能出现后一种警告。

如需了解详情,请参阅针对 Schemeful Same-Site 的测试和调试提示

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

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

常见问题解答

我的网站已经完全支持 HTTPS,为什么我在浏览器的开发者工具中看到相关问题?

您的某些链接和子资源可能仍会指向不安全的网址。

解决此问题的一种方法是使用 HTTP Strict-Transport-Security (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 可能无法通过不安全的连接发送或设置。在这种情况下,在您的网站升级到 HTTPS 之前,您将无法访问该 Cookie。
    • 请注意,这只是暂时的,因为我们最终会完全淘汰第三方 Cookie。

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

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

WebSocket 会受到什么影响?

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

同一网站:

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

跨网站:

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

照片由 Julissa Capdevilla 拍摄,拍摄于 Unsplash 网站