浏览器扩展钱包：全站读权限、静默更新与供应链风险

你装的每个钱包扩展，安装时都要一个权限：读取并更改你在所有网站上的数据。这不是暗黑设计，而是机制本身——扩展必须把 provider 对象注入每一个页面，站点上的兑换按钮才找得到它。副作用是，同一份软件同时拿到了两个关键能力：能读你粘进表单的地址，也能在站点请求时签名。2026-10-28，我们从 Google 自己的更新端点拉下六个主流钱包扩展的当前构建，解开包、读了它们的 manifest。这篇文章写的是这些文件究竟声明了什么、为什么更新通道比权限弹窗更该被怀疑，以及像我们这样的兑换站对此能做和不能做什么。

扩展钱包到底是什么

六个包全是 Manifest V3，这一点值得单说，因为 V3 改变了问题的形状。V3 钱包是一个没有常驻页面的 service worker，加上一个或多个在 document_start 阶段注入的内容脚本（比站点自己的 JS 更早），以及决定这些脚本能碰哪些源的 host 权限。内容脚本跑在隔离世界里，读不到页面变量，但能读和改写 DOM——足够改掉一个地址输入框。签名是另一件事：钱包自己弹窗，用户点确认。最容易被人忽略的是「读」这个能力，因为它是安装时一次性授予的，而那个弹窗大多数人一秒就点掉了。以 MetaMask 当前的 manifest 为例，它要 11 个权限，包括 cookies、webRequest、identity、offscreen，另外 clipboardRead 是可选项。

实测权限表：2026-10-28 06:02 UTC

我们读的六个包是 MetaMask 13.54.0.0、Phantom 26.35.0、Rabby 0.94.13、Keplr 0.13.53、Trust Wallet 26.42.4、OKX Wallet 4.21.0。六个全部声明了对所有 http 与 https 源的访问权。MetaMask 额外加了 ws、wss、file 和 localhost:8545，并且是唯一允许任意网站给它发消息的（externally_connectable 里扩展 id 写了通配）。Rabby 用的是最粗的 all_urls；Keplr 在 all_urls 上以 document_start 注入内容脚本；Trust Wallet 声明 clipboardWrite 和 gcm；OKX 除了所有站点，还把内容脚本钉在 solscan.io、twitter.com 和 x.com 上。包体积 16.4 MB 到 54.7 MB，文件数 103 到 1,187，解开后的 JS 15.5 MB 到 92.5 MB。最后这个数字才是攻击面的诚实度量：几十兆第三方代码，常驻权限覆盖你打开的每一个页面，而且由别人替你更新。

静默更新，以及 crx_id 保护了什么、没保护什么

CRX3 包是一小段 protobuf 头加一个 zip。六个包的头结构一样：两个 RSA 签名证明、一个 ECDSA 证明，以及一个带 16 字节 crx_id 的 signed_header_data。把这个 id 的每个十六进制数字映射成 a 到 p 的字母，就得到商店里那个 32 字符扩展 ID——我们逐一验过，六个全部对得上。所以密钥和 ID 是绑死的，别人没法替这个 ID 出包。但发布者可以出任何包，Chrome 也不问任何人就装上：检查在后台对着我们刚用的同一个公开端点跑，浏览器版本作为参数传过去，新代码在你下次加载页面时就生效，没有必须阅读的更新日志，也没有确认按钮。这也是为什么真正出事的都在下一层——依赖。@solana/web3.js 1.95.6 发布于 2024-12-03 15:10:07 UTC，1.95.7 是 15:20:23，两个版本现在都已从 registry 的版本列表里消失，干净的 1.95.8 到 20:25:40 才出现——差 5 小时 15 分。@ledgerhq/connect-kit 在 2023-12-14 依次是 08:49:04 的 1.1.5、09:44:57 的 1.1.6、10:37:24 的 1.1.7，干净版 1.1.8 到 13:18:35——四个半小时。两次的时间窗都不是几天，而是自动化安装把版本捡起来所需的时长。

兑换到底需要什么，扩展又还能做什么

这里就和我们自己的产品形状有关了。VeilSwap 下单只要五个字段——兑出资产、兑入资产、金额、收款地址、退款地址，别的都不要：没有账户、没有邮箱、不连钱包、不要签名。在前端代码里 grep window.ethereum、WalletConnect、wagmi 都是零结果，因为流程里没有任何一步要求钱包做事。这去掉了最大的一类风险——那些没人细看就点掉的授权弹窗。但「读」的权限没被去掉：钱包扩展照样在 veilswap.io 上以 document_start 跑起来，看得见地址输入框。地址格式和校验和是建单时在服务端查的，能挡住打错一个字符，挡不住格式合法的替换。06:04 UTC 的实测报价给个量级：100 USDT-TRC20 换 0.14408925 XMR，5,000 换 8.06917242 XMR——每 XMR 694.01 对 619.64 USDT，12% 的差距来自每单固定成本，不是钱包能影响的数。1 XMR 卖 589.282718 USDT；0.05 BTC 换 6.54643747 XMR（130.92875 XMR/BTC，约 77,154 美元/BTC）。目录当前 520 个资产、73 条网络。 (转错网络如何找回)

六个动作，三种常见误判

一，给钱包留一个专用浏览器配置，兑换在另一个完全没装钱包扩展的配置里做——地址靠复制粘贴在两边传递，这就够了。二，在扩展管理页把每个钱包的「网站访问权限」改成点击时或一个短白名单（如果你只用它连一条链），每次更新后再看一遍。三，动真钱之前，把已装版本和商店里列出的版本对一遍——上面这些版本是 06:02 UTC 时线上的，不是你手上那个。四，任何索要助记词的行为都当攻击处理，不管弹窗写着什么；网站流程不需要它。五，金额值得的时候用硬件签名，并且读设备屏幕上的地址，不是浏览器里的。六，如果某次更新把权限列表变长了，删掉重装，别点确认了事。三种误判：商店审核挡不住恶意更新（更新审核比首次上架轻得多，上面六个包的 JS 文件分别是 233、230、64、31、234、392 个）；无痕模式不是沙箱（扩展只有你明确允许才在里面跑，一旦允许，那些页面它照样读）；少装几个钱包也不会线性降低风险，因为每个钱包各自独立持有全站权限。

一句话版本：浏览器钱包不是硬件钱包那种意义上的钱包，它是一个能读页面、顺便拿着钥匙的程序，而且会被掌握发布者密钥的人静默替换。兑换不需要它——一单只需要地址和金额；一个要你连接并签名的站点，要的东西比这笔交易多。把钱包关在一个配置里，把兑换放在另一个配置里，在复制的源头逐字符核对地址。这比信任 92 MB 你从没读过的代码，要求低得多。