2026 年 4 月 22 日，网络安全研究人员发现了一个影响所有基于 Firefox 内核浏览器的严重隐私漏洞。

这个漏洞让所有网站在同一个基于 Firefox 内核浏览器进程里，都能看到完全相同的 IndexedDB 数据库排列顺序，这个顺序跨刷新、跨私密窗口都不变，只有重启浏览器才会变，因此可以用来跨网站跟踪用户。

这个漏洞允许网站通过一个看似无害的浏览器 API，生成一个唯一且稳定的进程级标识符，从而在用户不知情的情况下跨网站追踪其活动。

更令人担忧的是，这个标识符甚至能够绕过 Firefox 隐私浏览模式和 Tor 浏览器的 "New Identity" 功能，直接打破用户对隐私隔离的基本预期。

隐私浏览模式和以 Tor 为代表的隐私浏览器，核心设计目标就是减少网站跨上下文识别用户的能力。

绝大多数用户使用这些功能时，都抱有两个基本信任。

第一，不相关的网站无法判断它们正在与同一个浏览器实例交互，除非用户主动共享身份信息。

第二，当隐私会话结束后，所有与该会话相关的状态都会被彻底清除。

这次发现的漏洞同时打破了这两个信任。

网站不需要依赖 cookies、localStorage 或任何明确的跨站通信渠道。它们只需要利用浏览器自身的内部存储行为，就能从一个标准 API 返回的数据库名称顺序中，提取出高容量的唯一标识符。

对于开发者而言，这个漏洞是一个重要提醒。隐私漏洞并不总是来自对识别数据的直接访问。很多时候，它们源于对内部实现细节的确定性暴露。对于安全和产品负责人来说，这个案例传递的信息同样明确。即使是看起来完全无害的 API，只要它泄露了稳定的进程级状态，就可能成为跨站追踪的工具。

什么是 IndexedDB 和 indexedDB.databases ()

IndexedDB 是浏览器提供的一种客户端结构化数据存储 API。

Web 应用程序通常使用它来实现离线支持、数据缓存、会话状态管理等功能。每个网站源站可以创建一个或多个命名数据库，这些数据库可以存储对象仓库和大量数据。

indexedDB.databases()是 IndexedDB 标准中的一个 API，它返回当前源站可见的所有数据库的元数据。在实际开发中，开发者可能会用它来检查现有数据库、调试存储使用情况或管理应用状态。

按照正常的隐私预期，这个 API 返回结果的顺序本身不应该携带任何识别信息。

它应该只是以一种中立、规范或其他非敏感的方式呈现数据库元数据。

但研究人员发现，在所有基于 Firefox 内核的浏览器中，这个返回顺序远非中立。

一个看似无害的 API 如何变成追踪工具

在 Firefox 隐私浏览模式下，indexedDB.databases()返回数据库元数据的顺序，并非来自数据库的创建顺序，而是来自浏览器内部的存储结构。

相关实现位于 Firefox 源代码的dom/indexedDB/ActorsParent.cpp文件中。在隐私浏览模式下，网站提供的数据库名称不会直接用作磁盘上的标识符。相反，它们会通过一个全局哈希表映射到基于 UUID（通用唯一识别码）的文件名基础。

    using StorageDatabaseNameHashtable = nsTHashMap;StaticAutoPtrgStorageDatabaseNameHashtable;

    这个映射过程在OpenDatabaseOp::DoDatabaseWork()函数调用的GetDatabaseFilenameBase()函数内部完成。

    当aIsPrivate标志为真时，网站提供的数据库名称会被替换为一个生成的 UUID，并存储在全局的StorageDatabaseNameHashtable中。

    这个映射具有四个关键特性。

    1、它仅以数据库名称字符串作为键。

    2、它在 IndexedDB QuotaClient 的整个生命周期内保持稳定。

    3、它在所有源站之间共享。

    4、它只有在 Firefox 完全重启时才会被清除。

    之后，当调用indexedDB.databases()时，Firefox 会通过GetDatabasesOp::DoDatabaseWork()函数中调用的QuotaClient::GetDatabaseFilenames(...)方法收集数据库文件名。

    数据库基础名称会被插入到一个nsTHashSet中，在迭代之前不会进行任何排序操作，最终结果的顺序由哈希集内部桶布局的迭代顺序决定。

    由于 UUID 映射在 Firefox 进程的整个生命周期内都是稳定的，并且哈希表的结构和迭代顺序对于给定的内部布局是确定的，因此返回的顺序成为生成的 UUID 值、哈希函数行为以及哈希表容量和插入历史的确定性函数。

    漏洞复现

    一个简单的POC就足以演示该行为。两个不同的源（origin）托管着相同的脚本。

    每个脚本会：

    1. 创建一组固定的命名数据库

    2. 调用 .indexedDB.databases() API

    3. 提取并打印返回的数据库顺序

    在受影响的Firefox 私密浏览模式和Tor 浏览器版本中，在同一个浏览器进程的生命周期内，两个完全无关的源会观察到完全相同的数据库排列顺序。只有重启浏览器才会改变这个排列顺序。

    从概念上讲，输出看起来是这样的：

    创建顺序： a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p

    查询返回顺序： g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k

    关键问题不在于顺序本身是什么，而在于：

    • 这个顺序不是数据库的原始创建顺序

    • 完全无关的网站源会看到完全相同的顺序

    • 该顺序会在页面刷新、打开新的私密窗口后持续存在，甚至在关闭所有私密窗口后依然保留

    • 只有完全重启浏览器才会生成一个新的随机顺序

    从隐私保护的角度来看，这正是你绝对不希望看到的情况。

    这个顺序在不同标签页和隐私窗口之间保持一致，只有在完全重启 Firefox 时才会重置。至关重要的是，UUID 映射和哈希集迭代不是源站范围的，而是进程范围的。

    因此，这个漏洞允许在单个浏览器运行时内进行跨源和同源追踪，不相关的网站可以独立推导出相同的标识符，并推断出它们正在与同一个运行中的 Firefox 或 Tor 浏览器进程交互。这使得它们无需 cookies 或其他共享存储，就能跨域名链接用户活动。

    在 Firefox 隐私浏览模式下，即使所有隐私窗口都已关闭，只要 Firefox 进程本身仍在运行，该标识符就可以继续存在。这意味着网站可以识别出用户在看似全新的隐私会话中的后续访问。

    在 Tor 浏览器中，这个稳定的标识符实际上绕过了 Tor 浏览器的 "New Identity" 隔离功能。该功能原本设计为完全重置，会清除 cookies 和浏览器历史记录，并使用新的 Tor 链路。它的描述是为那些 "希望防止其后续浏览器活动与之前所做的事情相关联" 的用户提供的。这个漏洞实际上破坏了用户所依赖的不可链接性隔离保证。

    为什么这个问题在 Tor 浏览器中尤其严重？

    因为 Tor 浏览器的核心设计目标就是减少跨站可链接性，并最小化浏览器实例级别的身份。一个稳定的进程生命周期标识符直接违背了这个设计目标。即使它只持续到进程完全重启，也足以在用户活跃使用期间削弱不可链接性。

    如果一个网站控制了 N 个数据库名称，那么可能观察到的排列数量是 N 的阶乘，理论熵值为 log2 (N!)。使用 16 个受控名称时，理论空间约为 44 位。这远远超过了在实际中区分合理数量的并发浏览器实例所需的熵值。

    说白了，可供追踪生成的浏览器指纹强度极高，用 16 个数据库名称就能产生约44 位熵值（相当于 17 万亿种唯一排列），完全足够区分互联网上所有同时在线的浏览器用户。

    由于内部哈希表行为的影响，实际可达到的排列数量可能会略低，但这并不会从根本上改变安全结论。暴露的顺序仍然提供了足够多的熵，可以作为一个强大的标识符。

    正确的修复方法是停止暴露源自内部存储布局的熵。最简洁的缓解措施是按规范顺序返回结果，例如字典序排序。这既保留了 API 对开发者的实用性，又消除了指纹识别信号。每次调用时随机化输出也可以隐藏稳定的顺序，但排序更简单、更可预测，也更容易让开发者理解。

    从安全工程的角度来看，一个理想的修复应该具备三个特点。概念复杂度低。兼容性风险最小。直接消除隐私泄露。

    简单来说，它能在你完全不知情的情况下，把你在互联网上的所有活动都串到同一个人身上。

    具体能做什么：

    1. 跨所有网站跟踪你

      你访问 A 网站、B 网站、C 网站... 哪怕它们之间没有任何合作，也能通过这个 "数据库顺序指纹" 认出是同一个用户。

    2. 彻底击穿私密浏览模式

      你以为开无痕 / 私密窗口就没人知道了？没用。同一个浏览器进程里，所有私密窗口共享同一个指纹。

    3. 对 Tor 用户是毁灭性打击

      Tor 的核心就是让每次会话都无法关联。但这个漏洞能让不同的 Tor 会话、不同的洋葱站点都认出是同一个人，直接废掉匿名性。

    4. 常规清除手段完全无效

      删 Cookie、清缓存、关闭所有私密窗口都没用。只有彻底重启浏览器，指纹才会变一次。

    研究人员已经负责任地向 Mozilla 和 Tor 项目披露了这个问题。Mozilla 已在 Firefox 150 和 ESR 140.10.0 版本中发布了修复程序，该补丁在 Mozilla Bug 2024220 中进行跟踪。由于该行为源自 Gecko（火狐浏览器的渲染引擎）的 IndexedDB 实现，所有基于 Gecko 的下游浏览器，包括 Tor 浏览器，都受到影响，除非它们应用自己的缓解措施。

    *原文为著名网站信息浏览器指纹识别脚本FingerprintJS的创建公司发布，因此谨慎打开网站阅读。

    声明：本文来自黑鸟，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。