ERC20智能合約的approve千萬別這樣寫

微信號

功能介紹

最近智能合約安全事件頻發，從BEC到SMT，從HXG到FXE等，最近這幾個智能合約出的問題，大都是由于整數溢出漏洞導致的。大家對整數溢出是不是都杯弓蛇影了？我們是不是應該在所有的地方都加上安全檢查，確保我們的代碼沒有問題呢？可是這樣真的好嗎？

我們先來看看這段代碼：

這是ERC20接口中的approve函數的一個實現。乍一看，這個代碼是不是很完美。仔細看，我們注意到，在函數最開始的地方有這樣一行：

approve的時候對當前余額進行檢測，要求授權的_amount小于或等于當前余額。這樣寫貌似還很有道理，但真的是這樣嗎？

首先我們看這樣寫有沒有必要。

實際存在以下一些可能性，使得approve過的allowance大于用戶對應余額的情況。

1. 在approve之后，token的所有者自己通過transfer函數，把token轉走，導致余額小于allowance。

2. approve給多個人，其中一個人進行transferFrom操作后，可能導致余額小于之前給其他人approve過的值。

既然無法在后續操作里保證，授權的allowance大于余額，我們就可以得出結論，在approve里加上這樣的驗證是沒有意義的。有人可能會說，那加上這個除了多耗一點gas，那也沒什么問題啊。真的沒有什么問題嗎？

最近我們在和去中心化交易所DDEX合作審計該平臺上的ERC20 token的智能合約，發現一個比較嚴重的問題。目前的去中心化交易所，很多都用到了0x protocol或者類似的協議。在0x的智能合約里，進行轉賬的時候，通過Exchange合約的fillOrder函數完成轉賬。

其中fillOrder函數中由以下代碼來實現轉賬：

去中心化的交易所需要準備一個中間賬戶，也就是上面代碼中的msg.sender，來發起交易。具體轉賬過程如下：

1. 由該中間賬戶給賣出賬戶轉入WETH

2. 中間賬戶向買入賬戶轉入Token

而這四步轉賬都是通過一個叫TokenTransferProxy的合約完成，中間賬戶需要向該合約approve足夠的allowance。而0x提供的合約并不提供approve過程，需要交易所提供的中間賬戶提前準備好這個approve工作。

然而如果這個中間賬戶并沒有提前擁有交易的token,由于這個檢測

無法提前完成approve，這樣的問題給去中心化交易所帶來了較大的困擾。

在各種去中心化交易所中，甚至中心化的交易所中類似的情況并不少見。因此我們強烈推薦大家在寫ERC20智能合約時不要這么寫，不要加上這樣一個判斷。

如果萬一已經發布的ERC20 token合約已經這么寫了，我們有什么辦法嗎？

當交易所遇到這種情況的時候，只能由項目方向交易所的中間賬戶打一筆足夠大的token，才能保證能夠approve成功，而且限制以后發生的交易額不能超過此數量的限制。

我們使用SECBIT的一個內部工具，對提供源碼的22681個ERC20 Token智能合約進行了一次掃描，發現了21個智能合約存在此問題，其中有3個合約的交易量較大。涉及的Token包括：

• IDH

• GZR

• ADE

• SAINT

• BULB

• ZZZ

• KTM

• ETI-P

• ZORRO01

• ZORRO02

現在去中心化交易所將越來越多，為了不影響項目token未來的交易的流動性，我們建議各token仔細檢查合約是否存在該問題，如果可能，盡早進行修正。

以上數據均有SECBIT實驗室提供。