重入攻擊：理解和防止這種智能合約漏洞

我花了無數小時調試合約漏洞，讓我告訴你——重入攻擊是智能合約的隱形殺手。它們看似簡單卻極具破壞性。讓我們深入了解它們是什麼，以及如何在它們耗盡你的資金之前阻止它們。

當我第一次遇到重入漏洞時，我花了數小時試圖理解有人如何能夠利用這樣一段看似無辜的代碼。這個概念令人沮喪地簡單：一個合約可以在第一個執行完成之前回調另一個合約。

想象一下：ContractA 有 10 ETH，而 ContractB 已經存入了 1 ETH。當 ContractB 提取其資金時，ContractA 在將 B 的餘額更新爲零之前發送了 ETH。這個微小的順序錯誤造成了巨大的安全漏洞。

發生了什麼？惡意合約的回退函數立即再次調用withdraw()，由於餘額尚未更新，它再次通過餘額檢查！這個循環會一直重復，直到ContractA被完全耗盡。真聰明，不是嗎？

攻擊者如何在代碼中利用這一點：

// 攻擊合約調用 withdraw() 合約 A 發送 ETH 以 ETH 觸發 fallback() // fallback() 在餘額更新之前再次調用 withdraw() // 清洗並重復，直到所有資金被盜

我見過項目因爲沒有理解這個簡單的攻擊向量而損失數百萬。這讓我感到憤怒的是，仍然有很多開發者犯這樣的初學者錯誤。

保護您的合同的三種技術

1. 非重入修飾符

   這在執行期間鎖定合約，防止任何帶有此修飾符的功能被重新進入。簡單但有效。

2. 檢查-效果-交互模式

   這是我個人最喜歡的。代替：

   // 脆弱 require(balance > 0); send(ether); 餘額 = 0;

   做這個:

安全 require(balance > 0); balance = 0; // 在外部交互之前更新狀態 send(以太坊);

在發送ETH或代幣之前，請始終更新您的狀態！

3. GlobalReentrancyGuard

對於具有多個相互作用的合約的項目，這通過使用共享鎖定機制爲您的整個合約生態系統提供保護。

這些技術不僅僅是學術上的——它們已經拯救了無數項目免於完全的財務破產。

太多開發者仍然認爲"這不會發生在我身上"，因此跳過這些保護措施。不要成爲那種人。每一個發送ETH或代幣的函數都應該至少實施其中一種保護機制。

記住，在智能合約開發中，偏執是一種特性，而不是錯誤。一個遺漏的保護措施可能會導致一切付諸東流。