本文由慢雾区白帽 wowo 投稿，内容基于其对多款主流指纹浏览器产品开展的实战安全审计总结。

前言

指纹浏览器(Antidetect Browser) 作为近年来快速崛起的工具类软件，被广泛应用于跨境电商多账号管理、社交媒体运营、广告投放，以及 Web3 领域的空投交互（“撸毛”）、多钱包管理等场景。其核心卖点是”隔离浏览器指纹、保护账号安全”，用户往往将大量高价值数字资产——包括电商平台登录态、社交媒体会话、支付凭据，乃至加密货币钱包的私钥和助记词——托管于其中。

然而，经过对行业内多款主流指纹浏览器产品进行深度安全审计后，我们发现了一个令人担忧的现实：这些以”安全”为核心卖点的产品，其自身的安全防护水平远低于行业预期，且存在高度共性的系统性安全缺陷。

事件一：钱包插件供应链投毒——数百万美元被盗（2024 年）

损失规模：被盗资金超过 410 万美元，约 3 万名用户受到影响，被盗资产被迅速分散至多个地址并通过混币器洗白。

事件经过：多名用户发现安装该指纹浏览器后，其加密货币钱包中的资产被转移。安全团队追踪发现，超过 3000 个钱包地址受到影响，被盗 ETH 被迅速转移至多条链(zkSync、Arbitrum、Optimism)，部分资金流入隐私协议(Tornado Cash、Railgun) 进行洗白。

除供应链攻击外，行业内还持续发生仿冒官网分发带病毒指纹浏览器的事件。攻击者注册与正版官网高度相似的域名（如拼写错误的变体），部署含有远控木马的篡改版安装包，通过搜索引擎优化(SEO) 或社交工程诱导用户下载。用户一旦安装，设备即被完全控制，所有密码、密钥、会话信息均面临泄露风险。

事件启示

当用户将数十甚至上百个高价值账号、加密钱包集中托管在一款指纹浏览器中时，该产品就成了一个极具吸引力的”蜜罐”。攻击者无需逐一攻破每个平台的账号，只需攻破指纹浏览器这一个点，就能一网打尽全部资产。

指纹浏览器在 Web3 领域的广泛应用，带来了一个传统电商场景中不存在的特殊高危风险维度。

• 多账号交易：在去中心化交易所(DEX)、借贷协议中管理多个交易账户。 

• GameFi 多开：链游中多账号同时在线运营。

2.2 钱包插件托管：致命的信任集中

指纹浏览器环境 #1 →  安装 MetaMask  →  导入钱包 #1 (私钥/助记词)        ...                                    ...

从安全角度看，这创造了一个极端危险的信任集中模型：

在技术层面，指纹浏览器对加密钱包插件构成了以下独有的威胁——这些威胁在用户使用普通的 Chrome/Firefox 浏览器时并不存在：

（1）插件分发链路可被劫持

在 Electron 架构中，指纹浏览器的主进程（Node.js 环境）对所有浏览器环境的本地存储数据拥有完整的文件系统访问权限。这意味着钱包扩展在本地加密存储的 Vault 文件（包含加密后的私钥）理论上可以被主进程读取。如果主进程存在漏洞（如前述的任意文件读取接口），或者厂商主动植入后门，用户的钱包私钥将直接暴露。

这与加密货币”Not your keys, not your coins”的核心安全理念形成了根本性矛盾。

这一切可以在几十秒内全自动完成，用户从看到恶意网页到资产被清空，可能全程毫无感知。

Web3 用户在指纹浏览器中的攻击面

供应链层

• 钱包插件被替换为恶意版本（已发生，损失 410 万美元）

• 浏览器内核被替换为含后门版本 

• 仿冒官网分发带木马的安装包 

↓      

客户端层

• 主进程读取钱包扩展 Vault 文件（任意文件读取漏洞）

• XSS → RCE → 提取本地钱包数据 

• 恶意网页通过本地 API 枚举并启动环境  

• 厂商内部人员或被入侵后访问云端备份数据 

↓  

结果 

• 私钥/助记词泄露 → 资产被转移

• 交易签名被篡改 → 授权恶意合约

• 全部钱包一次性清空 → 不可逆损失   

三、行业共性安全风险概览

风险一：桌面框架安全配置严重缺失

普遍性：几乎所有产品均存在不同程度的问题。

当前主流指纹浏览器几乎无一例外地采用 Electron 框架构建桌面客户端。Electron 将 Chromium 渲染引擎与 Node.js 运行时打包在一起，本身提供了一套完善的安全配置机制——包括进程隔离、上下文隔离、沙箱模式等。然而在实际审计中，我们发现绝大多数产品未正确配置这些安全选项，甚至主动关闭了关键安全防护。

最典型的表现包括：

• 主窗口开启 Node.js 集成(nodeIntegration)：这意味着在渲染页面中执行的任何 JavaScript 代码都可以直接调用操作系统级 API，包括文件读写、进程创建、网络请求等。一旦页面存在任何脚本注入漏洞，攻击者可立即获得系统级控制权。

• 关闭上下文隔离(contextIsolation)：Electron 的上下文隔离机制旨在防止网页脚本访问 Node.js API。关闭此选项等同于拆除了浏览器沙箱的最后一道屏障。

• 全局禁用沙箱(sandbox)：部分产品在启动参数中全局关闭了 Chromium 的沙箱机制，使得渲染进程获得了远超正常浏览器页面的系统权限。

• 窗口安全配置不一致：在同一产品中，不同功能窗口（主窗口、弹出窗口、通知窗口、调试窗口等）使用不同的安全配置。即便主窗口配置相对安全，辅助窗口的安全缺口同样可以被利用作为攻击入口。

• 导航限制缺失或可绕过：未设置或不当设置页面导航白名单，使用子串匹配而非严格的域名校验，导致攻击者可以构造特殊域名绕过限制，将主窗口导航至恶意页面。

风险本质：桌面框架的安全配置决定了漏洞的”天花板”——配置得当时，一个 XSS 漏洞只是中等风险；配置失当时，同样的 XSS 就等同于操作系统级的远程代码执行(RCE)。遗憾的是，多数指纹浏览器厂商并未充分理解这一点。

风险二：本地服务接口零认证暴露

普遍性：大多数产品存在此问题，严重程度从中危到极危不等。

指纹浏览器通常需要在本地运行 HTTP 或 WebSocket 服务，用于客户端内部通信、浏览器扩展交互、自动化接口等目的。然而审计发现，多数产品的本地服务存在以下问题的组合：

致命三连击模式：

1. CORS 完全开放(Access-Control-Allow-Origin: *)：允许互联网上任意网页对本地服务发起跨域请求。

2. 零认证：所有 API 端点不要求任何形式的身份验证——无 Token、无Cookie、无签名。

3. 端口可预测：使用固定默认端口或小范围动态端口，攻击者可以轻松探测。

这三个缺陷的组合产生了一个极其危险的攻击面：任意恶意网页（包括用户在普通浏览器中点击的钓鱼链接或含恶意广告的正常网站）均可在用户毫无感知的情况下，通过 JavaScript 直接调用指纹浏览器的全部本地 API。

更为严重的是，部分产品的本地 API 充当了认证代理的角色——本地服务会自动附加用户的登录会话凭据，将请求转发至厂商云端后端。这意味着攻击者通过一个恶意网页，就可以以受害者的身份调用厂商的所有后端 API，实现完整的账户接管。

审计中发现的可被未授权调用的危险接口类型包括：

获取用户账号信息和配置数据；

读取系统任意文件；

启动、关闭、删除浏览器环境；

发起任意 HTTP 请求(SSRF)；

实时事件订阅与监听；

控制指令注入；

剪贴板内容读取。

风险本质：开发者普遍存在一个认知误区——“本地服务只能本机访问，所以不需要认证”。但现实是，浏览器的跨域请求机制允许任何网页向 127.0.0.1发起请求，而 CORS *则移除了最后的同源策略保护。本地不等于安全。

风险三：XSS 可升级为系统级 RCE

普遍性：所有被审计产品均存在可利用的 XSS → RCE 攻击链。

在传统 Web 应用中，跨站脚本攻击(XSS) 通常被评为中等风险——它可以窃取 Cookie、劫持会话，但无法直接控制用户的操作系统。然而在 Electron 环境中，由于前述的桌面框架安全配置缺失，XSS 的危害被急剧放大。

审计中发现的 XSS → RCE 攻击链遵循一个高度一致的模式：

① 注入点：用户可控字段被后端零过滤存储↓② 安全渲染假象：前端框架(Vue/React) 的默认渲染是安全的↓③ 不安全的二次处理：某些特定功能路径绕过了框架的安全渲染（搜索高亮、Tooltip 拼接、通知弹窗、富文本渲染等）↓④ XSS 触发：恶意脚本在 Electron 渲染进程中执行↓⑤ RCE 升级：通过 Node.js API 或暴露的 IPC 接口执行任意系统命令

一个极具代表性的发现是：即使产品使用了 React 或 Vue 等现代前端框架（这些框架默认会对用户数据进行 HTML 转义），开发者仍然在以下”看似无害”的功能中引入了不安全的 HTML 渲染：

• 搜索高亮功能：将安全的文本内容通过字符串替换转换为 HTML，再通过 innerHTML 插入 DOM

• 批量操作 Tooltip：将多个用户输入的名称通过<br>拼接后以 HTML 渲染

• 通知系统：将消息内容直接通过 innerHTML 渲染到通知窗口

• 调试/日志窗口：将程序输出直接以 HTML 渲染

关键教训：框架的默认安全不等于全局安全。只要有一处代码路径使用了 innerHTML 渲染用户数据，XSS 就存在。在 Electron 环境中，任何 XSS 都必须被视为“严重（Critical）”级别漏洞。此外， “搜索高亮”、“Tooltip”、“通知弹窗”是 XSS 的高发区域。

风险四：服务端请求伪造(SSRF) 成为标配漏洞

普遍性：大多数被审计产品存在此问题。

指纹浏览器天然需要处理大量网络请求——代理检测、IP 刷新、页面加载等。审计发现，多数产品在实现这些功能时，提供了允许控制请求目标 URL 的接口，且缺乏对目标地址的校验。

典型的 SSRF 攻击场景：

• 云元数据窃取：在云服务器环境中运行的指纹浏览器，攻击者可通过 SSRF 访问云平台元数据接口，获取临时凭证，进而接管整个云环境。

• 内网服务探测：以受害者机器为跳板，扫描和攻击企业内网中的数据库、管理系统等。

• 真实 IP 暴露：通过 SSRF 请求外部服务，暴露用户的真实出口 IP——这对于以”匿名”为卖点的指纹浏览器而言，是一种讽刺性的安全失败。

尤其值得注意的是，部分产品的 SSRF 端点同时禁用了 TLS 证书验证(rejectUnauthorized: false)，进一步扩大了攻击面。

风险五：后端输入过滤形同虚设

普遍性：所有被审计产品的后端 API 均未实施有效的输入过滤。

这是一个简单但影响深远的问题：所有被审计产品的后端 API 均不对用户输入进行 HTML/XSS 过滤，恶意数据被原样存储到数据库并返回给前端。

这意味着攻击者可以在以下任何用户可编辑字段中注入恶意代码：

• 浏览器环境名称

• 备注/描述字段

• 代理配置信息

• 自动化流程参数

• 团队成员信息

后端的零过滤是前端 Stored XSS 得以成立的根本原因。即使前端做了完美的安全渲染（实际上并没有），缺乏后端纵深防御也意味着只要前端出现一处疏忽，攻击链就完整了。

行业现状：在审计的所有产品中，没有发现任何一家部署了 Web 应用防火墙(WAF) 或实施了有效的输入验证。这表明该行业在安全开发生命周期(SDL) 方面尚处于起步阶段。

风险六：客户端密钥与凭据硬编码泄露

普遍性：多款产品存在不同程度的凭据泄露。

Electron 应用的本质是打包后的 JavaScript 代码——无论如何混淆，都可以通过提取和反编译获取源码。然而，审计中发现多款产品将敏感凭据直接硬编码在客户端代码中：

• 第三方 API 密钥：如 AI 服务 API Key，任何用户提取安装包即可获得，导致厂商的 API 配额被盗用。

• OAuth Client Secret：OAuth 协议的客户端密钥属于服务端机密，不应出现在客户端代码中。泄露后攻击者可伪造 OAuth 授权流程实施钓鱼攻击。

• 通信加密密钥：用于客户端-服务器通信加密的密钥硬编码在代码中，使得加密体系可被完全破解。

• 内部服务凭据：日志上报、性能监控等内部服务的认证凭据在客户端明文可见。

关键教训：代码混淆(Obfuscation) 不等于加密(Encryption)。任何放在客户端的秘密最终都会被提取。

风险七：加密体系设计缺陷

普遍性：采用了通信加密的产品普遍存在密码学设计缺陷。

部分产品实现了 API 通信加密以保护数据传输，这是一个积极的安全意识。然而审计发现，这些加密实现普遍存在密码学反模式：

• 弱哈希算法：使用 MD5 进行文件完整性校验或 API 签名，MD5 的