浏览器指纹追踪一直是隐私保护领域的核心挑战。传统上，网站依赖 Cookie、LocalStorage 或 Canvas 渲染等手段识别用户，但现代隐私浏览模式已针对这些向量做了充分防御。然而，2026 年发现的 Firefox IndexedDB 漏洞展示了另一种更为隐蔽的攻击面：浏览器内部存储结构的实现细节本身就能产生稳定的进程级标识符，即使在 Tor Browser 的严格隔离环境下也难以幸免。
漏洞核心机制
问题出在 indexedDB.databases() 这个 API 上。该接口本应返回当前域名下已创建的 IndexedDB 数据库元数据，其设计初衷是为开发者提供调试和存储管理的便利。在正常隐私预期下，数据库名称的返回顺序应当是中性的、不会携带可识别信息的状态。然而，Firefox 在私有浏览模式下的实现细节打破了这个假设。
当网站调用 indexedDB.databases() 时，Firefox 并非按数据库创建顺序返回结果，而是遍历内部哈希表的存储结构来收集数据库文件名。关键在于，私有浏览模式下数据库名称并非直接用作磁盘文件名，而是通过一个全局哈希表映射为 UUID。这个映射关系具有以下特性：仅以数据库名称字符串作为键、贯穿整个 IndexedDB QuotaClient 生命周期、在所有源之间共享、只有 Firefox 完全重启时才会被清除。随后，当调用 indexedDB.databases() 时，Firefox 通过 QuotaClient::GetDatabaseFilenames 收集数据库文件名，并将基名插入 nsTHashSet。由于插入前未进行排序，最终返回的顺序由哈希表的内部桶布局和迭代顺序决定，而这一顺序对于给定的内部布局和 UUID 映射是确定性的。
这意味着，来自不同源的网站只要在同一个浏览器进程生命周期内创建相同数量的数据库，并查询返回顺序，就能观察到完全相同的排列组合。这个排列组合本质上就是一个进程级的稳定标识符，Resetting the browser is the only way to change it.
为什么这对 Tor Browser 危害巨大
Tor Browser 的设计目标是为用户提供强匿名性，其核心承诺包括跨站点不可链接性以及「New Identity」功能能够完全重置浏览器状态。然而，这个漏洞直接击穿了这两层防御。
攻击者可以在一个源上创建一个固定集合的 IndexedDB 数据库，调用 indexedDB.databases() 记录返回顺序，然后在另一个完全无关的源上重复相同操作。由于映射和哈希表迭代在进程级别是共享的，两个源将观察到相同的顺序，从而推断出它们正在与同一个浏览器进程交互。令人担忧的是，即使用户使用 Tor Browser 的「New Identity」功能创建新身份 —— 这个功能本应清除 Cookie、历史记录并使用新的 Tor 线路 —— 这个稳定标识符仍然保持不变，因为底层进程并未重启。只要浏览器进程继续运行，UUID 映射和哈希表状态就持续存在，这使得网站能够将用户在「隔离」会话中的活动链接在一起。
从熵的角度分析，如果攻击者控制 N 个数据库名称，可能的排列组合数为 N 个阶乘，理论熵为 log2 (N!)。使用 16 个受控名称，理论空间约为 44 比特，这在实际场景中足以区分并发浏览器实例。
修复方案与防护建议
Mozilla 已在 Firefox 150 和 ESR 140.10.0 中修复此问题，修复思路简洁有效：在返回结果之前对数据库名称进行字典序排序，消除内部存储结构带来的熵。这样既能保留 API 的开发可用性，又从根本上消除了指纹识别信号。Tor Browser 作为基于 Gecko 的下游浏览器，也需要应用相应的缓解措施，除非其自行实现了额外的防护。
对于普通用户，最直接的防护措施是将 Firefox 更新至包含修复的最新版本。对于高敏感性活动使用者，应确认 Tor Browser 已应用相关修复或等待官方更新。此外，尽量避免在同一浏览器进程内混合进行隐私敏感浏览和常规浏览，因为进程级标识符正是能够桥接不同会话的那种状态。
这个漏洞给安全工程师的启示在于：隐私问题并不总是来自对敏感数据的直接访问，有时恰恰源于内部实现细节的确定性暴露。即使是看似中性的 API，只要它泄露了进程级或系统级的状态信息，就可能成为跨站追踪的向量。在设计和审计浏览器隐私功能时，必须将这种间接泄露纳入威胁模型。
资料来源：Fingerprint.com 博客披露的技术分析报告（Mozilla Bug 2024220，CVE-2026-6770）。