Cobo 安全团队：牛市 DeFi 交互指南

作者 | Cobo 安全团队

自 2019 年 DeFi Summer 开启后，以以太坊为首，出现了越来越多富有创意的去中心化金融协议（DeFi 协议），大大丰富了链上资产的可用性，使区块链用户可以更好地利用链上资产进行更多样的金融活动并为此创造丰厚的收益。但随着越来越多 DeFi 协议的兴起，安全挑战也随之而来。据不完全统计，仅 2023 年一年，因区块链攻击而导致的资产损失已达到 26.1 亿美元。可见，在参与 DeFi 协议的过程中，除了评估对应的收益预期以外，协议安全性方面的评估也不可忽视，否则会给用户带来大的损失。
 
一般而言，目前对协议安全评估的主流定义为代码的安全性评估，这种定义的维度是比较单一的，这里的问题在于，评估的本身只是考虑了协议在静态过程下的安全性，而在 DeFi 交互过程中，安全性往往是动态的，包含账户管理、协议交互前的准备、交互完成后的资产管理、数据监控及极端情况下资产损失后的自救等多个阶段。
 
作为一个即将要进入 DeFi 新手村的用户，该如何在赚取收益的同时最大限度地保障资金的安全？Cobo 安全团队梳理了 DeFi 交互中常见的安全风险及对应的安全防范措施，希望可以对大家在牛市中的 DeFi 安全交互有所启发和帮助。

DeFi 交互中的常见安全风险和防范措施

一、账户私钥泄露
 
账户私钥泄露是目前新手用户较为容易中招的问题之一，由于当前市面上钱包种类繁多，新手用户缺乏自行判别钱包安全性的能力，很多新手用户会下载一些不安全的钱包，并使用其来生成私钥，从而导致私钥被恶意回传到攻击者手中，造成私钥泄露。很多资深用户发现自己的主账号在某一天被转走所有资产，分析大半天发现所有行为都正常，这种案例下大部分情况就是早期该账户使用了不安全的钱包来生成自己的私钥导致私钥早已泄露。
 
同时，由于区块链空投导致的财富效应，很多新手用户会盲目点击一些所谓的空投网站，这些空投网站将自己包装成非常正经的项目网页，并告诉用户存在大量未领取代币。在利益的驱使下，很多新手用户会在网页的诱导下，填入自己的账户私钥，导致私钥泄露。
 
为了防止私钥泄露，用户需要做到以下几点来加以防范：
 
·使用知名度较高的区块链钱包，并从对应的官网进行钱包的下载。有条件的用户建议使用硬件钱包。
 
·永远不要将自己的私钥明文暴露在联网环境中，也不要随意将自己的私钥输入到任何网页当中。

二、签名钓鱼风险
 
签名钓鱼风险和私钥泄露一样，同样也是新手用户的重灾区。区别于直接让用户填入私钥，此类钓鱼攻击则是诱导用户发起一笔交易或签名，从而获取用户相关资产的授权，具有隐蔽性高、不易分析以及难以察觉等特点。
 
通常，攻击者会先把用户诱导到钓鱼网页中，以领取空投、验证登录等名义让用户发起签名，此时，用户的浏览器钱包提示用户需要完成签名。
 
钓鱼交易的类型可能有多种：

·直接转账类型。直接转账 ETH 或进行 ERC20 transfer 调用将钱包资产转移到攻击者地址。
 
·Approve 类型。调用 ERC20 Approve 方法授权攻击者钱包。用户签名时不会发生资产转移。但攻击者钱包可通过调用 transferFrom 转移用户资产。
 
·EIP712 消息签名。如 ERC20 Permit 方法；Permit2 授权；NFT 挂单签名等。此类签名通常在钱包中展示为 Json 数据或者格式化较好的树状数据。用户签名时不会发起交易，不会有 gas 消耗。但签名结果会被钓鱼网站记录，攻击者可以使用该签名结果转移受害者的 ERC20 或 NFT 资产。
 
·原始 hash 签名。签名数据为 16 进制 hash 数据，从签名数据本身无法推断具体的签名内容。hash 背后可能是上述 1-3 种类型数据。签名很可能导致资产损失。不过目前主流钱包通常会禁止此种签名方式或者予以明显的风险提示。

最近一些案例中还发现某些钓鱼网站会要求用户连续进行多笔签名，且前几笔均为无害的正常签名。然后混杂一笔恶意签名内容。利用用户的操作惯性诱导用户完成签名操作。
 
为了防止钓鱼导致的资金损失，核心在于拒绝盲签。对于每笔签名认真审核，对于不确定内容的交易拒绝签名。具体来说，可以在签名过程中注意以下内容：

·确认交互网站为 DeFi 项目官网，检查完整域名。
 
·检查合约调用的方法，对于 transfer, approve 方法重点检查。
 
·检查交易附带的 ETH 转账。某些钓鱼网站会尝试构造看起来安全的方法（如 Claim），但实际会在调用时附带 ETH 转账造成 ETH 等链原生代币的损失。
 
·不签名原始 hash 内容。

三、转账地址投毒
 
转账地址投毒为近来较为新颖的攻击方式，其攻击手法为在用户发起一笔转账（ERC20， native token 等）时，使用与该交易中的接收地址相似的地址，向用户发送一笔金额相同的交易，或金额相同但对应代币为 fake token 的交易。
 
举例：

Alice 每月会固定转移了 1 ETH 给 Bob 作为薪资发放。Charlie 监控到了这笔交易，用与 Bob 相似的地址（地址前 8 位和后 8 位相同）发送 0.001 ETH 给 Alice。这种操作后，在下次 Alice 再向 Bob 转账的时候，就有可能使用 Charlie 的地址来作为交易的接收地址。会发生这样的情况的原因在于区块链地址长度较长且无规律，用户难以记忆，导致很多时候用户会贪图方便直接从上一次的交易记录中复制地址。由于 Charlie 和 Bob 的地址极为相似，导致 Alice 难以分辨，最终导致资产损失。
 
为了防止中招转账地址投毒，用户可以采取以下手段进行防范：
 
·每次交易均核对转账地址，且要核对完整内容而不是仅比较前后几字节。
 
·将常用的的地址设置进地址白名单（地址簿）中设置别名，尽量只使用地址簿中的地址进行转账。
 
·避免将从链上渠道（包括区块链浏览器、钱包交易记录等）中复制地址作为转账目标。

四、代币过度授权
 
代币授权几乎是进行 DeFi 交互的第一步。在进行 DeFi 操作时，由于交易数据是通过项目方网页构造而不是用户构造，在通常情况下，为了方便用户多次交互而不需要重复授权，项目方网页通常会构造一个无限授权的交易让用户签名。其出发点是为用户节省 gas，但是这也为后续资金安全埋下了隐患。假设后续项目代码发生问题，如未授权接口，或任意调用漏洞，用户对合约的无限授权将导致被攻击者利用，导致用户资产被转移。这种攻击场景在跨链桥和 DEX 协议中较为常见。
 
为了防止后续项目在升级中引入风险代码或项目代码本身存在未发现的漏洞，用户应采用最小授权的原则，尽量仅授权本次交易中使用到的额度，防止后续项目风险导致自己的资产损失。
 
五、不安全的 DeFi 操作
 
除了交互前的准备外，在交互过程中同样存在很多容易忽视的风险。这些风险通常源于用户对项目本身的不了解导致。具体的例子为：

·在通过链上兑换协议进行代币兑换时滑点设置过大或者编写脚本进行 swap 没有设置最低接收数量（出于编写方便设置为 0），导致交易受到 MEV 机器人的“三明治”攻击。
 
·在通过链上借贷协议进行借贷操作时，没有对仓位健康度进行及时管理，导致大波动行情中仓位被清算。
 
·在与某些项目交互时，没有对项目方凭证进行良好的保管，如把 Uniswap V3 的 NFT 凭证当成是普通 NFT 到 OpenSea 中进行售卖。

为了防范这些风险，用户在进行项目交互时，一定要做好对应的项目调研，明确项目机制和相关特性，防止资产损失。



阅读原文