作者 / 谷歌中国 Web 生态咨询团队
SameSite Cookie 对网站的安全性十分重要。在今年七月我们重新发布了 SameSite 的变更,时至今日在 Chrome 80 以上版本已达到完全覆盖。
有鉴于广大开发者尚未作出相对应的调整,且基于保护用户隐私的前提下,本团队将变更内容及如何调整 SameSite Cookie 为所有开发者再做了整合,希望可以唤起开发者对用户隐私的关注并着手进行变更,减少潜在的安全风险。
在 7 月恢复 SameSite Cookie 变更
在今年 4 月,为确保网站在应对新冠肺炎的重要初始阶段稳定提供必要服务,我们临时回滚了 SameSite Cookie 标记实施。我们已发布准备在夏季恢复部署的计划。
自 4 月以来,我们一直在监控整个生态系统的准备程度,并与网站和服务合作,确保他们为 SameSite 标记政策做好准备。我们在 7 月 14 日恢复了针对 Chrome 80+ 启用的 SameSite Cookie 实施,与 Chrome 84 的稳定版保持一致。
4 月
https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html
为新的 SameSite=None; Secure Cookie 设置做好准备
去年 5 月,Chrome 宣布推出 Cookie 的默认安全模型,采用新的 Cookie 分类系统 (规范)。此计划是我们持续工作的一部分,旨在改进网络上的隐私性和安全性。请参阅 web.dev 上的 SameSite Cookie 说明获取开发者指导。
宣布
https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
规范
https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
持续工作
https://www.blog.google/products/chrome/building-a-more-private-web/
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 暴露给跨站请求伪造攻击等威胁。
跨站请求伪造
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
为保护更多网站及其用户,新的默认安全模型假定所有 Cookie 都应受到保护以防止外部访问 (除非另有指定)。开发者必须使用新的 Cookie 设置 SameSite=None 指定 Cookie 能用于跨站访问。当 SameSite=None 属性存在时,必须使用附加 Secure 属性,使跨站 Cookie 只能通过 HTTPS 连接访问。这无法缓解与跨站访问相关的风险,但可以防范网络攻击。
除了即时安全性的优点,显式声明跨站 Cookie 还可以增强透明度和用户选择。例如,浏览器可以为用户提供细粒度控制,将仅供单个网站访问的 Cookie 与跨多个网站访问的 Cookie 分开管理。
如何准备: 已知复杂性
如果您管理跨域 Cookie,则需要对这些 Cookie 应用 SameSite=None; Secure 设置。应直接面向大多数开发者实施,但我们强烈建议您现在就开始测试,以便发现复杂性和特殊情况,例如:
并非所有语言和库都已支持 None 值,需要开发者直接设置 Cookie 标头。此 Github 仓库说明了如何在各种语言、库和框架中实施 SameSite=None; Secure。
某些浏览器 (包括 Chrome、Safari 和 UC 浏览器的某些版本) 可能以非预期方式处理 None 值,需要开发者针对这些客户端进行例外编码。这包括旧版 Chrome 支持的 Android WebView。下面是已知的不兼容的客户端列表。
对于通过 HTTP(S) 标头以及 Android WebView 的 CookieManager API 访问的 Cookie,建议应用开发者根据兼容 None 值的 Chrome 版本为 Android WebViews 声明适当的 SameSite Cookie 设置,虽然目前不会在 Android WebView 上强制实施新模型。
如果某些服务 (如单点登录或内部应用) 对于 2 月的实施未准备好,企业 IT 管理员可能需要实施特殊政策,将 Chrome 浏览者临时恢复到旧行为。
如果您有在第一方和第三方场景中访问的 Cookie,可以考虑在第一方场景中使用单独的 Cookie 来获得 SameSite=Lax 的安全性优点。
Github 仓库
https://github.com/GoogleChromeLabs/samesite-examples
不兼容的客户端
https://www.chromium.org/updates/same-site/incompatible-clients
CookieManager API
https://developer.android.google.cn/reference/android/webkit/CookieManager
特殊政策
https://www.chromium.org/administrators/policy-list-3/cookie-legacy-samesite-policies
SameSite Cookie 说明提供了上述情况的具体指导以及提出问题的渠道。
SameSite Cookie 说明
https://web.dev/samesite-cookies-explained
要测试新 Chrome 行为对您管理的网站或 Cookie 的影响,您可以在 Chrome 76+ 中访问 chrome://flags,启用 "SameSite by default cookies" 和 "Cookies without SameSite must be secure" 实验。此外,这些实验对一部分 Chrome 79 测试版用户会自动启用。某些启用了实验的测试版用户可能因服务不支持新模型而遇到不兼容的问题;用户可以转到 chrome://flags 禁用实验,选择退出测试版实验。
如果您管理只在同域场景中访问的 Cookie (同域 Cookie),则无需执行操作;Chrome 会自动阻止外部实体访问这些 Cookie,即使缺少 SameSite 属性或者未设置值也是如此。不过,我们强烈建议您应用适当的 SameSite 值 (Lax 或 Strict),而不要依靠默认浏览器行为,因为并非所有浏览器都默认保护同站 Cookie。
最后,如果您担心供应商以及向您的网站提供服务的其他方的准备程度,您可以在 Chrome 77+ 中检查 "开发者工具" 控制台警告,了解网页何时包含跨站点 Cookie 且缺少必需设置:
更多资源
像以前的部署一样,实施将循序渐进,我们将在 Chromium.org 的 SameSite 最新动态页面上及时公布时间和任何可能的变动。我们面向开发者的整体指导没有变化,您可以在之前的 Chromium 博客和 Web.dev 上查找更多信息、资源和反馈渠道。
SameSite 最新动态
https://www.chromium.org/updates/same-site
Chromium 博客
https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
Web.dev
https://web.dev/samesite-cookies-explained/
推荐阅读
点击屏末 | 阅读原文 | 访问 Web.dev 了解更多相关信息