如何保護(hù)智能合約不被重入攻擊

即將于12月初推出的伊斯坦布爾硬分叉包括EIP1884：“限制trie大小有關(guān)的操作碼”。關(guān)鍵字是“限制”，這意味著某些指令現(xiàn)在將花費(fèi)更多的氣體來執(zhí)行。最近對(duì)此進(jìn)行了很多討論的原因是現(xiàn)有的可以少量氣體運(yùn)行代碼，硬分叉后可能超過該限制，并導(dǎo)致會(huì)出現(xiàn)“out of gas”錯(cuò)誤。

“以少量氣體運(yùn)行代碼”的一個(gè)特例是任何Solidity智能合約中的fallback函數(shù)，因?yàn)樗怯蒘olidity的transfer函數(shù)或Solidity和Vyper的send函數(shù)觸發(fā)的以太坊傳遞過程中運(yùn)行的代碼。transfer和send都只允許以太坊的接收者以2300的氣體（實(shí)際上是零）。伊斯坦布爾到分叉后，接近此限制的fallback函數(shù)可能會(huì)停止工作，而任何調(diào)用這些函數(shù)的智能合約都將在有限的氣體中停止工作。

出于安全原因，到目前為止，推薦使用transfer和send來傳輸Ether。它們所允許的氣體不足以進(jìn)行重入攻擊，因此有論據(jù)認(rèn)為，它將保護(hù)智能合約免受它們的侵害。確實(shí)有……但是以太坊開發(fā)者社區(qū)現(xiàn)在正面臨這樣一個(gè)現(xiàn)實(shí)，即操作碼定價(jià)不能被認(rèn)為是穩(wěn)定的，并且如果我們希望構(gòu)建面向未來的系統(tǒng)，我們應(yīng)該尋求其他確保安全的方法。即我們應(yīng)該停止使用transfer，而轉(zhuǎn)而使用其他發(fā)送以太網(wǎng)的方法，而應(yīng)依賴其他安全技術(shù)來防止重入攻擊。

本文介紹了可重入性，目前可用于根據(jù)它獲得智能合約的技術(shù)，以及如何使用OpenZeppelin合約輕松在項(xiàng)目中實(shí)現(xiàn)它們。特別值得一提的是我們還沒有提到的一種技術(shù)：提款支付法（pull payments）。

什么是可重入攻擊？

智能合約在正常執(zhí)行期間可以通過執(zhí)行函數(shù)調(diào)用或簡(jiǎn)單地轉(zhuǎn)移以太坊來執(zhí)行對(duì)其他智能合約的調(diào)用。這些智能合約本身可以稱為其他智能合約。特別是它們可以回調(diào)到調(diào)用他們的智能合約或回調(diào)棧中的任何其他智能合約。在這種情況下，我們說智能合約被重新輸入，這種情況被稱為可重入性。

重入本身不是問題。當(dāng)智能合約以“不一致”狀態(tài)重新輸入時(shí)，就會(huì)出現(xiàn)問題。當(dāng)智能合約特定的不變量成立時(shí)，狀態(tài)被認(rèn)為是一致的。例如對(duì)于ERC20主要不變性是所有智能合約余額的總和不超過已知的總供應(yīng)量。

通常函數(shù)假定它們開始運(yùn)行時(shí)便以一致的狀態(tài)觀察智能合約，并且它們還承諾一旦完成運(yùn)行就使智能合約保持一致。在執(zhí)行過程中，可能會(huì)違反不變量，這很好，只要沒有人能觀察到不一致的狀態(tài)。問題在于通過重入，這成為可能。函數(shù)完成時(shí)，不僅要保持不變量，還必須在每個(gè)潛在的重入點(diǎn)保持不變。

當(dāng)我們調(diào)用不受信任的智能合約或?qū)①Y金轉(zhuǎn)入不受信任的帳戶時(shí)，我們的代碼容易受到重入攻擊的攻擊?？梢詫?duì)這些帳戶進(jìn)行特殊編程，以在重入調(diào)用期間濫用不變違規(guī)。

這里的不變之處在于，智能合約中的資金額等于余額映射中所有條目的總和。在第三行執(zhí)行調(diào)用期間，由于_amount資金已轉(zhuǎn)出，但余額尚未更新，因此不變量被破壞了。 由于msg.sender可以是智能合約，因此同一調(diào)用允許重入。 如果攻擊者此時(shí)觸發(fā)了重入，他們將能夠從破碎的不變量中獲利。

function withdraw（uint _amount） public {

if （amount 《= balances［msg.sender］） {

msg.sender.call.value（_amount）（）;

balances［msg.sender］ -= _amount;

}

}

現(xiàn)在，我們將看到幾種抵御這些攻擊的方法。

Checks-Effects-InteracTIons（檢查-效果-交互）

我們應(yīng)該提到的第一種技術(shù)稱為Checks-Effects-InteracTIons模式。 它描述了一種在函數(shù)中組織語句的方法，以使智能合約的狀態(tài)在調(diào)出其他智能合約之前處于一致的狀態(tài)。通過將每個(gè)語句分類為檢查，效果（狀態(tài)更改）或交互作用，并確保嚴(yán)格按照此順序進(jìn)行操作來完成此操作。通過在交互之前放置效果，我們可以確保所有狀態(tài)更改都在任何潛在的重入點(diǎn)之前完成，從而使?fàn)顟B(tài)保持一致。

已經(jīng)對(duì)這種模式進(jìn)行了很多討論，您應(yīng)該在Solidity文檔中和ConsenSys的最佳實(shí)踐中對(duì)其進(jìn)行閱讀。

但是我們應(yīng)該對(duì)這種方法不滿意，因?yàn)樗菀资艿饺藶殄e(cuò)誤的影響：程序員必須正確地應(yīng)用它，而審閱者必須發(fā)現(xiàn)任何錯(cuò)誤。是否可以減輕窮人的這種責(zé)任？

ReentrancyGuard（重入保護(hù)）

如果在執(zhí)行的任何時(shí)候不確定智能合約的不變量是否成立，則應(yīng)避免調(diào)用其他（不可信）智能合約，因?yàn)樗鼈兛赡軙?huì)被重入。 如果我們別無選擇，可以嘗試使用ReentrancyGuard來防止可重入。

ReentrancyGuard（重入保護(hù)）是一段代碼，當(dāng)檢測(cè)到重入時(shí)，該執(zhí)行會(huì)導(dǎo)致執(zhí)行失敗。OpenZeppelin合約中有一個(gè)稱為ReentrancyGuard（重入保護(hù)）的模式實(shí)現(xiàn)，該模式提供了nonReentrant修飾符。將此修飾符應(yīng)用于函數(shù)將使其變?yōu)椤安豢芍厝搿?，并且通過重新調(diào)用將拒絕重新輸入該函數(shù)的嘗試。

當(dāng)我們的智能合約具有多個(gè)函數(shù)時(shí)會(huì)發(fā)生什么？ 由于修飾符是針對(duì)每個(gè)函數(shù)的應(yīng)用，因此如果要完全防止重入攻擊，則必須將其應(yīng)用于所有函數(shù)。否則如果它對(duì)不可變的變量很敏感，仍然有可能重新進(jìn)入另一個(gè)函數(shù)并將其用于重入攻擊。

但是如果我們決定使每個(gè)函數(shù)都nonReentrant，則應(yīng)牢記Solidity的public變量。標(biāo)記為public的合約變量將生成一個(gè)getter函數(shù)以讀取其值，并且無法對(duì)該函數(shù)應(yīng)用修飾符。在大多數(shù)情況下，這不會(huì)引起重入問題，但仍然值得擔(dān)心，因?yàn)樗赡軙?huì)導(dǎo)致其他合約由于不可變而導(dǎo)致狀態(tài)不一致的情況（假設(shè)它們會(huì)保留）。

盡管有所有注意事項(xiàng)，但在某些情況下，重入防護(hù)（reentrancy guards）可能會(huì)很有價(jià)值。但是要完全消除可重入性也有其弊端：在某些情況下，可重入性是安全的，并且隨著以太坊智能合約變得更加復(fù)雜，可組合和相互聯(lián)系，我們可能會(huì)在外看到它的合法用途。

Pull Payments（提款支付法）

如果我們將Ether轉(zhuǎn)移到合約中但未執(zhí)行其代碼，則根本無法重入。通過使用selfdestruct，可以在EVM中繞過接收器的代碼。但是接收以太幣的合約需要以某種方式進(jìn)行處理，并且大多數(shù)沒有編程為處理通過自毀而收到的資金，這可能導(dǎo)致資金損失。

另一種選擇是提款支付模式（pull payment ）。這個(gè)想法是與其將資金“推”到接收者，不如將它們“拉”出合約。 OpenZeppelin合約在PullPayment合約中實(shí)現(xiàn)了這種模式。繼承此協(xié)定將提供類似于傳遞的內(nèi)部函數(shù)_asyncTransfer。但是它不會(huì)將資金發(fā)送給接收方，而是將其轉(zhuǎn)移到托管合約中。此外PullPayment還為接收者提供Public函數(shù)以提取其付款：withdrawPayments和withdrawPaymentsWithGas。

OpenZeppelin Contracts 2.4中添加了第二個(gè)命令withdrawPaymentsWithGas，以修復(fù)伊斯坦布爾的操作碼重新定價(jià)，并在實(shí)際的以太坊轉(zhuǎn)移過程中將所有可用的氣體轉(zhuǎn)發(fā)給接收器。請(qǐng)注意此時(shí)可以重新輸入，但這是安全的，因?yàn)镻ullPayment（提款支付法）不會(huì)使您的合約的任何不變式無效。

值得一提的是，提款功能可以由任何人調(diào)用，而不僅僅是接收方。這意味著收款人無需知道這是預(yù)付款的目標(biāo)，這在現(xiàn)有的智能合約無法自行付款時(shí)尤其重要。

總 結(jié)

由于操作碼定價(jià)不穩(wěn)定，我們不能再依賴轉(zhuǎn)移了，因此在后伊斯坦布爾世界中，重入變得不可避免。攻擊者可以將其用于破壞狀態(tài)不變性時(shí)調(diào)用不信任帳戶的合約。有必要通過根據(jù)checks-effects-interacTIons模式組織代碼，或使用諸如ReentrancyGuard（重入保護(hù)）措施或Pull Payments（提款支付法）等工具來對(duì)我們的合約進(jìn)行編程，以防止重入攻擊。