将您的钱包连接到新的、未经验证的 dApp 有哪些风险？

钱包连接到未经验证的 dApp 的风险

1. 当用户将钱包连接到未经验证的去中心化应用程序时，他们通常会在不完全了解范围的情况下授予广泛的权限。许多 dApp 要求无限的代币批准，使合约能够在未经进一步同意的情况下重复提取资产。

2. 恶意合约可能嵌入在连接时触发自动转账的逻辑，特别是当钱包持有带有转账挂钩或重入漏洞的代币时。这导致了许多事件，用户在批准交易后几秒钟内就失去了全部余额。

3. 虚假接口模仿合法协议，诱骗用户签署伪装成标准连接请求的网络钓鱼负载。这些有效负载可能包含恶意签名请求，这些签名请求以“钱包连接”或“登录”为幌子，授权任意合约​​调用。

4. 一些 dApp 部署在具有最少节点基础设施的不起眼的 EVM 兼容链上，增加了抢先交易、三明治攻击甚至链重组的可能性，从而使预期的状态转换失效，从而使用户面临无声的资金损失。

5. MetaMask 等钱包扩展在提示签名请求之前不会验证合约字节码完整性。 dApp 前端中的单个受损依赖项（例如被劫持的 CDN 托管库）可以将恶意签名逻辑直接注入用户的浏览器上下文中。

令牌批准利用模式

1. 旧版 ERC-20 批准在协议升级和链迁移过程中仍然有效。攻击者通过在新部署的共享相同功能选择器的恶意合约上重复使用旧的批准来利用这一点。

2. 授予代理合约的批准特别危险，因为底层实现可以在不通知用户的情况下升级。控制管理密钥的攻击者可以随时交换逻辑以耗尽批准的代币。

3. 一些 dApp 使用基于许可的链下批准，要求用户签署 EIP-712 消息。如果域分隔符配置错误或消息结构不明确，签名可以在网络上重放或重新用于未经授权的传输。

4. 钱包很少在批准提示期间显示完整的 ABI 编码的通话数据。用户无法验证批准的目标是真实的令牌地址还是攻击者使用类似的校验和大小写或 Unicode 同形异义词技巧部署的相似地址。

前端供应链漏洞

1. 当开发人员错误地在全局范围内公开敏感引用时，已观察到通过 npm 依赖项注入的第三方分析脚本会从内存钱包对象中窃取私钥。

2. dApp 构建者使用的受损 UI 框架有时会包含隐藏的事件侦听器，这些事件侦听器会捕获助记词输入字段中的击键，即使这些字段已通过 CSS 禁用或隐藏。

3. 浏览器扩展冲突会产生竞争条件，钱包提供商无法正确拦截签名请求，从而导致使用不正确的参数或随机数签名的原始交易广播。

4. 未缩小的 JavaScript 捆绑包通常包含硬编码的 API 密钥、钱包地址或测试网凭证，攻击者会抓取并重新利用这些凭证来模拟受信任的后端服务，同时通过恶意中继器路由流量。

网络级欺骗策略

1. 恶意 RPC 端点提供伪造的区块链状态，显示虚假的代币余额或捏造的交易确认，以在启动不可逆转的操作之前诱导虚假的信心。

2. DNS 中毒攻击将尝试访问官方 dApp 域的用户重定向到托管相同 UI 但指向攻击者控制的智能合约的镜像站点。

3. 中间人代理拦截钱包和 dApp 之间的 WebSocket 连接，改变响应负载以隐藏待批准的内容或抑制由已知诈骗合约地址触发的警告横幅。

4. 与 dApp 入门流程捆绑在一起的测试网水龙头有时会与合法合约一起部署恶意合约，鼓励用户与两者进行交互——在主网上引入利用逻辑之前建立信任。

常见问题解答

问：dApp 可以仅通过连接我的钱包而不签署任何交易来窃取资金吗？答：是的。仅连接不会转移资金，但许多 dApp 会立即请求代币批准或调用使用用户钱包上下文执行任意代码的委托调用模式。

问：使用硬件钱包可以消除这些风险吗？答：不会。硬件钱包可以保护私钥，但仍然签署前端请求的交易。如果 dApp 显示误导性信息或构造欺骗性通话数据，硬件设备将按照指示对其进行签名。

问：连接开源 dApp 是否自动安全？答：不一定。公共源代码不保证部署完整性。攻击者经常部署经过审核的合约的修改版本，其中包含细微的更改（例如更改的所有者地址或后门回退功能），从而绕过静态分析工具。

问：为什么有些钱包扩展程序显示警告，而其他钱包扩展程序则不显示？答：警告行为取决于扩展提供商维护的实时合约地址信誉数据库。这些数据库落后于新的部署，并且通常缺乏对鲜为人知的链或新签订的合约的覆盖。