如何使用工廠模式來(lái)減少智能合約安全漏洞的影響
智能合約可以部署其他智能合約。這使工廠模式成為可能,在工廠模式中,您可以創(chuàng)建多個(gè)智能合同,每個(gè)智能合同只跟蹤一件事,而不是一個(gè)跟蹤許多事情的智能合同。使用此模式可以簡(jiǎn)化代碼并減少某些類(lèi)型的安全漏洞的影響。
在這篇文章中,我將向您介紹一個(gè)基于我們?cè)谧罱膶徲?jì)中發(fā)現(xiàn)的一個(gè)關(guān)鍵漏洞的示例。如果使用了工廠模式,那么漏洞就就減少了很多。
?
越野車(chē)智能合約
下面是一個(gè)智能合約,通過(guò)一個(gè)相當(dāng)簡(jiǎn)單的界面銷(xiāo)售WETH。如果您有WETH,你只需要批準(zhǔn)這個(gè)智能合約出售你的代幣,它將確保你得到正確的金額支付。只要批準(zhǔn)充足的代幣,任何人都可以任意購(gòu)買(mǎi)WETH。
合約使用提款模式將付款交付給賣(mài)方,但合約的作者犯了一個(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(mài)方的余額從未減少,所以欠任何以太的賣(mài)方都可以反復(fù)調(diào)用withdraw()來(lái)消耗每個(gè)人的合約。這是一個(gè)嚴(yán)重的漏洞。
修復(fù)這個(gè)bug,就像大多數(shù)bug一樣,一旦你發(fā)現(xiàn)了它,就變得微不足道了。但在這篇文章中,我想談?wù)勅绾瓮ㄟ^(guò)使用工廠模式來(lái)減輕這個(gè)bug,即使我們不知道這個(gè)特定的問(wèn)題。
現(xiàn)在讓我們看一下更簡(jiǎn)單的WETHMarket合約版本。在這個(gè)版本中,合約只負(fù)責(zé)銷(xiāo)售一個(gè)賣(mài)家的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è)帳戶(hù)調(diào)用withdraw(),并且合約中存儲(chǔ)的所有以太網(wǎng)都屬于該帳戶(hù)。這個(gè)錯(cuò)誤的影響只是余額并不能反映合約中的真實(shí)余額。
這個(gè)bug是手工挑選來(lái)顯示其優(yōu)點(diǎn)的,但是這個(gè)bug代表了托管協(xié)議中的一大類(lèi)bug。根據(jù)我審計(jì)智能合約的經(jīng)驗(yàn),這是發(fā)現(xiàn)關(guān)鍵漏洞最常見(jiàn)的地方之一。
托管背后的想法是,不同的資金必須分開(kāi)存放,以確保合同始終可以涵蓋所有欠款。獲得托管權(quán)最簡(jiǎn)單的方法之一是將資金完全分成不同的智能合約。
您可以將工廠模式看作是一種深入防御的托管方法。
簡(jiǎn)單代碼
單賣(mài)方版本的合約不僅有更強(qiáng)大的代管,而且更簡(jiǎn)單。我們?nèi)サ袅艘粋€(gè)函數(shù)參數(shù)和一個(gè)映射。在生產(chǎn)代碼中,我們可能會(huì)更進(jìn)一步,完全刪除balance,而代之以address(this).balance。
因?yàn)槲覍?xiě)合約是為了方便閱讀,原來(lái)的代碼已經(jīng)很簡(jiǎn)單了。在現(xiàn)實(shí)世界的例子中,這種差異可能更為顯著。從安全的角度來(lái)看,任何降低復(fù)雜性的機(jī)會(huì)都是一種勝利。
工廠模式
每個(gè)賣(mài)家都可以部署自己的Wethsale合約并從簡(jiǎn)單的合約中獲益,但是這種方法有一個(gè)主要的缺點(diǎn),惡意賣(mài)家可能會(huì)部署稍微修改過(guò)的代碼版本,但實(shí)際上并沒(méi)有傳輸weth。
即使像ConsenSys Diligence這樣有信譽(yù)的公司審核了WETHSale代碼,每個(gè)買(mǎi)家也必須驗(yàn)證他們購(gòu)買(mǎi)的具體合約是否使用了那些確切的代碼。
使用工廠可以解決這個(gè)問(wèn)題。工廠確保每個(gè)部署的合約都使用相同的代碼,并且它提供了一個(gè)簡(jiǎn)單的查找機(jī)制來(lái)查找給定賣(mài)方的單一合約:
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來(lái)跟蹤WETH和賣(mài)方地址,每個(gè)地址需要20,000燃?xì)?。這比代碼的原始多賣(mài)家版本至少多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)。
來(lái)源: 區(qū)塊鏈研究實(shí)驗(yàn)室?