如何使用工廠模式來減少智能合約安全漏洞的影響

智能合約可以部署其他智能合約。這使工廠模式成為可能，在工廠模式中，您可以創(chuàng)建多個(gè)智能合同，每個(gè)智能合同只跟蹤一件事，而不是一個(gè)跟蹤許多事情的智能合同。使用此模式可以簡(jiǎn)化代碼并減少某些類型的安全漏洞的影響。

在這篇文章中，我將向您介紹一個(gè)基于我們?cè)谧罱膶徲?jì)中發(fā)現(xiàn)的一個(gè)關(guān)鍵漏洞的示例。如果使用了工廠模式，那么漏洞就就減少了很多。
?

越野車智能合約

下面是一個(gè)智能合約，通過一個(gè)相當(dāng)簡(jiǎn)單的界面銷售WETH。如果您有WETH，你只需要批準(zhǔn)這個(gè)智能合約出售你的代幣，它將確保你得到正確的金額支付。只要批準(zhǔn)充足的代幣，任何人都可以任意購買WETH。

合約使用提款模式將付款交付給賣方，但合約的作者犯了一個(gè)嚴(yán)重的錯(cuò)誤：

1// Technically this could sell any token， but we‘re selling WETH in this

2// example because then I don’t have to think about prices. 1 WETH costs 1 ETH.

3contract WETHMarket {

4 IERC20 public weth;

5 mapping（address =》 uint256） public balanceOf;

6

7 constructor（IERC20 _weth） public {

8 weth = _weth;

9 }

10

11 // Buy WETH from a specified seller. Seller must first approve WETH.

12 function buyFrom（address seller） external payable {

13 balanceOf［seller］ += msg.value;

14 require（weth.transferFrom（seller， msg.sender， msg.value），

15 “WETH transfer failed.”）;

16 }

17

18 // Used by a seller to get their ETH.

19 funcTIon withdraw（uint256 amount） external {

20 require（amount 《= balanceOf［msg.sender］， “Insufficient funds.”）;

21

22 // Whoops！ Forgot this：

23 // balanceOf［msg.sender］ -= amount;

24

25 （bool success， ） = msg.sender.call.value（amount）（“”）;

26 require（success， “ETH transfer failed.”）;

27 }

28}

（如果您想知道為什么代碼使用.call而不是.transfer，請(qǐng)閱讀“立即停止使用Solidity的傳輸（）”）。

因?yàn)橘u方的余額從未減少，所以欠任何以太的賣方都可以反復(fù)調(diào)用withdraw（）來消耗每個(gè)人的合約。這是一個(gè)嚴(yán)重的漏洞。

修復(fù)這個(gè)bug，就像大多數(shù)bug一樣，一旦你發(fā)現(xiàn)了它，就變得微不足道了。但在這篇文章中，我想談?wù)勅绾瓮ㄟ^使用工廠模式來減輕這個(gè)bug，即使我們不知道這個(gè)特定的問題。

現(xiàn)在讓我們看一下更簡(jiǎn)單的WETHMarket合約版本。在這個(gè)版本中，合約只負(fù)責(zé)銷售一個(gè)賣家的WETH。此合約與先前版本具有相同的bug：

1contract WETHSale {

2 IERC20 public weth;

3 address seller; // only a single seller

4 uint256 public balance; // no need for a mapping anymore

5

6 constructor（IERC20 _weth， address _seller） public {

7 weth = _weth;

8 seller = _seller;

9 }

10

11 // No need to specify the seller.

12 funcTIon buy（） external payable {

13 balance += msg.value;

14 require（weth.transferFrom（seller， msg.sender， msg.value））;

15 }

16

17 funcTIon withdraw（uint256 amount） external {

18 require（msg.sender == seller， “Only the seller can withdraw.”）;

19 require（amount 《= balance， “Insufficient funds.”）;

20

21 uint256 amount = balance;

22

23 // Whoops！ Forgot this：

24 // balance -= amount;

25

26 （bool success， ） = msg.sender.call.value（amount）（“”）;

27 require（success， “ETH transfer failed.”）;

28 }

29}

盡管存在完全相同的邏輯錯(cuò)誤，但此漏洞并不是那么嚴(yán)重。只允許一個(gè)帳戶調(diào)用withdraw（），并且合約中存儲(chǔ)的所有以太網(wǎng)都屬于該帳戶。這個(gè)錯(cuò)誤的影響只是余額并不能反映合約中的真實(shí)余額。

這個(gè)bug是手工挑選來顯示其優(yōu)點(diǎn)的，但是這個(gè)bug代表了托管協(xié)議中的一大類bug。根據(jù)我審計(jì)智能合約的經(jīng)驗(yàn)，這是發(fā)現(xiàn)關(guān)鍵漏洞最常見的地方之一。

托管背后的想法是，不同的資金必須分開存放，以確保合同始終可以涵蓋所有欠款。獲得托管權(quán)最簡(jiǎn)單的方法之一是將資金完全分成不同的智能合約。

您可以將工廠模式看作是一種深入防御的托管方法。

簡(jiǎn)單代碼

單賣方版本的合約不僅有更強(qiáng)大的代管，而且更簡(jiǎn)單。我們?nèi)サ袅艘粋€(gè)函數(shù)參數(shù)和一個(gè)映射。在生產(chǎn)代碼中，我們可能會(huì)更進(jìn)一步，完全刪除balance，而代之以address（this）.balance。

因?yàn)槲覍懞霞s是為了方便閱讀，原來的代碼已經(jīng)很簡(jiǎn)單了。在現(xiàn)實(shí)世界的例子中，這種差異可能更為顯著。從安全的角度來看，任何降低復(fù)雜性的機(jī)會(huì)都是一種勝利。

工廠模式

每個(gè)賣家都可以部署自己的Wethsale合約并從簡(jiǎn)單的合約中獲益，但是這種方法有一個(gè)主要的缺點(diǎn)，惡意賣家可能會(huì)部署稍微修改過的代碼版本，但實(shí)際上并沒有傳輸weth。

即使像ConsenSys Diligence這樣有信譽(yù)的公司審核了WETHSale代碼，每個(gè)買家也必須驗(yàn)證他們購買的具體合約是否使用了那些確切的代碼。

使用工廠可以解決這個(gè)問題。工廠確保每個(gè)部署的合約都使用相同的代碼，并且它提供了一個(gè)簡(jiǎn)單的查找機(jī)制來查找給定賣方的單一合約：

contract WETHSaleFactory {

IERC20 public weth;

mapping（address =》 WETHSale） public sales;

constructor（IERC20 _weth） public {

weth = _weth;

}

funcTIon deploy（） external {

require（sales［msg.sender］ == WETHSale（0）， “Only one sale per seller.”）;

sales［msg.sender］ = new WETHSale（weth， msg.sender）;

}

}

潛在缺陷

使用工廠模式的一個(gè)主要缺點(diǎn)是價(jià)格昂貴。CREATE操作碼目前的燃?xì)獬杀緸?2，000。我們的特殊合約還需要另外兩個(gè)SSTORE來跟蹤WETH和賣方地址，每個(gè)地址需要20，000燃?xì)?。這比代碼的原始多賣家版本至少多72，000氣體。

另一個(gè)潛在的缺點(diǎn)是復(fù)雜性。在大多數(shù)實(shí)際情況下，工廠模式簡(jiǎn)化了現(xiàn)有的合同，但請(qǐng)記住，它還添加了一個(gè)新的合同：工廠本身。根據(jù)代碼的不同，這可能會(huì)導(dǎo)致復(fù)雜性的增加。

在決定工廠模式之前，請(qǐng)仔細(xì)考慮變更的總體影響。

總結(jié)

1. 托管方面的錯(cuò)誤是導(dǎo)致關(guān)鍵漏洞的一個(gè)重要原因。

2. 使用單獨(dú)的智能合約可以降低這些錯(cuò)誤的嚴(yán)重性。

3. 工廠模式以一種不可信任的方式實(shí)現(xiàn)了這一點(diǎn)。

4. 在采用工廠模式之前還要考慮潛在的缺點(diǎn)。
來源： 區(qū)塊鏈研究實(shí)驗(yàn)室?