Safari中的Cname隐藏和反弹追踪防御

这篇博客文章涵盖了macOS Big Sur，Catalina和Mojave，iOS 14和iPadOS 14上Safari 14中的智能跟踪预防（ITP）的多项增强功能，以解决我们在跟踪领域的最新发现。

现在，ITP将在所谓的第三方CNAME隐藏的HTTP响应中设置的Cookie的有效期限设置为7天。在macOS上，此增强功能特定于Big Sur。

在网络浏览器看来，网站的第一方通常由其可注册域定义。这意味着www.blog.example和comments.blog.example被视为同一站点和同一方。如果用户从www.blog.example加载网页，并且该页面向comments.blog.example发出子资源请求，则该请求将携带所有设置为覆盖blog.example网站的cookie，包括登录cookie和用户身份饼干。另外，对该comment.blog.example子资源请求的响应可以为blog.example设置cookie，并且这些cookie将是第一方cookie。

输入CNAME。 CNAME代表规范名称记录，并将一个域名映射到另一个域名，作为域名系统或DNS的一部分。这意味着网站所有者可以在解析为IP地址之前，配置其子域之一（例如sub.blog.example）以解析为thirdParty.example。这种情况发生在Web层下面，称为CNAME伪装-thirdParty.example域被伪装为sub.blog.example，因此具有与真正的第一方相同的权力。

跨站点跟踪程序已说服站点所有者设置CNAME伪装，以规避跟踪预防，例如ITP对JavaScript中设置的Cookie的7天有效期上限。在我们的博客案例中，这将把track.blog.example解析为tracker.example。

高级研究大学（Sokendai）和法国国家网络安全局（ANSSI）研究人员的最新论文发现，共有1,762个CNAME网站掩盖了56个跟踪器。

如果对CNAME记录的管理不当，例如，如果CNAME伪装不再使用时就不再使用，那么设置CNAME伪装的网站所有者可能会面临整个网站被收购或客户Cookie劫持的风险。最近有报道称，由于CNAME伪装管理不当，银行，医疗保健公司，饭店连锁和民权组织的250个网站遭到破坏。微软在今年6月记录了这些攻击以及他们的云客户应如何防止它们。

现在，ITP会检测到第三方CNAME的伪装请求，并将HTTP响应中设置的任何cookie的有效期限设置为7天。此上限与ITP通过JavaScript创建的所有Cookie的有效期限一致。

第三方CNAME伪装被定义为第一方子资源，该子资源通过与第一方域不同且与顶级主机的CNAME（如果存在）不同的CNAME进行解析。是的，当使用所谓的边缘服务器时，整个站点都可以被CNAME隐藏。

最好的解释方法是通过表（1p表示第一方，3p表示第三方）：

2018年6月，我们宣布对ITP进行更新，以检测和防御第一方跳动跟踪器。 2020年3月，我们宣布了一项增强功能，可以检测延迟的反弹跟踪。从那时起，我们收到了一份有关跳出跟踪的特定网站的报告，同时也有可能频繁地与用户互动。为了解决此类问题，我们向W3C隐私社区小组提出了所谓的SameSite = Strict监禁以及其他升级建议。

SameSite = strict监狱的工作是检测跳出跟踪，并在一定阈值下将所有跟踪域的Cookie重写为SameSite = strict。这意味着它们将不会在跨站点的第一方导航中发送，并且不再可以用于基于重定向的简单反弹跟踪。

我们的实现相当轻松，将阈值设置为10个唯一的导航，第一方重定向（就唯一域而言是唯一的），并且一旦将cookie重写为SameSite = strict后，该计数器就会自动重置。这会自动为域提供新的机会，使他们可以脱离跳出跟踪并“摆脱监禁”。

我们当前受此保护的域列表为空，因为报告给我们的域已停止其退信跟踪。但是这种保护仍然保留在我们的工具箱中。

到目前为止，WebKit已阻止跨域IndexedDB。现在，WebKit允许分区的和临时的第三方IndexedDB努力与其他浏览器保持一致，因为它们也对存储分区也很感兴趣。您可以参与GitHub上正在进行的存储分区标准化工作。

分区意味着每个第一方站点都有唯一的IndexedDB实例，短暂意味着仅在内存中，即在浏览器退出时消失。

Safari中的私人浏览基于WebKit的短暂会话，其中任何内容都不会持久保存到磁盘。这意味着ITP将无法在Safari启动之间学习东西。此外，私人浏览还为用户打开的每个新选项卡使用单独的临时会话。为了维持标签之间的这种分隔，ITP甚至无法从用户的完整浏览中对跨站点跟踪器进行分类。

但是，完整的第三方Cookie阻止功能不需要分类，并且默认情况下已在“私人浏览”中启用。这看起来似乎很容易支持，但是面临的挑战是使Storage Access API与上述选项卡分隔一起使用。它是这样工作的：假设identityProvider.example希望在登录页面上以第三方身份请求选项卡A中的social.example的存储访问。与identityProvider.example作为选项卡B中的第一方网站进行交互将无法允许它请求在选项卡A中进行存储访问，因为那样会在单独的临时会话之间泄漏状态。因此，用户必须在与identityProvider.example稍后请求第三方进行存储访问相同的选项卡中与identityProvider.example进行交互。这样可以确保在“私人浏览”模式下可以进行涉及两个不同方且需要第三方Cookie访问的登录流。

早在2020年3月，当我们宣布ITP对所有可写脚本的存储设置7天上限时，开发人员就询问了主屏幕Web应用程序以及是否不受此7天上限的限制。我们解释了ITP的“使用天数”计数器和如何捕获用户互动，如何有效地确保第一屏主屏幕应用程序不会受到新的7天上限的限制。为了更清楚地说明这一点，我们为主屏幕Web应用程序的第一方域实现了一个明确的例外，以确保ITP始终在其网站数据删除算法中跳过该域。

此外，主屏幕Web应用程序的网站数据与Safari保持隔离，因此不会受到ITP在Safari中跟踪行为分类的影响。

没有Kate，Jiten，Scott，Tommy，Sihui和David的帮助，不可能对WebKit和ITP进行以上更新。谢谢！