深度还原 7702 钓鱼攻击原理，钱包和用户该如何防范？

EIP-7702赋予了地址类似智能合约的能力和灵活性，越来越多的7702应用正在不断被创造出来，这对让更多的人进入Web3和提高用户体验至关重要。

然而，7702的灵活性以及大多数用户对7702还不熟悉的现状正在被欺诈团伙利用，近期我们观测到有用户就因为 Metamask 7702 批量执行的能力而导致原本需要授权十几次的交互，被钓鱼团伙 #InfernoDrainer 合并成一笔交易完成，导致资产被盗。

说明：Metamask 本身没有安全问题，Metamask在为用户提供7702相关能力时是把用户安全放在第一位的，并且做了很多安全措施。用户需要对7702的能力和相关风险了解更多，以防止此类安全事件再次发生。

• 由用户授权已部署的Delegator Contract，将用户账户的code字段指向该合约。当前MetaMask官方Delegator Contract地址：0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B

• 授权结构：(chainId, delegatorAddress, nonce, signature)写入authorization_list

• 签名方式：Metamask底层对EIP-7702相关的授权交易采用统一的签名逻辑，即signEIP7702Authorization方法，对授权数据digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce))进行 ECDSA 签名，生成(v, r, s)签名结构，并附加到随后的 Type-4 交易中，实现账户的授权与升级，具体实现见：https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts

• 验证方式：共识层通过ecrecover(digest7702, sig) == tx.from完成验证。

• 安全设计：网页端无法诱导用户对任意的Delegator进行授权，因为signEIP7702Authorization方法仅在 MetaMask 钱包内部实现，不通过 window.ethereum对网页端开放调用**。**网页可访问的签名方法如 eth_signTypedData_v4并不适用于 EIP-7702 授权签名，其签名摘要格式如下：

而 EIP-7702 规范要求的签名格式为：

由于 eth_signTypedData_v4固定包含 0x1901前缀，且摘要计算过程与 7702 完全不同，因此即使构造巧妙的 domainSeparator、primaryType和 message，也几乎不可能使得 digest712 == digest7702。

因此，网页端无法通过该方法伪造合法的 7702 授权签名。此外，MetaMask 还对 Delegator 地址实行白名单机制，默认且仅允许授权官方 Delegator（0x63c0...32B），禁止 DApp 自行注入地址，进一步防止用户被诱导签名恶意 Delegator 授权数据。