スマートコントラクトにおける再入攻撃：包括的な防止ガイド

再入攻撃は、スマートコントラクトのセキュリティにおける最も重要な脆弱性の一つです。本記事では、再入攻撃の詳細な技術分析を提供し、コード例を通じてそのメカニズムを示し、スマートコントラクトを保護するための3つの戦闘実績のある予防技術を紹介します。

リエントランシーを理解する:基本的な概念

本質的に、再入攻撃は、あるコントラクト(ContractB)が、最初の関数呼び出しが完了する前に、呼び出し元のコントラクト(ContractA)にコールバックする際に発生します。この脆弱性は、資金を排出したり、コントラクトの状態を操作したりするために悪用できる関数呼び出しの再帰ループを作成します。

重要な洞察: コントラクトが内部状態を更新する前に外部コールを実行する場合、再入可能性の脆弱性が存在します。

このシナリオを考えてみてください：

• ContractAの残高は10ETHです
• ContractBがContractAに1ETHを入金した
• ContractAには脆弱な引き出し機能があります

ContractBがこの脆弱性を悪用すると、ContractAの資金を draining するために、一連の再帰呼び出しを実行することができます。残高の更新が発生する前に。

リエントランシー攻撃の構造

攻撃パターンは通常、2つの重要な要素で構成されています:

1. エクスプロイトを開始するattack()機能
2. ETHを受信したときに実行されるフォールバック()関数は、再帰ループを作成します。

攻撃は以下の順序で実行されます:

1. 攻撃者は彼らの悪意のある契約で attack() を呼び出します
2. 悪意のある契約が脆弱な契約内で withdraw() を呼び出します
3. 脆弱なコントラクトが攻撃者にETHを送信し、フォールバック関数をトリガーします。
4. フォールバック関数内で、攻撃者は再帰的にwithdraw()を再度呼び出します。
5. このサイクルは、脆弱なコントラクトの資金が枯渇するまで繰り返されます

歴史的意義: 2016年の悪名高いDAOハッキングは、約$60 百万ドル相当のETHの損失をもたらし、最終的にEthereumのハードフォークにつながった高プロファイルの再入金攻撃でした。

脆弱なコード分析

脆弱なコントラクトの実装を見てみましょう：

硬度 コントラクトEtherStore { mapping(address => uint) 公的残高。

公的支払額deposit()関数{ balances[msg.sender] += msg.value; }

関数 withdrawAll() public { uint bal = 残高[msg.sender]; require(bal > 0);

送信された(bool、 ) = msg.sender.call{value: bal}(""); require(sent、「Ether の送信に失敗しました」);

残高[msg.sender] = 0; } }

このコードの重大な脆弱性は、コントラクトが送信者の残高を更新する前に、ETH (msg.sender.call{value: bal}(""))を送信することです。このシーケンスは再入可能性の脆弱性を生み出します。

脆弱性の悪用

攻撃者は、このような契約を展開して脆弱なEtherStoreを悪用するでしょう:

硬度 コントラクトアタック{ EtherStoreパブリックetherStore;

constructor(address _etherStoreAddress) { etherStore = EtherStore(_etherStoreAddress); }

// フォールバック関数 - EtherStoreがEtherを送信したときに呼び出されます

fallback() 外部未払金 { (address)etherStore(.balance >= 1 ether( { etherStore.withdrawAll)); } }

外部債務attack()関数 { require(msg.value >= 1 ether); etherStore.deposit{値: 1 ether}(); etherStore.withdrawAll(); } }

攻撃フロー:

1. 攻撃者がattack()に電話をかけ、1ETHを入金
2. 攻撃者がEtherStoreでwithdrawAll()を呼び出す
3. EtherStoreは1 ETHを返送し、フォールバック関数をトリガーします。
4. フォールバック関数内で、攻撃者は再帰的に withdrawAll() を再度呼び出します。
5. 残高がまだ更新されていないため、このサイクルはEtherStoreが枯渇するまで続きます

リエントランシーに対する3つの防御テクニック

( 1. 機能レベルの保護: noReentrant モディファイア

この修飾子は、関数がまだ実行中である間に再入を防ぐロックメカニズムを作成します:

硬度 契約ReentrancyGuard { bool private locked = false;

修飾子 noReentrant)### { require(!locked, "リエントラントコール"); ロック = true; _; ロック = false; } }

契約 SecureEtherStore は ReentrancyGuard { mapping(address => uint) 公的残高。

関数 withdrawAll() public noReentrant { uint bal = 残高[msg.sender]; require(bal > 0);

送信された(bool、 ) = msg.sender.call{value: bal}(""); require(sent、「Ether の送信に失敗しました」);

残高[msg.sender] = 0; } }

テクニカル分析: 修飾子は状態変数 (locked) を設定して再入場を防ぎます。この修飾子を持つ関数が既に実行中の際に呼び出された場合、トランザクションはロールバックされます。

( 2. クロスファンクションプロテクション: チェックス・エフェクツ・インタラクションズパターン

このパターンは、外部との相互作用の前に状態変更が行われることを確実にすることによって、クロスファンクションの再入を解決します：

ソリディティ 傷つきやすい 関数 withdrawAll)### public { uint bal = 残高[msg.sender]; require(bal > 0);

送信された(bool、 ) = msg.sender.call{value: bal}(""); require(sent、「Ether の送信に失敗しました」);

残高[msg.sender] = 0;外部呼び出し後に状態が更新されました }

牢 関数 withdrawAll() public { uint bal = 残高[msg.sender]; require(bal > 0);

残高[msg.sender] = 0;外部呼び出しの前に状態が更新されました

送信された(bool、 ) = msg.sender.call{value: bal}(""); require(sent、「Ether の送信に失敗しました」); }

テクニカル分析: 外部コールを行う前にステート変数を更新することで、コントラクトは外部コールが再入可能であっても、ステートがすでに適切に変更されていることを保証し、悪用を防ぎます。

( 3.クロスコントラクト保護: GlobalReentrancyGuard

複数の相互作用する契約を持つプロジェクトでは、グローバル再入防止ガードを実装することで、システム全体の保護が提供されます。

ソリディティ 契約 GlobalReentrancyGuard { boolプライベート_notEntered;

constructor)### { _notEntered = 真; }

修飾子 globalNonReentrant() { require(_notEntered、「ReentrancyGuard:再入可能な通話」); _notEntered = false; _; _notEntered = 真; } }

コントラクト ContractA は GlobalReentrancyGuard { 関数 transferFunds() public globalNonReentrant { 安全な実装 } }

コントラクト ContractB は GlobalReentrancyGuard { 関数 withdrawFunds() public globalNonReentrant { // セーフ実装 } }

テクニカル分析: このアプローチは、同じエコシステム内の複数のコントラクト間での再入を防ぐために共有コントラクト状態を使用し、関数レベルだけでなくシステムレベルでの保護を提供します。

セキュリティベストプラクティス実装マトリックス

| 防止技術 | 保護レベル | ガスコスト | 実装の複雑さ | 最適 | |----------------------|------------------|----------|---------------------------|----------| | noReentrant モディファイア | 関数レベル | 低-中 | シンプル | 単一の脆弱な関数 | | チェック-効果-相互作用 | コントラクトレベル | 低 | 中 | 一般的な契約のセキュリティ | | グローバル再入防止ガード | システムレベル | 中 | 複雑 | マルチコントラクトシステム |

技術的な実装に関する考慮事項

再入防止を実装する際、開発者は以下を考慮すべきです：

1. ガス最適化: 再入可能性ガードは関数実行にオーバーヘッドを追加します。高頻度の操作におけるパフォーマンスへの影響を考慮してください。

2. エッジケース: 一部の正当なユースケースは再入可能な動作を必要とします。保護メカニズムが意図した機能を損なわないようにしてください。

3. 監査要件: 保護メカニズムが整っていても、プロのセキュリティ監査は、より複雑な脆弱性を検出するために不可欠です。

4. 保護範囲: 異なる再入攻撃防止メカニズムは異なる攻撃ベクトルに対処します。あなたの契約の特定の脆弱性を理解することは、適切な保護を選択するために重要です。

再入攻撃のメカニズムを理解し、適切な保護メカニズムを実装することで、開発者はブロックチェーンエコシステムで最も一般的で危険な脆弱性の一つに対するスマートコントラクトのセキュリティを大幅に強化することができます。