リエントランシー攻撃とは何ですか?また、スマートコントラクトはそれをどのように防御できますか?

スマートコントラクトにおけるリエントランシー攻撃を理解する

1. 再入攻撃は、最初の実行が完了する前に、悪意のあるコントラクトが別のコントラクトの脆弱な機能を繰り返しコールバックするときに発生します。このエクスプロイトは、状態の変更と外部呼び出しが実行される順序を利用します。

2. 最も悪名高い例は、2016 年の DAO ハッキングです。このハッキングでは、攻撃者がイーサを送信する前に残高を更新できなかった契約から資金を再帰的に引き出し、6,000 万ドル以上を流出させました。

3. これらの攻撃は通常、重要な状態変数を矛盾した状態に保持しながら、信頼できないコントラクトへの外部呼び出しを行う関数をターゲットとします。

4. 再帰呼び出し中に、攻撃者のフォールバックまたは受信関数が同じ引き出しロジックを再度トリガーし、アクセス制御や残高チェックを事実上バイパスします。

5. 中心的な脆弱性は、チェック効果相互作用パターンに違反することにあります。このパターンでは、実行中の操作を防ぐために、状態の変更は常に外部呼び出しよりも前に行われる必要があります。

Solidity における一般的な脆弱なパターン

1. 最初に内部アカウンティングを更新せずに、ユーザーが制御するアドレスに Ether またはトークンを送信する機能は、再入可能性の主なターゲットです。

2. ネイティブ Ether 転送によるコールなどの低レベルのコールを使用するコントラクトは、残りのすべてのガスを転送し、複雑なコールバック ロジックが可能になるため、特にリスクにさらされます。

3. 呼び出し後の検証に依存するロジックは、呼び出し自体が再帰エントリをトリガーすると失敗し、損傷が発生するまでそれらのチェックが無効になります。

4. たとえ子コントラクトが安全であるように見えても、親コントラクトが適切な保護を強制しない場合、継承構造により意図せずに機能が公開される可能性があります。

5. デリゲートコール メカニズムが共有ストレージ レイアウトを通じて状態の破損を許可する場合、ライブラリまたはプロキシ パターンによって脆弱性が伝播する可能性があります。

効果的な防御メカニズム

1. Checks-Effects-Interactionsパターンを厳密に実装します。常に入力を検証し、状態変数を更新してから、外部呼び出しを続行します。

2. OpenZeppelin の ReentrancyGuard などの確立されたライブラリの再入ガードを使用します。このガードは、ミューテックス ロックを使用して再帰エントリをブロックします。

3.電話の代わりに転送または送信を介して資金を転送することを好みます。これらの方法はガス転送を制限し、攻撃対象領域を減らすためです。

4. 自動的に送金されるのではなく、ユーザーが資金を請求するプルオーバープッシュ支払いモデルを採用し、アウトバウンド コールのリスクを排除します。

5. 開発中に厳密な静的分析ツールと正式な検証を適用して、展開前に潜在的な再帰パスを検出します。

よくある質問

再入シナリオにおいてフォールバック機能が危険になるのはなぜですか?フォールバック関数は、呼び出し側コントラクトのビジネス関数を再度呼び出すロジックが含まれている場合、危険になります。外部呼び出しを行う前に元のコントラクトの状態が更新されていない場合、この再帰トリガーによって古い残高やアクセス許可が悪用される可能性があります。

複数の契約対話にわたって再入が発生する可能性はありますか?はい、同じコントラクト内の異なる機能が適切な同期を行わずに共有状態にアクセスすると、機能間の再入が可能になります。攻撃者は、外部から呼び出す 1 つの関数をトリガーし、状態が更新される前にフォールバックを使用して 2 番目の脆弱な関数に入る可能性があります。

非イーサ契約は再入の影響を受けませんか?いいえ、ERC-20 転送を処理するトークン コントラクトも悪用される可能性があります。トークン転送が受信側フック (承認 + コールバックなど) をトリガーし、受信コントラクトが転送中に送信側の状態を操作する場合、同様の再帰的エクスプロイトが出現します。

コンパイラのアップグレードは再入を軽減するのにどのように役立ちますか? Solidity の新しいバージョンには、より安全なデフォルトと既知のアンチパターンに対する警告が含まれています。たとえば、明示的な可視性指定子と改善されたガソリン給金ルールにより、意図しない動作が減少します。ただし、コンパイラ機能だけでは、アーキテクチャ上の規律を必要とする論理的欠陥を排除することはできません。