應用於數字藏品的智能合約都有哪些安全風險？如何有效防範？

在我們推送數字藏品專題系列文章期間，國內數字藏品平台就又爆發了一起安全事件（國內又一數字藏品平台遭惡意攻擊,數字藏品安全該如何保障？）。不斷爆發的數字藏品安全事件，時刻提醒着我們：數字藏品安全問題不容忽視！

國內數字藏品在技術上與NFT並無太大差別，也是通過智能合約來實現業務邏輯，所以合約漏洞等安全問題在國內數字藏品上也會存在，我們需謹慎對待。下面我們就來看看數字藏品在智能合約實現中存在的安全問題和解決方案。

數字藏品與智能合約

什麼是智能合約？

為什麼數字藏品的安全問題離不開對智能合約的討論呢？因為，數字藏品在技術上是通過智能合約實現並運行的。在討論數字藏品智能合約安全問題之前，我們先來看看什麼是智能合約。

20世紀90年代，Nick Szabo首次提出智能合約的概念。當時，他把智能合約定義為通過結合協議與用戶界面，規範和保障計算機網絡安全的工具。

在區塊鏈領域，智能合約可界定為運行在區塊鏈中的應用或程序。簡單來說，智能合約是一種確定性程序，會在滿足某些條件時，強制執行特定規則來發揮作用。這些規則由計算機代碼預定義，經所有網絡節點複製和執行。

目前應用最廣泛的基於以太坊的智能合約有着分佈式、確定性、自主性、不變形、定製化、去信任化、透明性等特性。

為什麼數字藏品會有智能合約安全風險？

因為，智能合約本身由人工編寫的計算機代碼組成，那麼就不可避免的存在缺陷和漏洞風險。合約一旦部署不可修改、合約執行后不可逆、所有執行事務可追蹤，而且區塊鏈上的智能合約對所有用戶可見，如果有漏洞被作惡者利用，將導致資產被盜且往往無法收回，給用戶造成巨大損失。並且存在的安全問題可能無法迅速修復。

隨着數字藏品等應用的爆火，區塊鏈智能合約數量也與日俱增，隨之暴露出來的安全問題也會越來越多。

為了避免安全事件的發生，保護用戶的資產安全，就必須在最源頭做好安全防範，提高數字藏品開發的安全意識。

接下來，就給大家介紹一些由智能合約特性導致的安全風險和對應的安全措施。

數字藏品智能合約主要安全問題有哪些？

經成都鏈安安全團隊研究發現，數字藏品智能合約主要的安全問題有：重入漏洞安全問題、隨機數安全問題、整型溢出安全問題、動態數組越界安全問題、函數權限配置錯誤安全問題、忽略返回值安全問題、空指針引用安全問題、訪問外部資源安全問題、輸入參數檢查安全問題等，問題詳細分析如下。

1、重入漏洞安全問題

數字藏品的業務場景中智能合約常常需要實現合約間的外部調用，這種方式主要的危險就是外部合約可以接管控制流，並調用函數對某些關鍵數據進行更改。尤其在solidity語言中，當用戶直接向一個合約轉賬時會產生一個隱藏的fallback()外部調用，如果未對該調用進行限制則可能會產生重入漏洞。

重入攻擊首次出現於以太坊，對應的真實攻擊為 The DAO 攻擊，該攻擊還導致了原來的以太坊分叉成以太經典(ETC)和現在的以太坊(ETH)。

成都鏈安安全團隊對此建議：

1、更改狀態變量時採用官方推薦的檢查-生效-交互模式；

2、使用互斥鎖：添加一個在代碼執行過程中鎖定合約的狀態變量，防止重入調用；

3、對可能產生的外部調用操作本身進行限制；

2、隨機數安全問題

隨機數在數字藏品中的應用十分廣泛，如為藝術類數字藏品隨機分配屬性，為遊戲類的藏品分配寶藏位置，以及保障限量版藏品空投的公平性等。

不同區塊鏈開發語言中生成隨機數的方式也多種多樣，例如Go使用math/rand、Java使用java.util.Random類等。而在Solidity中由於沒有原生的生成偽隨機數的函數，所以部分開發者常採用區塊參數替代。

但上述隨機數的生成方式都存在安全缺陷，當開發者使用可被預測的隨機數種子生成隨機數時，攻擊者就可以根據對應的算法獲取到即將出現的隨機數，實現隨機數預測，達到攻擊目的。

成都鏈安安全團隊對此建議：

隨機數的來源盡量來自於區塊鏈之外，這可以在具有諸如commit-reveal之類的系統的對等體之間完成，或者通過將信任模型改變為一組參與者來完成。

3、整型溢出安全問題

數據的存儲是區塊鏈上重要的一環，而執行合約的虛擬機（EVM）為各類整數都指定了固定大小的存儲寬度。這意味着一個整型變量只能由一定範圍的數字錶示。

所以在代碼實現時，如果沒有檢查用戶輸入就執行算術運算，可能會導致數值超出存儲它們的數據類型允許的範圍，產生數值溢出的問題。

具體的溢出類型包括乘法溢出、加法溢出、減法溢出、指數溢出等。例如，Solidity中 uint8 只能存儲大小在[0,255] 的數值。當試圖存儲 256 到一個 uint8 時將溢出變成0。而Go語言中使用make()進行內存分配時，如果發生溢出使得該值為0或最大值時，將導致內存分配失敗。攻擊者常利用該漏洞達到繞過轉賬條件、操縱內存、破壞堆棧的目的。

成都鏈安安全團隊對此建議：

在進行整數算術運算之前先進行校驗，或者使用一些算術安全的第三方庫。如：OpenZeppelin提供了一套很好的SafeMath庫，使用SafeMath庫函數能夠有效避免四則運算溢出漏洞。

4、動態數組越界安全問題

對於數組越界這種嚴重的內存錯誤，不同的區塊鏈開發語言有各自的特點。

Java、Solidity、Go語言等跟其他大部分編程語言類似，在編譯期間會進行數組越界檢查。特別的是，在Solidity語言中動態數組將首先在變量定義處的虛擬機插槽位置存儲數組元素數量，之後根據該插槽位置的Keccak256值和下標位置計算特定元素值的存儲位置。

所以當動態數組下標是用戶可控的且數組長度不受限的情況下，攻擊者可以根據虛擬機的插槽深度構造對應的參數，使得參數指向虛擬機中的任意內存位置，從而修改對應插槽的狀態變量。

成都鏈安安全團隊對此建議：

在合約中訪問數組時，應當校驗參數合法性，即是否超過數組長度。

5、函數權限配置錯誤安全問題

函數是區塊鏈智能合約中的一個重要組成部分，而函數的權限控制決定了其是否可以被用戶或其他派生合約在外部調用，或僅在內部調用。

不同的語言同樣擁有不同的函數權限聲明方式，如：Solidity中可以使用四種可見性修飾符public 、private 、internal、external直接規定調用權限，同時也可以採用modifier實現對某些特權函數的嚴格權限控制。而go語言則採用函數首字母的大小寫聲明權限。

如果這些函數權限修飾符被開發者誤用，則會導致一些特殊功能的函數被攻擊者調用，造成諸如隨意更改藏品數量等嚴重後果。

成都鏈安安全團隊對此建議：

區塊鏈上涉及到合約中修改狀態變量的操作，必須對函數的調用權限進行嚴格控制。尤其涉及到一些重要屬性修改時，應當配置僅合約擁有者可以調用的權限。

6、忽略返回值安全問題

合約中的重要函數通常都有返回值，該值用於判斷函數操作是否執行成功，並對執行失敗的情況做出錯誤處理。

區塊鏈上合約的調用是通過交易實現的，交易產生的回執中status字段有兩種結果：0x1(true)、0x0(false)。但是交易是否成功僅取決於交易事務執行過程中是否拋出了異常，所以可能會出現函數執行失敗返回false，但是交易仍然是成功執行的情況。

因此如果區塊鏈開發人員採用鏈上交易回執替代函數返回值，並將其作為業務邏輯是否執行成功的判斷依據，就可能造成意想不到的安全問題。

成都鏈安安全團隊對此建議：

區塊鏈上涉及到函數返回值的判斷，除了判斷交易事務回執外，還應該再次判斷涉及到的狀態變量是否更改。

7、空指針引用安全問題

指針是區塊鏈開發中一種重要數據類型，用於表示複雜的數據結構、動態分配內存等。其中空指針是一個已經聲明但未指向任何一個有效對象的指針。

所以在Go、Java等語言中，當試圖對空指針進行解引用操作時，可能會導致拒絕服務攻擊或者程序異常中斷。特別的是，在Solidity中EVM存在兩種數據存儲的位置，分別是Storage和Memory。而未初始化的Storage類型局部變量默認值為0x0，所以這可能指向合約中的其他狀態變量。

如果該未初始化的變量可控，攻擊者可以利用該變量修改合約中對用插槽的狀態變量，從而造成嚴重後果。

成都鏈安安全團隊對此建議：

Remix-ide等編譯器會對未初始化的存儲器局部變量進行告警，在聲明變量時應對這些存儲器局部變量進行初始化，避免安全漏洞。

8、訪問外部資源安全問題

區塊鏈開發人員為了提升開發效率和保障安全性，同樣會引入第三方庫等外部資源，這些第三方庫代碼可能會存在安全缺陷，導致合約出現意想不到的問題。即使第三方庫本身不存在安全問題，也可能造成安全隱患。

如在solidity中，如果引入的合約代碼中包含狀態變量，而調用者又採取delegatecall的方式調用則會因為參數存儲位置的不一致而導致變量覆蓋或者異常終止的問題，影響正常的業務邏輯。同時無漏洞合約在某些情況下也可以以惡意行為的方式進行部署，造成嚴重的安全問題。

成都鏈安安全團隊對此建議：

1、開發人員應該謹慎使用第三方庫代碼。同時使用無狀態的庫代碼，並且避免使用代理調用的方式。

2、如果引用的外部合約地址已知的話，可以對引用合約的地址進行硬編碼。

9、輸入參數檢查安全問題

雖然區塊鏈開發中編譯器會對參數的合法性進行檢查，但是開發者同樣需要對每個函數的輸入參數進行預期檢查，使其符合業務邏輯。尤其涉及到一些包含特權操作的函數時，如：solidity中的call()函數，當該函數參數中的方法選擇器用戶可控，而EVM具有不校驗參數個數的特性，所以就可能造成代碼執行漏洞等嚴重後果。

成都鏈安安全團隊對此建議：

開發人員應對特函數作進行權限校驗，包括函數調用者的身份驗證，或者使用諸如private、internal等函數修飾符對函數本身進行權限控制。