逃离矩阵：Privacy Sandbox API的客户端去匿名化攻击

引言

Google的Privacy Sandbox计划旨在支持常见的广告技术功能，如转化跟踪和受众细分，同时保护个人隐私。在后Cookie时代，浏览器默认阻止第三方Cookie，这一举措变得尤为重要。该计划的关键支柱是引入Chrome和基于Chromium的浏览器中的一组Web和移动API，这些API实现了这些隐私保护功能。

Attribution Reporting API

Attribution Reporting API是Privacy Sandbox的核心转化跟踪API。简而言之，它报告在网站A（发布商）上查看的广告是否导致在网站B（广告商）上购买产品等转化。它通过请求和响应头在客户端浏览器或操作系统中存储转化跟踪数据来实现这一点。

当用户访问显示广告的发布商网站时，广告将向归因源服务器发送Attribution-Reporting-Eligible: source头。服务器然后响应一个Attribution-Reporting-Register-Source头，其值是一个JSON编码的字符串，包含有关事件目标目的地（最多3个）和其他转化标准的数据。

另一方面，当发送带有Attribution-Reporting-Eligible: trigger头的请求并收到带有Attribution-Reporting-Register-Trigger头的响应时，会注册归因触发器，其值也是JSON编码的字符串。

获取Privacy Sandbox访问权限

Google将Privacy Sandbox作为一个封闭花园运营，这意味着像Attribution Reporting API这样的API只能用于向Google注册的白名单源。有趣的是，Privacy Sandbox在https://github.com/privacysandbox/attestation 维护一个有些过时的透明存储库，其中列出了注册站点。

泄露的调试报告

如Attribution Reporting API文档所述，API支持"过渡性调试报告"，每当发生归因事件时，这些报告会向报告源发送包含额外信息（包括源或目标站点）的调试报告。

关键影响之一是，额外的跨站点请求将独立于浏览上下文发生。这创建了安全问题，正如GitHub文档中一个无害的提示所示。

我们可以用以下概念验证PHP页面快速演示这一点：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


<?php
  header("Referrer-Policy: no-referrer");
?>
<!DOCTYPE html>
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Ad</title>
</head>
<body>
  <img width="180" src="https://simeola.com/register-source.php" attributionsrc />
</body>

在这种情况下，Referrer-Policy明确设置为最严格的no-referrer值，以省略页面发出的任何请求中的Referrer头。

不出所料，Attribution Reporting API设计为支持所有归因源和触发器注册请求的Referrer-Policy，这些请求在顶级站点的浏览上下文中生成。

然而，调试报告绕过了这种保护。如果访问此页面，它将首先向归因源https://simeola.com/register-source.php发送请求。由于此请求在浏览上下文中生成，它尊重引用策略，确实在没有Referrer头的情况下发送归因报告请求。

然而，在成功源注册后，它还会发送一个调试报告，其中包含source_site，其值通常包含在Referrer头中！无论如何，由于调试报告在与顶级站点分开的上下文中发送，它首先不会发送Referrer头。

目标劫持和存储限制Oracle旁道攻击

Attribution Reporting API的一个关键安全机制是速率限制，限制每个（源站点、目标站点、报告站点、用户）的最大归因数以及其他报告。理想情况下，这减慢了数据报告站点可以收集关于任何特定个人的数据的速率。

虽然Attribution Reporting API团队讨论了拒绝服务攻击的风险，并且速率限制有详细文档，但对存储限制的关注较少，存储限制也存在，但仅用以下简短段落解决：

“浏览器可能应用存储限制以防止过度资源使用。API当前对每个源的待处理源和每个目标站点的待处理事件级报告有存储限制。”

虽然每个目标站点的事件级报告的存储限制没有明确记录，但在Chrome上发现为1000。当达到此存储限制时，不是存储更多报告，而是向该目标的任何新源触发器匹配的报告源发送类型为trigger-event-storage-limit的错误调试报告。

要利用此oracle，我们可以利用在Attribution Reporting API的实际使用中观察到的错误配置。广告平台通常在其广告商的实际目标旁边注入不存在的调试目标到源注册中。

Shared Storage API

Shared Storage API是另一个普遍可用的Privacy Sandbox API，支持跨站点数据存储和访问。一个用例是识别用户的受众群体，使广告平台能够跨多个站点定制与该用户最相关的广告。

这实现的关键隐私好处是，它允许设置此类数据而不允许直接读取数据；相反，数据在工作脚本的输出门中使用，以配置嵌入页面无法访问的围栏框架。

不安全的跨站点工作脚本代码

Shared Storage的主要假设之一是，通过仅允许在工作脚本中读取数据，这防止了将这些数据与浏览上下文直接共享。然而，这意味着很大程度上取决于实际的工作脚本代码本身。

当然，Shared Storage还进一步将工作脚本的输出限制到特定的输出门，如selectURL()和run()，防止工作脚本直接返回Shared Storage数据作为字符串。然而，通过不安全的工作脚本代码，仍然可能完全泄露数据，正如我们将看到的。

结论

Privacy Sandbox引入了几个新的复杂API。特定设计选择的安全和隐私影响，如调试报告、速率限制和跨域处理，可能甚至其创建者尚未完全枚举或探索。因此，这些API的弱实现将会出现，并可以以各种方式被利用，如本博客文章所示。

还有更多有待发现。我观察到其他奇怪的调试域被注入广告平台的归因报告目标中。另外，整个Privacy Sandbox的聚合服务，涉及在您自己的GCP或AWS账户中设置"可信执行环境"，也是一个重要的研究目标。

各种Web API的开发是一个漫长而艰苦的旅程，其中各种假设被证明是错误的，需要多轮加固才能达到稳定状态。Privacy Sandbox API将受益于安全和隐私研究人员的更严格审查，以更好地实现其声明的隐私保护广告技术目标。