スマート コントラクトを再入攻撃から保護するにはどうすればよいですか?

再入可能性の脆弱性を理解する

1. 再入攻撃は、最初の関数の実行が完了する前に、脆弱なコントラクトにコールバックする外部コントラクトの機能を悪用します。

2. これは、外部呼び出しの前に状態の変更が完了していない場合に発生し、悪意のあるコードが残高やフラグを繰り返し操作できるようになります。

3. 2016 年の悪名高い DAO ハッキングでは、再帰的な引き出しパターンによって 6,000 万ドル相当の ETH がどのように流出するのかが実証されました。

4. このような脆弱性は、転送、引き出し、または状態更新に続く外部呼び出しを伴うロジックを処理する関数で顕著です。

5. 0.8.0 より前の Solidity バージョンには再入可能ガードが組み込まれていなかったため、従来の展開では手動による保護が不可欠でした。

チェック - 効果 - インタラクション パターンの実装

1. このアーキテクチャ規律では、すべての内部状態の変更が外部との相互作用の前に行われることが義務付けられています。

2. たとえば、ユーザーの残高の更新は、転送の呼び出しまたは別のアドレスでの呼び出しの前に行う必要があります。

3. この命令に違反すると、攻撃者が制御フローを乗っ取り、同じ機能に再度侵入する可能性が高まります。

4. 順序が適切であっても、開発者は、イベント エミッターや修飾子などの中間関数が意図しない外部呼び出しをトリガーしていないことを確認する必要があります。

5. Slither や MythX などのツールは、バイトコードとソースの静的分析中にこのパターンからの逸脱を検出できます。

ReentrancyGuard 修飾子の使用

1. OpenZeppelin のReentrancyGuardは、ブール値フラグを使用して関数をロックする、広く監査されているユーティリティです。

2. 修飾子は、実行前に_statusを_ENTEREDに設定し、完了後に_NOT_ENTEREDにリセットします。

3. 同じ保護された関数に再度入ろうとするネストされた呼び出しは、アクティブなロックにより元に戻ります。

4. すべての機密エントリ ポイントが同じガード インスタンスを共有しない限り、機能間の再入は防止されません。

5. 開発者は、継承階層がガード状態を正しく初期化し、内部変数のシャドウイングを回避することを確認する必要があります。

緩和戦略としてのガス制限

1. call.gas(2300)のような低レベルの呼び出しで転送されるガスを明示的に制限することで、受信者のコントラクトが複雑なロジックを実行するのを防ぎます。

2. この手法は、実行を 2300 ガスに制限するsendおよびtransferのガス支給を模倣します。

3. ただし、ガス制限のみに依存するのは脆弱です。将来の EVM アップグレードやカスタム オペコードにより、ガス コストが予期せず変化する可能性があります。

4. また、ロギングやリバランスを実行するなど、フォールバック ロジックに最小限以上のガスを必要とするコントラクトとの互換性も失われます。

5. ガスベースの緩和は、リエントラントガードや国家命令などの構造的安全策に代わるものではなく、補完するものであるべきです。

よくある質問

Q: ビューまたは純粋な関数で再入可能性は発生しますか? A: いいえ。これらの関数は状態変更操作や外部呼び出しを実行できないため、再帰的な干渉の可能性が排除されます。

Q: delegatecall を使用すると再入はできなくなりますか? A: 本質的にはそうではありません。 delegatecall は呼び出し元のストレージ コンテキストを保持しますが、ターゲット ロジックに保護されていない外部対話が含まれている場合、再入可能パターンはブロックされません。

Q: Payable フォールバック機能は常に危険ですか? A: 再入保護なしで状態の更新または外部呼び出しを実行する場合のみ。副作用なしで ETH を受け入れる最小限のフォールバックでは、無視できるリスクが生じます。

Q: アップグレード可能なプロキシ パターンは再入可能性を高めますか? A: はい。実装契約に適切な保護がなく、プロキシが検証なしで呼び出しを転送する場合、攻撃者はプロキシ ロジックとビジネス ロジックの両方を同時に悪用する可能性があります。