准备好迎接新的 SameSite=None; Secure Cookie 设置

2020 年 1 月 16 日,星期四

本博文是从 Chromium 开发者博客交叉发布的一篇博文,专门介绍了 Chrome 变更可能会对未来用户使用您的网站有何影响。

5 月份,Chrome 宣布推出了一个默认安全的 Cookie 安全模型,由新的 Cookie 分类系统(规范)提供支持。我们一直致力于改善整个网络的隐私性和安全性,此计划就是这方面的工作之一。

Chrome 计划于 2020 年 2 月在 Chrome 80 中实现这一新模型。Mozilla 和 Microsoft 也表示,他们打算按照各自的时间规划在 Firefox 和 Edge 中实现此新模型。虽然 Chrome 变更还有几个月才会实施,但负责管理 Cookie 的开发者需要立即评估自身准备情况,这一点非常重要。本博文将概述总体概念;如需获取开发者指南,请参阅 web.dev 上的 SameSite Cookie 的说明

网站通常会集成外部服务,以便提供广告、内容推荐、第三方微件、社交媒体嵌入和其他功能。当您浏览网页时,这些外部服务可能会在您的浏览器中存储 Cookie,随后访问这些 Cookie,以便提供个性化体验或衡量受众群体互动度。每个 Cookie 都有一个与其关联的网域。如果与 Cookie 关联的网域与某项外部服务匹配,但与用户地址栏中的网站不匹配,则会被视为跨网站(或“第三方”)上下文。

不那么明显的跨网站用例包括拥有多个网站的实体跨这些资源使用 Cookie 的情况。虽然这些 Cookie 和网站属于同一实体,但如果 Cookie 的网域与访问该 Cookie 的网站不匹配,则仍然属于跨网站上下文或“第三方”上下文。

网站网域与 Cookie 网域不匹配

当网页上的外部资源访问与网站网域不匹配的 Cookie 时,视为跨网站上下文或“第三方”上下文。

相比之下,当 Cookie 的网域与用户地址栏中的网站网域匹配时,则视为在同一网站(或第一方)上下文中访问 Cookie。同一网站 Cookie 通常用于使用户在各个网站保持登录状态、记住其偏好设置以及支持网站分析。

网站网域与 Cookie 网域匹配

当网页上的资源访问与用户正在访问的网站相匹配的 Cookie 时,视为同一网站或“第一方”上下文。

目前,如果只能在第一方上下文中访问 Cookie,则开发者可以选择应用两种设置(SameSite=LaxSameSite=Strict)之一来阻止外部访问。但是,很少有开发者遵循此推荐做法,导致大量同一网站 Cookie 不必要地面临了跨站请求伪造攻击等威胁。

为保护更多网站及其用户,除非另有规定,否则这个默认安全的新模型假定应保护所有 Cookie 并阻止外部访问。开发者必须使用新的 Cookie 设置 SameSite=None 来指定跨网站访问的 Cookie。如果存在 SameSite=None 属性,则必须使用其他安全属性,让跨网站 Cookie 只能通过 HTTPS 连接进行访问。这不会缓解与跨网站访问相关的所有风险,但有助于防范网络攻击。

除了直接的安全优势之外,明确声明跨网站 Cookie 还有助于提高透明度,为用户提供更多选择。例如,浏览器可以为用户提供精细的控件,以便单独管理仅由单个网站访问的 Cookie,这些 Cookie 与跨多个网站访问的 Cookie 是分开管理的。

自 2020 年 2 月起执行 Chrome 强制措施

从 2 月份起,在 Chrome 80 中,Chrome 会将未声明 SameSite 值的 Cookie 视为 SameSite=Lax Cookie。只有采用 SameSite=None; Secure 设置的 Cookie 可用于外部访问,但前提是通过安全连接进行访问。适用于 SameSite=NoneSecure 的 Chrome Platform Status 跟踪器会持续更新,列出最新的发布信息。

Mozilla 已经确认他们支持新的 Cookie 分类模型,并打算在 Firefox 中实现对跨网站 Cookie 的 SameSite=None; Secure 要求。Microsoft 最近宣布计划在 Microsoft Edge 80 中进行实验,开始实现该模型。

准备工作;已知复杂性

如果您负责管理跨网站 Cookie,则需要对这些 Cookie 应用 SameSite=None; Secure 设置。对于大多数开发者来说,实现过程应该简单直接,但我们强烈建议您立即开始测试,以确定有哪些复杂和特殊情况,例如:

  • 并非所有语言和库都支持 None 值,这要求开发者直接设置 Cookie 标头。此 GitHub 代码库提供了有关以多种语言、库和框架实现 SameSite=None; Secure 的说明。
  • 某些浏览器(包括某些版本的 Chrome、Safari 和 UC 浏览器)可能会以意想不到的方式处理 None 值,这要求开发者为这些客户端编写异常处理代码。其中包括由旧版 Chrome 提供支持的 Android WebView。下面列出了已知不兼容的客户端
  • 建议应用开发者同时针对通过 HTTP(S) 标头以及通过 Android WebViewCookieManager API 访问的 Cookie,根据与 None 值兼容的 Chrome 版本为 Android WebViews 声明适当的 SameSite cookie 设置,尽管晚些时候才会在 Android WebView 上实施此新模型。
  • 如果某些服务(如单点登录或内部应用)尚未准备好迎接在 2 月份发布的新模型,企业 IT 管理员可能需要实施特殊政策,以暂时将 Chrome 浏览器还原为原有运行方式。
  • 如果您有同时在第一方和第三方上下文中访问的 Cookie,可以考虑使用单独的 Cookie,以获得第一方上下文中的 SameSite=Lax 优势。

SameSite Cookie 的说明针对上述情况提供了具体指南,并提供了问题反馈渠道。

如需测试新的 Chrome 行为对网站或您管理的 Cookie 的影响,您可以在 Chrome 76 及更高版本中转到 chrome://flags,然后启用“SameSite by default cookies”和“Cookies without SameSite must be secure”实验设置。此外,系统会自动为部分 Chrome 79 Beta 版用户启用这些实验设置。某些启用了实验设置的 Beta 版用户可能会遇到与尚不支持新模型的服务不兼容的问题;这些用户可以转到 chrome://flags 并选择停用 Beta 版实验设置。

如果您管理的 Cookie 仅在同一网站上下文中访问(同一网站 Cookie),则无需执行任何操作。即使缺少 SameSite 属性或未设置任何值,Chrome 也会自动阻止外部实体访问这些 Cookie。不过,强烈建议您应用适当的 SameSite 值(Lax 或 Strict),并且不要依赖默认的浏览器行为,因为并非所有浏览器都会默认保护同一网站 Cookie。

最后,如果您担心供应商和其他为您的网站提供服务的提供商的准备情况,则当某个网页包含缺少所需设置的跨网站 Cookie 时,您可以在 Chrome 浏览器 77 及更高版本中查看开发者工具控制台是否有警告:

与 Cookie 网域上的跨网站资源关联的 Cookie 未使用“SameSite”属性进行设置

一些提供商(包括部分 Google 服务)将在 2 月 Chrome 80 发布新模型之前的月份中实施必要的更改;建议您联系您的合作伙伴,确认他们是否已准备就绪。