CNAME 伪装和跳出追踪防御
这篇博客文章涵盖了 Safari 14 在 macOS Big Sur、Catalina 和 Mojave、iOS 14 和 iPadOS 14 中智能追踪预防 (ITP) 的几项增强功能，旨在应对我们最近发现的行业追踪问题。
CNAME 伪装防御
ITP 现在将所谓第三方 CNAME 伪装 HTTP 响应中设置的 Cookie 的有效期限制在 7 天。在 macOS 上，这项增强功能仅适用于 Big Sur。
什么是 CNAME 伪装？
在网络浏览器看来，网站的第一方通常由其可注册域定义。这意味着 www.blog.example 和 comments.blog.example 被视为同站和同一方。如果用户从 www.blog.example 加载网页，并且该页面向 comments.blog.example 发出子资源请求，则该请求将携带所有覆盖 blog.example 网站的 Cookie，包括登录 Cookie 和用户身份 Cookie。此外，对 comments.blog.example 子资源请求的响应可以为 blog.example 设置 Cookie，这些 Cookie 将是第一方 Cookie。
CNAME 登场。CNAME 代表规范名称记录，是域名系统 (DNS) 的一部分，它将一个域名映射到另一个域名。这意味着网站所有者可以配置其子域之一（例如 sub.blog.example）解析到 thirdParty.example，然后再解析到 IP 地址。这发生在网络层之下，被称为 CNAME 伪装—— thirdParty.example 域伪装成 sub.blog.example，因此具有与真正的第一方相同的权限。
CNAME 伪装和追踪
跨站点追踪器已说服网站所有者设置 CNAME 伪装，以规避追踪预防，例如 ITP 对 JavaScript 中设置的 Cookie 的 7 天有效期限制。在我们的博客案例中，这将使 track.blog.example 解析到 tracker.example。
高级研究大学院大学 (Sokendai) 和法国国家网络安全局 (ANSSI) 的研究人员最近发表的一篇论文发现，共有 1,762 个网站 CNAME 伪装了总共 56 个追踪器。
CNAME 伪装和网站安全
如果 CNAME 记录管理不当，例如不再使用时未停用 CNAME 伪装，设置 CNAME 伪装的网站所有者可能会面临完整的网站劫持或客户 Cookie 劫持的风险。最近有报道称，250 家银行、医疗保健公司、连锁餐厅和民权组织的网站因 CNAME 伪装管理不善而被入侵。今年 6 月，微软记录了这些攻击以及他们的云客户应如何预防它们。
ITP 对 CNAME 伪装追踪的防御
ITP 现在检测第三方 CNAME 伪装请求，并将 HTTP 响应中设置的任何 Cookie 的有效期限制在 7 天。此限制与 ITP 对通过 JavaScript 创建的所有 Cookie 的有效期限制保持一致。
第三方 CNAME 伪装定义为通过与第一方域不同且与顶层框架主机的 CNAME（如果存在）不同的 CNAME 解析的第一方子资源。是的，整个站点都可以进行 CNAME 伪装，当它使用所谓的边缘服务器时。
解释这一点最好的方法是通过一个表格（1p 代表第一方，3p 代表第三方）
| 1p 主机，例如 www.blog.example | 非 1p 主机的 1p 子域，例如 track.blog.example | Cookie 有效期是否受限？ |
|---|---|---|
| 无伪装 | 无伪装 | 无限制 |
| 无伪装 | other.blog.example (1p 伪装) | 无限制 |
| 无伪装 | tracker.example (3p 伪装) | 7 天限制 |
| abc123.edge.example (伪装) | 无伪装 | 无限制 |
| abc123.edge.example (伪装) | abc123.edge.example (匹配伪装) | 无限制 |
| abc123.edge.example (伪装) | other.blog.example (1p 伪装) | 无限制 |
| abc123.edge.example (伪装) | tracker.example (3p 伪装) | 7 天限制 |
用于跳出追踪器的 SameSite=Strict Cookie 隔离
2018 年 6 月，我们宣布了 ITP 的更新，以检测和防御第一方跳出追踪器。2020 年 3 月，我们宣布了一项增强功能，也用于检测延迟跳出追踪。从那时起，我们收到了一份关于某个特定网站进行跳出追踪同时可能获得频繁用户交互的报告。为了解决此类问题，我们向 W3C 隐私社区组提出了我们称之为SameSite=Strict 隔离以及其他升级措施。
SameSite=Strict 隔离的作用是检测跳出追踪，并在达到某个阈值时，将所有追踪域的 Cookie 重写为 SameSite=Strict。这意味着它们将不会在跨站点、第一方导航中发送，并且它们不能再用于简单的基于重定向的跳出追踪。
我们的实现相当宽松，阈值设置为 10 个唯一的导航性第一方重定向（在转到唯一域的意义上是唯一的），并且一旦 Cookie 被重写为 SameSite=Strict，该计数器就会自动重置。这会自动为该域提供新的机会，以便它们可以脱离跳出追踪并“摆脱困境”。
我们目前受此保护的域列表为空，因为向我们报告的域已停止其跳出追踪。但这项保护仍保留在我们的工具箱中。
分区临时 IndexedDB
到目前为止，WebKit 一直阻止跨源 IndexedDB。WebKit 现在允许分区和临时的第三方 IndexedDB，以期与现在也对存储分区感兴趣的其他浏览器保持一致。您可以参与 GitHub 上正在进行的存储分区标准化工作。
分区意味着每个第一方站点都有唯一的 IndexedDB 实例，临时意味着仅内存中存在，即浏览器退出后消失。
隐私浏览中的第三方 Cookie 阻止和存储访问 API
Safari 中的隐私浏览基于 WebKit 的临时会话，其中没有任何内容持久化到磁盘。这意味着 ITP 无法在 Safari 启动之间学习事物。此外，隐私浏览还为用户打开的每个新标签页使用单独的临时会话。为了维护标签页之间的这种分离，ITP 甚至无法在内存中根据用户的完整浏览来分类跨站点追踪器。
然而，完全阻止第三方 Cookie 不需要分类，现在在隐私浏览中默认启用。这看起来很简单，但挑战在于使存储访问 API 与上述标签页分离协同工作。它是这样工作的：假设 identityProvider.example 希望在 Tab A 中 social.example 的登录页面上请求作为第三方的存储访问。在 Tab B 中将 identityProvider.example 作为第一方网站进行交互不足以允许它在 Tab A 中请求存储访问，因为这会在单独的临时会话之间泄露状态。因此，用户必须在与 identityProvider.example 稍后作为第三方请求存储访问的同一标签页中与 identityProvider.example 交互。这确保了涉及两个不同方且需要第三方 Cookie 访问的登录流程在隐私浏览模式下是可能的。
主屏幕网络应用程序域豁免于 ITP
早在 2020 年 3 月，当我们宣布 ITP 对所有可脚本写入存储的 7 天限制时，开发者们询问了主屏幕网络应用程序是否可以豁免于此 7 天限制。我们解释了 ITP 的“使用天数”计数器和用户交互捕获如何有效地确保主屏幕网络应用程序的第一方不会受到新的 7 天限制。为了使这一点更清晰，我们为主屏幕网络应用程序的第一方域实现了一个明确的例外，以确保 ITP 始终在其网站数据删除算法中跳过该域。
此外，主屏幕网络应用程序的网站数据与 Safari 隔离，因此不会受到 ITP 在 Safari 中追踪行为分类的影响。
感谢我的同事
上述 WebKit 和 ITP 的更新若没有 Kate、Jiten、Scott、Tommy、Sihui 和 David 的帮助是不可能实现的。谢谢你们！