官网没被改，脚本先变坏：前端依赖投毒与签名请求防线

钓鱼有两种：假的冒充真的，以及真的内部烂掉。前端供应链投毒属于后者——域名字符一个没动，DNS 解析正常，证书有效，页面截图与昨天完全一样，但页面加载的某个第三方组件今天多了一段代码。它不需要骗你点任何东西，它等你连接钱包，然后替你决定该签什么。

攻击面在哪里

现代 dApp 前端大多是静态页面加构建产物，构建时打包大量第三方依赖，运行时还可能引入统计、广告、客服小部件、CDN 托管的公共库。链条上任何一环失守都足以给页面注入代码：依赖包被攻击者通过钓鱼接管维护者账号后发布带毒版本；CDN 账号被盗导致公共库文件被替换；构建流水线被污染。这类事件在 Web 世界反复发生过，与项目本身的专业程度关系不大——它考验的是上游生态的安全水位。

用户能感知到什么

信号是存在但稀疏的：连接钱包时弹窗内容异常，出现从未见过的授权类型或巨额无限批准；页面加载明显变慢或变重；浏览器开发者工具的 Network 面板里出现陌生域名的脚本请求——这条对会按 F12 的人最有效；更常见的”信号”其实来自社群：同一时间段多人报告同款异常，往往比任何个人检查都早。

真正的防线：假设前端迟早出事

既然你无法审计一个页面的全部依赖，防线就得建在授权结构上。第一层，专用钱包：交互新协议、低信任前端用小额热钱包，主资产钱包从不在浏览器里连接任何东西。第二层，最小授权：能授权具体额度的不用无限批准，能只连接不调交易的先只连接，用不到的授权当次撤销。第三层，把签名当转账看：钱包弹出签名请求时确认发起域名、合约地址与动作内容，尤其警惕无需 Gas 的消息签名类授权——它们同样可能直接导致资产转移。第四层，硬件钱包作为最终防线：它的价值恰恰在于屏幕独立显示真实合约与金额，前端注毒骗不过设备的第二双眼睛。第五层，定期撤销：用批量撤销工具按季度清理不活跃授权，工具本身要先核验域名真伪。

与相邻攻击面的区分

前端投毒常被混称为”钓鱼”，但防御逻辑完全不同：钓鱼拼的是域名核验，投毒拼的是授权结构。同类还有第三类——官方前端没错、后端接口被攻破，返回恶意的合约地址或参数，此时连”域名对、页面对”都保证不了内容可信，能兜底的只有独立设备上的签名审查与小额试探。三类风险共用一条总原则：把信任锚点从”页面显示什么”移到”设备与链上实际发生什么”，任何只能在浏览器里完成的”核验”都值得多问一句。

一份日常操作顺序模板

把防线落成习惯才算数：连接任何 dApp 前先问三句——域名从哪条可信路径到达、这个操作要不要动用主钱包、这次授权上限设多少合适；操作过程中，凡是弹窗内容和页面文案对不上的，一律取消并重开；操作结束后，对不常用的授权随手撤销或在台账记一笔到期清理。这套动作在浏览器端每次多花两分钟，成本远低于任何一次误签。把”先小额试一笔”设为默认而非例外，尤其适用于新桥、新协议和新合约——机制准确的答案永远比页面漂亮的话术可靠。

怀疑中招时的动作

立即断开当前网页会话；在干净环境检查并撤销可疑授权；资产迁移到新地址；清理浏览器扩展与站点数据；对照最近签名记录排查有无已生效的被动授权。事后动作只能止损，结构化的分层授权才是让你”中招也只伤一层”的那堵墙。

本文为通用安全知识介绍，不构成投资建议。