我们发现了一个稳定的 Firefox 标识符，可关联你所有私密的 Tor 身份

# 我们发现了一个稳定的 Firefox 标识符，可关联你所有私密 Tor 身份 来源：https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/ 我们最近发现一处影响所有基于 Firefox 的浏览器的隐私漏洞。该问题允许网站通过 IndexedDB 返回条目的顺序，生成一个唯一、确定且稳定的进程生命周期标识符，即使用户期望更强的隔离也无济于事。这意味着网站可以创建一组 IndexedDB 数据库，检查返回顺序，并将该顺序作为运行中浏览器进程的指纹。由于该行为作用于“进程范围”而非“源范围”，无关网站可在同一浏览器运行期间独立观察到同一标识符，并跨源关联活动（https://fingerprint.com/blog/external-protocol-flooding/）。 在 Firefox 隐私浏览模式（https://fingerprint.com/blog/firefox-privacy-security-guide/）下，即使所有隐私窗口都已关闭，只要 Firefox 进程仍在运行，该标识符就会持续存在。在 Tor Browser 中，即使使用“新身份”（https://support.torproject.org/tor-browser/features/managing-identities/）功能，该稳定标识符依旧存在；而该功能本应完全重置，清除 cookie 与浏览历史，并切换新 Tor 线路。官方描述称，该功能适用于“希望后续浏览活动无法与之前行为关联”的用户。此漏洞直接破坏了用户依赖的不可关联性保证。 我们已负责任地向 Mozilla 和 Tor Project 披露该问题。Mozilla 迅速在 Firefox 150（https://www.mozilla.org/en-US/security/advisories/mfsa2026-30/#CVE-2026-6770）和 ESR 140.10.0（https://www.mozilla.org/en-US/security/advisories/mfsa2026-32/#CVE-2026-6770）中发布了修复，补丁记录在 Mozilla Bug 2024220（https://bugzilla.mozilla.org/show_bug.cgi?id=2024220）。由于 Tor Browser 继承了 Gecko 的 IndexedDB 实现，因此该问题同时影响两款产品及所有基于 Firefox 的浏览器。 修复思路很直接：浏览器不应暴露反映进程级状态的内部存储顺序。在返回结果前进行规范化或排序即可消除熵值，防止该 API 成为稳定标识符。 ## https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/#why-this-matters ### 为何重要 隐私浏览模式和注重隐私的浏览器（https://fingerprint.com/blog/privacy-settings-detection/）旨在降低网站跨场景识别用户的能力。用户通常期望两点： 1. 无关网站不应知晓它们正在与同一浏览器实例交互，除非存在共享存储或明确身份机制。 2. 隐私会话结束后，相关状态应随之消失。 该问题同时违背了两项期望。网站无需 cookie、localStorage 或任何显式跨站通道，仅凭浏览器内部存储行为，即可从 API 返回的数据库名顺序中提取高容量标识符。 对开发者而言，这提醒我们：隐私漏洞并非总来自直接获取身份数据，有时源于内部实现细节的确定性暴露。 对安全与产品决策者而言，要点简单明了：即便看似无害的 API，一旦泄露稳定的进程级状态，也可能成为跨站跟踪向量。 ## https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/#what-is-indexeddb-and-what-does-indexeddbdatabasesdo ### 什么是 IndexedDB，`indexedDB.databases()` 做什么？ IndexedDB（https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API）是浏览器提供的结构化数据本地存储 API。Web 应用利用它实现离线功能、缓存、会话状态及其他本地存储需求。每个源可创建多个命名数据库，内含对象仓库与大量数据。 `indexedDB.databases()` API 返回当前源可见的数据库元数据。开发者常用它检查现有数据库、调试存储用量或管理应用状态。按照正常隐私期望，该 API 返回结果的顺序本身不应携带识别信息，而应呈现中性、规范或其他非敏感的元数据展示。 我们发现的漏洞在于：所有基于 Firefox 的浏览器返回的顺序并不中性。 ## https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/#howindexeddbdatabasesbecame-a-stable-identifier ### `indexedDB.databases()` 如何成为稳定标识符 在 Firefox 隐私浏览模式下，`indexedDB.databases()` 返回的数据库元数据顺序源自内部存储结构，而非数据库创建顺序。相关实现见 dom/indexedDB/ActorsParent.cpp（https://searchfox.org/firefox-main/source/dom/indexedDB/ActorsParent.cpp）。 在隐私浏览模式下，数据库名称不会直接用作磁盘文件名，而是通过全局哈希表映射到基于 UUID 的文件名： ```cpp using StorageDatabaseNameHashtable = nsTHashMap; StaticAutoPtr gStorageDatabaseNameHashtable; ``` 该映射在 `GetDatabaseFilenameBase()` 中被调用，位于 `OpenDatabaseOp::DoDatabaseWork()` 内。当 `aIsPrivate` 为真时，网站提供的数据库名被替换为生成的 UUID，并存入全局 `StorageDatabaseNameHashtable`。该映射： - 仅以数据库名字符串为键 - 在 IndexedDB QuotaClient 生命周期内持续存在 - 跨所有源共享 - 仅在 Firefox 完全重启时清除 随后，当调用 `indexedDB.databases()` 时，Firefox 通过 `QuotaClient::GetDatabaseFilenames(...)` 在 `GetDatabasesOp::DoDatabaseWork()` 中收集数据库文件名，并将其插入 `nsTHashSet`。迭代前未进行排序，最终结果顺序由哈希集内部桶布局决定。 由于 UUID 映射在 Firefox 进程生命周期内保持稳定，且哈希表结构与迭代顺序对给定内部布局具有确定性，返回顺序成为生成 UUID 值、哈希函数行为及哈希表容量与插入历史的确定性函数。该顺序在标签页与隐私窗口间保持一致，仅在整个 Firefox 重启后重置。 关键点是：UUID 映射与哈希集迭代并非源级作用域，而是进程级作用域。 ## https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/#reproducing-the-issue ### 复现方法 一个简单的概念验证即可演示行为。两个不同源托管同一段脚本，各自： 1. 创建一组固定命名的数据库。 2. 调用 `indexedDB.databases()`。 3. 提取并打印返回顺序。 在受影响的 Firefox 隐私浏览及 Tor Browser 版本中，两源在同一浏览器进程生命周期内观察到相同排列。重启浏览器后排列改变。概念输出如下： ``` created: a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p listed: g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k ``` 关键不在于具体顺序，而在于顺序并非原始创建顺序，无关源却看到同一顺序，且在重载、新建隐私窗口后依旧保持，即使所有隐私窗口已关闭。只有完全重启浏览器才会生成新顺序——这正是隐私角度最不希望出现的情况。 ## https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/#privacy-impact ### 隐私影响 该问题允许在同一浏览器运行期间进行跨源及同源跟踪。 ### https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/#cross-origin-impact #### 跨源影响 无关网站可独立得出同一标识符，并推断它们正与同一运行中的 Firefox 或 Tor Browser 进程交互，从而在无 cookie 或其他共享存储的情况下跨域关联活动。 ### https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/#same-origin-impact #### 同源影响 在 Firefox 隐私浏览模式下，只要 Firefox 进程仍在运行，即使所有隐私窗口已关闭，标识符仍可留存。这意味着站点可在看似全新的隐私会话中识别后续访问。 在 Tor Browser 中，稳定标识符直接破坏“新身份”隔离，允许网站关联本应完全隔离的会话。 ### https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/#why-this-is-especially-serious-in-tor-browser #### 为何在 Tor Browser 中尤为严重 Tor Browser 专为降低跨站可关联性并最小化浏览器实例级身份而设计。稳定的进程生命周期标识符直接违背该设计目标，即便仅持续到完整进程重启，也足以削弱使用期间的不可关联性。 ## https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/#entropy-and-fingerprinting-capacity ### 熵值与指纹容量 该信号不仅稳定，且容量极高。若站点控制 `N` 个数据库名，则可观测的排列数为 `N!`，理论熵为 `log₂(N!)`。使用 16 个受控名称时，理论空间约 44 比特，远超区分实际并发浏览器实例所需。受内部哈希表行为影响，实际可达排列数可能略低，但这并不改变安全本质：暴露的顺序仍提供足够熵值，足以充当强标识符。 ## https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/#the-fix ### 修复方案 正确修复方式是停止暴露源自内部存储布局的熵值。最简洁的缓解措施是按规范顺序返回结果，例如按字典序排序。这样既保留 API 对开发者的可用性，又消除指纹信号。每次调用随机化输出亦可隐藏稳定顺序，但排序更简单、可预测，且便于开发者理解。 从安全工程角度，理想修复具备： - 低概念复杂度 - 最小兼容性风险 - 直接消除隐私泄露 ## https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/#responsible-disclosure ### 负责任披露 我们已负责任地向 Mozilla 与 Tor Project 披露该问题。Mozilla 已在 Firefox 150（https://www.mozilla.org/en-US/security/advisories/mfsa2026-30/#CVE-2026-6770）和 ESR 140.10.0（https://www.mozilla.org/en-US/security/advisories/mfsa2026-32/#CVE-2026-6770）中发布修复，补丁追踪于 Mozilla Bug 2024220（https://bugzilla.mozilla.org/show_bug.cgi?id=2024220）。由于该行为源自 Gecko 的 IndexedDB 实现，所有基于 Gecko 的浏览器（包括 Tor Browser）均受影响，除非自行应用缓解措施。 ## https://fingerprint.com/blog/firefox-tor-indexeddb-privacy-vulnerability/#building-for-privacy ### 为隐私而构建 该漏洞表明，一个微小的实现细节即可造成重大隐私问题。其影响显著：无关网站可在同一浏览器运行期间跨源关联活动，且私有会话边界被削弱，因为标识符的存活时间超出用户预期。 好消息是修复简单有效：在返回前对输出进行规范化，即可消除该熵源，恢复预期的隐私边界。这正是值得关注的典型问题：隐蔽、易被忽视，却对构建隐私敏感型浏览器功能者极具启发。