如今，随着人们对DeFi的兴趣日益浓厚，DEX（即去中心化交易所）风靡一时。它们解决了常见的CEX（即中心化交易所）问题，那我们也会问，DEX够安全吗？

在上一篇说明了代币本身的安全问题后（纯干货分享（一）|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数量为:

且正