TMT观察网_独特视角观察TMT行业

最近，我們在審計客戶合約時發現：EOS代幣合約存在整型溢出等問題，部分合約實現不夠嚴謹。

具體包括：

整型溢出錯誤；

權限檢查不嚴謹；

API函數的不規范使用；

常規代碼錯誤。

為了使開發者在合約開發中不掉進坑里，我們接下來就一一對上述問題進行分析。并且給出合理的解決辦法，讓開發者不至被黑客利用。

讓我們直奔主題。

問題出在EOS的代幣合約

這次漏洞的主要原因，在于EOS的代幣合約有不嚴謹之處，主要體現在以下4個方面：

1.  整型溢出錯誤

使用自己的數據結構描述代幣，對代幣數值進行算數運算時未進行安全檢查。在誤操作時容易產生整型溢出錯誤，可能導致代幣量歸零甚至變成負數的嚴重后果！

2. 權限檢查不嚴謹

權限檢查不嚴謹，造成邏輯漏洞。部分代幣合約設置了「凍結賬戶和代幣」的功能，然而用戶們卻將檢查 「凍結」 的代碼放在transfer（轉賬）函數中，從而導致執行issue（發行代幣）的時候不受「凍結」狀態影響，可以任意增發代幣。參考以下代碼。

3. API函數的不規范使用

這里指的是開發者要注意EOS API函數的參數類型。

例如：string_to_symbol（uint8_t , const char *），

第一個參數傳入的整型變量需要小于256，若使用該API前未對輸入進行檢查，則可能導致整型溢出，從而導致操作了錯誤類型的代幣，帶來嚴重后果。

4. 常見代碼錯誤

數據庫API使用不嚴謹，如multi_index中提供的get和find。其中get會檢查數據是否查詢成功，數據未找到則斷言退出，而find不會檢查數據查詢情況，需要用戶自行判斷，如果缺少判斷直接使用將會導致指針使用問題。

不要慌！關鍵時刻拿走這三根救命稻草

既然EOS代幣合約存在不嚴謹之處，那么作為項目方應該如何去防范后期可能造成的風險呢？我們給出下面三種建議方法。

第一，合約中使用官方提供的asset數據結構描述代幣，對代幣的算數運算同樣利用asset完成。參考以下代碼：

第二，在使用multi_index的find函數時，一定要進行返回值的檢查。

第三，對所有輸入都通過斷言檢查有效性，調用API函數前，檢查參數類型和大小。

最后，建議代幣合約參照EOS官方給出的eosio.token示例進行實現，避免疏忽而導致的安全檢查不完備。

此漏洞應引起開發者重視

雖然目前EOS代幣合約還沒有上線，但是項目方一定不能掉以輕心，反而應該時刻記住BEC這類事件的慘痛教訓，避免重蹈覆轍，以及整型溢出問題引發的代幣被盜事件的發生。

總體而言，我認為從目前審計EOS代幣合約所遇到的問題來看，開發者在合約敏感代碼（如操作代幣數額）前后，一定要做好參數限制和權限檢查，使用EOS API時一定要搞清楚該函數的輸入限制和返回值形式，同時多多參考官方的示例實現。

另一方面，智能合約安全是整個區塊鏈行業的基礎設施最底層的保障，項目方合約開發完成后進行安全審計也是很有必要的，從多角度分析合約代碼，找出那些容易忽略的問題，并且做到防患于未然。