安全浏览如何未能保护用户隐私 - Trail of Bits博客

Trail of Bits博客
安全浏览如何未能保护用户隐私
Trail of Bits
2019年10月30日
密码学

近期，安全研究人员发现苹果公司将所有中国用户的安全浏览数据发送给腾讯。这一发现使得安全浏览协议的底层安全和隐私保障受到更严格审查。特别是，安全浏览声称通过提供所谓的k-匿名性来保护用户。在本文中，我们将展示这种隐私定义在安全浏览的背景下某种程度上是无意义的。在深入探讨k-匿名性为何不足之前，让我们先看看安全浏览协议的工作原理。

安全浏览如何工作？

不久前，谷歌认为利用其对网络的了解向Web客户端提供恶意网站数据库会很有用。最初，用户会将其IP地址和相关URL提交给谷歌，随后会对照恶意软件数据库进行检查。该方案称为查找API，至今仍可用。然而，人们很快对放弃如此多的隐私感到不安。这种合理的担忧导致了当前安全浏览方案的发展，称为更新API，谷歌和腾讯都在使用。

来自Gerbet等人的安全浏览更新API流程图

在高层次上，谷歌维护一个恶意URL及其256位哈希的列表。为了在向浏览器分发此列表时节省带宽，他们只发送每个哈希的32位前缀。这意味着当用户的浏览器检查网站是否恶意时，可能会得到误报，因为许多256位URL哈希将包含相同的32位前缀。为了补救这一点，如果发生匹配，浏览器将向谷歌发送相关的32位前缀，并获取包含该前缀的所有256位哈希的完整URL列表。回顾一下，安全浏览更新API在用户每次尝试访问新URL时执行以下步骤：

1. 浏览器对URL进行哈希处理，并对照（本地）32位前缀列表进行检查。
2. 如果匹配，浏览器向谷歌发送32位前缀。
3. 谷歌然后发回所有包含该前缀的256位哈希的黑名单URL。
4. 如果更新列表中有匹配，浏览器向用户发出警告。

直观上，这种安全浏览方案比原始方案更私密，因为谷歌只知道用户访问的每个潜在恶意网站的32位前缀。确实，谷歌认为它为用户提供了所谓的k-匿名性——隐私分析师用来确定识别信息唯一性的一种度量。让我们看看k-匿名性到底是什么，以及安全浏览在多大程度上满足这一定义。

什么是k-匿名性

传统上，k-匿名性用于从数据库中删除个人识别信息。在高层次上，它涉及删除敏感数据，直到数据集中的每个人在特定特征上“看起来像”至少k个其他人。例如，如果我们有图1中的医疗记录表，我们可以修改姓名和年龄字段，使患者在姓名、年龄、性别和州方面实现2-匿名，如图2所示。

图1

任何试图使用这些数据的人都会获得执行某种统计分析所需的所有信息（表面上你的名字不会真正影响你患结核病的可能性），但数据库中的任何人都会“看起来像”至少两个其他人。这样，试图去匿名化人们的攻击者将失败，因为他们无法区分看起来相似的三个条目。显然，k越大越好；如果攻击者是试图使用医疗数据作为提高你保费理由的保险提供商，提供2-匿名性的数据库可能不够。在图2中，如果保险公司知道你在数据库中并且是来自加利福尼亚的52岁女性，他们将能够推断你患有癌症或心脏病，并开始向你收取更多费用。

图2

回到安全浏览：我们可以看到，将谷歌或腾讯可查看的URL限制为32位哈希前缀，使得两个提供商都无法将你的请求与具有相同哈希前缀的任何其他URL区分开。问题是，我们预计会发生多少次这样的碰撞？2015年，Gerbet等人得出结论，每个前缀在网络中大约出现14757次，这意味着安全浏览的用户可以期望他们的浏览数据大约为14757-匿名。换句话说，谷歌/腾讯只知道你尝试访问的网站包含在大约14757个网站的集合中，这可能足够大，包含许多在政治（或商业）上不会非常暴露的通用网站。

为什么k-匿名性未能保护用户

尽管安全浏览满足k-匿名性的定义，但实际上谷歌从这些查询中恢复你的浏览数据并不难。这种不安全是由于k-匿名性的隐私保证没有考虑谷歌交叉引用多个安全浏览查询并缩小给定32位前缀对应的特定网站的能力。

作为这种攻击的第一个例子，回想一下谷歌对安全浏览使用cookie，因此可以看到多个查询是否来自同一IP地址。现在，假设www.amazon.com和https://www.amazon.com/gp/cart/view.html?ref_=nav_cart都与两个不同的恶意网站共享32位哈希前缀。如果用户快速连续访问亚马逊和他们的购物车，谷歌将收到两个32位哈希前缀。由于用户不太可能连续访问两个不相关的恶意网站，谷歌可以合理地确定他们在亚马逊上购物。这种攻击仅在两个相关网站都与恶意网站共享32位哈希前缀并且用户在小时间窗口内访问它们时有效。然而，这个例子已经表明，当面对能够关联多个查询的对手时，k-匿名性并不是那么有用。

但情况实际上更糟，因为安全浏览协议经常强制用户同时提交几个高度相关的URL。这些多个查询的发生是因为许多URL在某种意义上“太具体”，谷歌无法跟踪，因为恶意网站创建新URL的速度比谷歌报告每个特定URL的速度快。为了解释这一点，用户为每个查询提交一组“URL分解”，这是通过逐步剥离URL的部分来构建的。例如，当访问URL http://a.b.c/1/2时，浏览器将同时对照安全浏览数据库检查以下URL：

• a.b.c/1/2
• a.b.c/1/
• a.b.c/
• b.c/
• b.c/1/

使用完整的URL分解允许谷歌为用户提供高度信心，确保他们访问的网站不是恶意的。然而，一次性提交许多高度相关的32位哈希前缀破坏了安全浏览协议最初提供的大部分隐私。如果谷歌在同一查询中收到对应于a.b.c/和a.b.c/1的32位哈希前缀，它可以轻松地去匿名化用户的浏览数据。即使在提交多个前缀不会导致完整URL恢复的情况下，也可能有足够的信息来了解用户浏览历史的敏感细节。

为了更具体，Gerbet等人表明，这种URL分解攻击可用于识别用户的色情内容偏好——压迫性政府肯定有兴趣监控这一点。更糟糕的是，由于这些恶意软件数据库不公开，很难确定哈希前缀是否未被恶意包含以跟踪用户。虽然我们可能信任谷歌不会操纵数据库以确定用户何时访问亲香港网站，但很容易想象腾讯会利用此漏洞。

展望未来

虽然安全浏览无疑为用户提供了真正的安全好处，但它未能保护他们免受想要监控其浏览习惯的公司或政府的侵害。不幸的是，这种隐私缺失被协议为用户提供的弱但技术上精确的匿名性概念所掩盖。随着技术界和法律界围绕k-匿名性和差分隐私等工具团结起来，我们需要记住它们不是一刀切的技术，理论上满足此类定义的系统在实际部署时可能无法提供真正有意义的隐私。

如果你考虑在应用程序中使用差分隐私或k-匿名性等工具，我们的密码学服务团队可以帮助你驾驭这些系统的固有微妙之处。无论你需要协议设计帮助还是审计现有代码库，我们的团队都可以帮助你构建用户能够信任的东西。

如果你喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News

页面内容
近期文章
使用Deptective调查你的依赖项
系好安全带，Buttercup，AIxCC的评分回合正在进行中！
使你的智能合约超越私钥风险
Go解析器中意想不到的安全隐患
我们审查首批DKLs23库的收获
来自Silence Laboratories的23个库
© 2025 Trail of Bits。
使用Hugo和Mainroad主题生成。