スマートコントラクトにおける再入攻撃: 脆弱性の理解と防止策の実装

再入攻撃は、スマートコントラクトセキュリティにおける最も悪名高い脆弱性の一つであり、さまざまなブロックチェーンプロトコルにおいて数百万ドルの盗まれた資金に関与しています。本記事では、再入脆弱性のメカニズムを探り、セキュリティに配慮した開発者が実装すべき包括的な防止技術を提示します。

再入攻撃とは何ですか？

本質的に、再入攻撃はスマートコントラクト内の関数が前の実行が完了する前に繰り返し呼び出されるときに発生します。根本的な脆弱性は、スマートコントラクトが自らの状態変更を解決する前に外部コントラクトを呼び出すときに生じ、悪用の機会を生み出します。

典型的なシナリオでは、契約Aが契約Bの関数の1つを呼び出すことで相互作用します。契約Bが契約Aが元の関数を実行中に契約Aに再度呼び出す能力を得るとき、重大なセキュリティの欠陥が現れます。この再帰的な相互作用パターンは、潜在的な悪用の基盤を形成します。

再入攻撃の仕組み：ステップバイステップの内訳

このシナリオを考えてみてください: コントラクトAは合計10 ETHを保持しており、コントラクトBはコントラクトAに1 ETHを預けています。脆弱性は、コントラクトBが次のシーケンスを通じて資金を引き出そうとしたときに悪用可能になります:

1. コントラクトBはコントラクトAのwithdraw()関数を呼び出します。
2. コントラクトAはコントラクトBの残高が0より大きいことを確認します(チェックを通過)
3. コントラクトAはETHをコントラクトBに送信し、コントラクトBのフォールバック関数をトリガーします
4. 契約Aが契約Bの残高をゼロに更新する前に、契約Bのフォールバック関数がwithdraw()を再度呼び出します
5. コントラクトAはコントラクトBの残高を確認しますが、まだ更新されていない1 ETH (が表示されています)
6. プロセスは契約Aの資金が枯渇するまで繰り返されます

主要な脆弱性は、ETHの転送後に残高の更新が行われるため、攻撃者が残高をゼロに設定される前に同じ残高を複数回悪用できることです。

攻撃の構造: 技術的な実装

脆弱なコードパターンを検証してみましょう:

ソリディティ // 脆弱なEtherStoreコントラクト コントラクト 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; } }

さて、攻撃者がこの脆弱性をどのように悪用するか見てみましょう:

ソリディティ リエントランシーの脆弱性を悪用した攻撃コントラクト コントラクトアタック{ EtherStoreパブリックetherStore;

コンストラクタ(アドレス _etherStoreAddress) {

etherStore = EtherStore(_etherStoreAddress); }

// EtherStoreがEtherを送信する際に呼び出されるフォールバック関数
受け取る() 外部の支払い {

if(アドレス(etherStore).balance >= 1 ether) { withdrawAll機能を再入力します etherStore.withdrawAll(); } }

外部債務attack()関数 { require(msg.value >= 1 ether);

    // EtherStoreにバランスを確立するために入金する

etherStore.deposit{値: 1 ether}();

    // 出金プロセスを開始し、再入攻撃を引き起こす

etherStore.withdrawAll(); } }

攻撃シーケンスは、攻撃者がattack()を呼び出すと始まります。これにより1 ETHが預けられ、残高が設定され、その後withdrawAll()が呼び出されます。EtherStoreがETHを返すと、攻撃契約内のreceive()関数がトリガーされ、残高が更新される前に再度withdrawAll()が呼び出されます。このループは、EtherStoreの資金が枯渇するまで続きます。

包括的な予防技術

セキュリティに配慮した開発者は、再入可能性の脆弱性から保護するために、3つの堅牢な技術を実装できます:

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

個々の機能レベルで最も一般的な保護は、再入可能ガードを実装することです。

ソリディティ 契約ReentrancyGuard { bool private locked = false;

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

// 脆弱な関数にこの修飾子を適用します

関数 withdrawFunds() public nonReentrant { // 再入可能性から保護された関数コード } }

このアプローチは、関数の実行中に契約をロックし、関数が完了して状態がアンロックされるまで、再帰的な呼び出しを防ぎます。

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;エフェクト(state changes)

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

チェック-効果-相互作用パターンに従うことで、契約は外部相互作用の前にその状態を更新し、攻撃者が再入場を試みても、更新された状態(ゼロ残高)に遭遇することを保証します。

3. プロジェクトレベルの保護: グローバル再入可能性ガード

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

ソリディティ 契約 GlobalReentrancyGuard { ブール private _notEntered = true;

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

// プロジェクト内のすべてのコントラクトはGlobalReentrancyGuardから継承します 契約 SecureContract は GlobalReentrancyGuard { 関数 vulnerableOperation() public globalNonReentrant { // プロジェクト全体での再入防止 } }

このアプローチは、複数の契約が相互に作用するDeFiプロトコルにおけるクロスコントラクト再入攻撃から保護するために特に価値があります。

リエントランシーの脆弱性の現実世界への影響

再入可能性の脆弱性は、ブロックチェーンの歴史の中で最も壊滅的なエクスプロイトのいくつかを引き起こしました。2016年の悪名高いDAOハッキングは、約360万ETHの盗難をもたらし、当時(百万ドル相当で、最終的にはEthereum Classicを生み出すEthereumのハードフォークにつながりました。

最近では、2020年にLendf.Meプロトコルが再入攻撃により約$50 百万を失ったことが強調されており、認識の向上にもかかわらず、これらの脆弱性はスマートコントラクトのセキュリティに対して依然として重大なリスクをもたらすことが示されています。

セキュリティのベストプラクティス

具体的に言及された技術を超えて、開発者はこれらの追加のセキュリティプラクティスに従うべきです:

1. 常に最新のSolidityバージョンを使用してください それは改善されたセキュリティ機能を提供します
2. 対象契約は信頼できる企業による徹底的なセキュリティ監査を受ける
3. 包括的なテストカバレッジを実装する エッジケースの単体テストを含む
4. 新しい契約を本番環境に展開する際は、最小限のETHエクスポージャーから始める
5. 高価値契約のために形式検証を考慮する

これらの防御技術を実装し、セキュリティのベストプラクティスに従うことで、開発者は再入攻撃のリスクを大幅に軽減し、ブロックチェーンアプリケーションのためにより安全なスマートコントラクトを構築することができます。