如何使用工廠模式來減少智能合約安全漏洞的影響
智能合約可以部署其他智能合約。這使工廠模式成為可能，在工廠模式中，您可以創(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)充足的代幣，任何人都可以任意購(gòu)買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òu)買的具體合約是否使用了那些確切的代碼。
使用工廠可以解決這個(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)室?
下載文檔
