致开发者：全新的安全 Cookie 设置功能即将上线

文 / Chrome 和 Web 平台合作关系部门 Barb Palser

2019 年 5 月，Chrome 曾公布一个预设安全 (Secure by default) cookie 模型，该模型启用了全新 cookie 分类系统（SPEC）。这仅仅是我们不断努力改善整个网络隐私性和安全性的一部分。

• 公布
  https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
  

• SPEC
  https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
  

• 不断努力
  https://www.blog.google/products/chrome/building-a-more-private-web/
  

Chrome 计划在 2020 年 2 月正式发布的 Chrome 80 上实现这一新模型。Mozilla 和 Microsoft 也都表示会按自己的时间计划将这个新模型部署到 Firefox 和 Edge 中。虽然这一变更离实际部署到 Chrome 还有一些时间，但是对于进行 cookie 管理的开发者来说，最好现在就评估是否已做好准备。本文将会介绍高层面的概念。请前往 web.dev 参阅“SameSite Cookie 解释”获取开发者指南。

• 开发者指南：SameSite Cookie 解释
  https://web.dev/samesite-cookies-explained

理解跨站和同站Cookie 上下文

网站通常会集成外部服务，用于广告、内容推荐、第三方组件、社交插件和其他功能。当浏览网页时，这些外部服务可能会在您的浏览器中储存 cookie，接着会通过访问这些 cookie 以提供个性化体验或衡量受众参与度。每一个 cookie 都有与之关联的域名。如果与 cookie 关联的域名与外部服务匹配，但是与用户地址栏的网站不符，则可以称为跨站（或 “第三方”）上下文。

其他的跨站用例包括拥有多个网站的实体在他们拥有的多个网站中使用同一个 cookie 的情况。尽管拥有 cookie 和网站的是同一个实体，但当 cookie 的域名与访问 cookie 所在的网站不匹配时，这仍然算作跨站或 “第三方” 上下文。

当网页上的外部资源访问到与网站域名不匹配的 cookie时，可以算作跨站或“第三方”上下文

相反，当 cookie 的域名与用户地址栏的网站域名匹配时，可以算作在 同站（或 “第一方” ）上下文中访问 cookie。同站 cookie 通常用于保持用户在该网站的登录状态、记住用户偏好和用于网站分析。 

当网页上的资源访问到的 cookie 与用户访问的网站匹配时，可以算作同站或“第一方”上下文

让 Cookie 安全、透明的全新模型

如今，如果只想将 cookie 的访问限制在第一方上下文中，开发者可以选择应用这两种设置中的一种（SameSite=Lax 或 SameSite=Strict） 来阻止外部访问。然而，只有很少一部分开发者遵循这个推荐做法，导致有很大一部分同站 cookie 面临不必要的威胁，比如跨站请求伪造（Cross-Site Request Forgery）攻击。

• 跨站请求伪造
  https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

除非另有说明，否则为了保护更多的网站及其用户，这个全新预设安全模型假定所有 cookie 都应该保护起来，防止外部访问。开发者必须使用新的 cookie 设置SameSite=None来指定用于跨站访问的 cookie。当出现SameSite=None属性时，必须使用额外的 Secure属性，以便保证仅可以通过 HTTPS 连接访问跨站 cookie。这不会降低与跨站访问相关的风险，但提供针对网络攻击的保护。

除了直接的安全优势外，明确声明跨站 cookie 还能提高透明度和用户选择。例如，浏览器可以为用户提供管理 cookie 时的精细控制，将仅可以在单个网站访问的 cookie 与可以在多个网站访问的 cookie 分开。

Chrome 将于今年 2 月开始强制启用

即将在 2 月份发布的 Chrome 80 中，Chrome 会将没有声明 SameSite 值的 cookie 默认设置为SameSite=Lax。只有采用SameSite=None; Secure设置的 cookie 可以从外部访问，前提是通过安全连接访问。SameSite=None 和 Secure 的 Chrome Platform Status 追踪器会根据最新的启动信息持续更新。

• SameSite=None
  https://chromestatus.com/feature/5088147346030592

• Secure
  https://chromestatus.com/feature/5633521622188032

Mozilla 已经确认他们会支持这一全新的 cookie 分类模型，会为 Firefox 的跨站 cookie 部署SameSite=None; Secure要求。Microsoft 近期宣布打算先在 Microsoft Edge 80 中以实验特性的形式实现这一模型。

• 部署
  https://groups.google.com/forum/#!msg/mozilla.dev.platform/nx2uP0CzA9k/BNVPWDHsAQAJ

• 宣布
  https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/AknSSyQTGYs/8lMmI5DwEAAJ

如何做好准备以及已知复杂性

如果您是跨站 cookie 管理员，则需要对这些 cookie 进行“SameSite=None; Secure”设置。对于大多数开发者来说，部署应该非常简单，但我们强烈建议您立即开始测试，以确定复杂性和特殊情况，例如：

• 并非所有语言和库都支持 None 值，因此要求开发者直接设置 cookie 标头。此 Github 代码库 提供将“SameSite=None; Secure”部署到各类编程语言、程序库和框架的步骤。

• Github 代码库
  https://github.com/GoogleChromeLabs/samesite-examples

• 某些浏览器（包括一些版本的 Chrome、Safari 和 UC 浏览器）可能会以不正确的方式处理  None 值，这就要求开发者针对这些客户端出现的异常进行相应的处理。这包含由旧版 Chrome 提供支持的 Android WebView。以下是已知不兼容的客户端列表。

• 不兼容的客户端
  https://www.chromium.org/updates/same-site/incompatible-clients
  

• 尽管新模型稍后才会在 Android WebView 上强制执行，但是我们建议应用开发者根据与 None 值兼容的 Chrome 版本 Android WebView 的 SameSite cookie 设置做相应声明，无论是对于通过 HTTP(S) 标头访问的 cookie，还是通过 Android WebView 的 CookieManager API 访问的 cookie。

• CookieManager API 
  https://developer.android.com/reference/android/webkit/CookieManager
  

• 2 月份发布时，如果某些服务（如单点登录或内部应用程序）尚未适配好，则企业 IT 管理员可能需要实施特殊策略，以暂时将 Chrome 浏览器还原到旧的行为方式。

• 特殊策略
  https://www.chromium.org/administrators/policy-list-3/cookie-legacy-samesite-policies
  

• 如果您有需要同时在第一方和第三方上下文中访问的 cookie，则可以考虑在第一方上下文中使用单独的 cookie 以获取“SameSite=Lax”的安全优势。

“SameSite Cookies 解释” 为上述情况提供具体指导，也是提 issue 与问题的渠道。

• SameSite Cookies 解释
  https://web.dev/samesite-cookies-explained
  

若要测试新的 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 以上版本中查看“开发者工具”控制台警告：

一些服务提供商（包括一些 Google 服务）将在 2 月份的 Chrome 80 发布前几个月发布这一变更。您可能需要与合作伙伴联系，以确认他们是否准备就绪。