在上一篇说明了代币本身的安全问题后（纯干货分享（一）|DEFI安全问题之基础篇），现在来聊聊DEX在兑换代币时可能产生的安全问题。目前DEX主要面临的安全问题大致可分成两类：
（1）DEX项目本身存在的安全问题。
（2）与其他DEFI项目交互时产生的安全问题。
本文将对第一类安全问题进行介绍。
Part.1 - DecentralizedExchange
重入漏洞
重入漏洞在上一篇我们也提到过，它属于需要防范的经典漏洞。与普通代币的重入相比，Uniswap的重入漏洞的主要表现形式为：攻击者在一笔兑换交易中利用Uniswap未及时更新价格前发起二次兑换，由于此时Uniswap未更新价格，使得二次兑换可兑出的代币数量比正常兑换的多。此外，在Uniswap的重入攻击中，攻击者利用单笔交易可能只能获得微小的收益，因此攻击者往往倾向于使用闪电贷或者循环套利扩大战果。
以imBTC攻击事件为例，该事件是由于UniswapV1在调用ERC777系列代币时，未充分考虑合约回调的情况。
具体表现为：攻击者使用imBTC代币兑换ETH时（如图1），合约先通过self.getInputPrice函数计算正确的ETH数额并将ETH发送到目标地址，然后调用self.token.transferFrom函数时，会调用imBTC合约的_callTokensToSend函数（如图2），而_callTokensToSend函数会调用用户指定存储imBTC代币的合约。因此，如果攻击者部署存储合约，并改写其中TokensToSend函数，那么当兑换代币时，pair(两种代币组成的交易对)合约调用攻击者部署的存储合约，就可以回调pair进行二次兑换，而二次兑换时pair合约账本还未更新，使得计算的ETH数额比正常兑换要多，以此来获利。
图1Uniswap的tokenToEthInput函数
图2imBTC的transferFrom函数
图3imBTC的__callTokensToSend函数
详细攻击流程如下：
图4ETH-imBTC事件流程图
那么，为什么在第二次调用tokenToEthSwapInput函数兑换代币时，发送的ETH会比正常兑换要多呢?我们可以用公式来还原可兑换代币数量的代码逻辑：
首先，正常兑换下，getInputPrice函数计算可兑换的ETH数量为:
且正
本文来自用户投稿，不代表币大大立场，如若转载，请注明出处：https://czxurui.com/zx/3915.html
发表回复
评论列表（0条）