リエントランシー攻撃

暗号資産におけるリエントランシー攻撃とは？

リエントランシー攻撃とは、最初の関数呼び出しが完了する前に、外部コントラクトが脆弱なコントラクトへコールバックするスマートコントラクトのエクスプロイトです。

暗号資産分野では、資金を保有するスマートコントラクト、残高を記録するコントラクト、出金処理や報酬計算を行うコントラクト、ボールトシェアを管理するコントラクト、他のコントラクトと連携するコントラクトが主な標的となります。

根本的な問題は、脆弱なコントラクトが内部状態の更新を終える前に、別のコントラクトへ制御を渡してしまうことです。

攻撃者がこの未完了の状態で再びコントラクトに入れると、本来1回しか許可されない操作を繰り返せる可能性があります。

よくある例は、ユーザーの記録残高を減らす前に、ユーザーへ暗号資産を送金する出金関数です。

受取先が悪意のあるコントラクトの場合、フォールバック処理やコールバック処理を使って、残高が更新される前に出金関数を再度呼び出すことができます。

その結果、攻撃者が受け取る権利のある額を超えて出金できる可能性があります。

OWASP Smart Contract Top 10 2026のリエントランシー解説では、コントラクトが外部呼び出しを行い、呼び出された側が状態の更新完了前に元のコントラクトへコールバックする状況として定義されています。

リエントランシーは、オンチェーン会計の信頼性を直接脅かすため、最もよく知られたスマートコントラクトの脆弱性の一つです。

DeFiでは、スマートコントラクトが大規模な流動性プールを管理し、スワップ、担保、報酬、価格データなどで他のコントラクトに依存することが多いため、特に危険です。

リエントランシー攻撃の仕組み

リエントランシー攻撃は、脆弱なスマートコントラクトが別のコントラクトやアドレスを外部呼び出しするところから始まります。

その外部呼び出しは、ネイティブ暗号資産の送金、トークンの移転、フックの呼び出し、コールバックの要求、戦略の実行、他のプロトコルとの連携などを伴う場合があります。

脆弱なコントラクトが呼び出しを行うと、受取側のコントラクトに一時的に自身のコードを実行する機会が与えられます。

受取側のコントラクトが攻撃者の管理下にある場合、攻撃者はその機会を利用して脆弱なコントラクトをコールバックできます。

脆弱なコントラクトは、残高、債務、シェア、報酬インデックス、ロックフラグを更新しておらず、古い状態値のままの可能性があります。

攻撃者はその古い値を悪用し、出金を繰り返したり、報酬を複数回請求したり、許可された額を超えて借り入れたり、計算を操作したりする可能性があります。

脆弱なコントラクトの資金が尽きるか、トランザクションのGasが不足するか、保護機能が反復呼び出しを止めるまで攻撃が続く場合があります。

外部呼び出しに関するSolidityのドキュメントは、別のコントラクトとの連携によって制御がそのコントラクトに渡り、最初の呼び出しが戻る前に元のコントラクトへコールバックされる可能性があると警告しています。

この警告は、リエントランシー対策の基本です。

外部呼び出しは、コントラクトの前提が崩される可能性のある箇所として扱う必要があります。

リエントランシーの簡単な例

各ユーザーの預入残高を記録する貸付コントラクトを想定してください。

ユーザーがコントラクトに10 ETHを預け入れます。

コントラクトは、そのユーザーの残高が10 ETHであると記録します。

後日、ユーザーが出金関数を呼び出し、10 ETHを受け取ります。

安全なコントラクトは、ETHを送る前にユーザーの残高をゼロにします。

脆弱なコントラクトは、先にETHを送り、その後に残高を更新します。

ユーザーが実際には悪意のあるコントラクトである場合、ETHの送金時に受取関数を実行できます。

その受取関数は、脆弱なコントラクトがまだユーザーの残高を10 ETHと認識している間に、直ちに再び出金関数を呼び出せます。

1回のトランザクション内で同じ出金を何度も実行できる場合があります。

このため、スマートコントラクトの処理順序は非常に重要です。

従来のソフトウェアでは、小さな順序の誤りが通常の会計ミスにつながる場合があります。

暗号資産を保有するスマートコントラクトでは、同じ順序の誤りが資産を直接盗み出す経路になる可能性があります。

リエントランシー攻撃が危険な理由

スマートコントラクトが、エクスプロイト後に回収しにくい資産を管理していることが多いため、リエントランシー攻撃は危険です。

パブリックブロックチェーンは、有効なトランザクションを実行し、その履歴を保持するよう設計されています。

悪意のあるトランザクションがブロックチェーンの規則に従いながらコントラクトの不具合を悪用した場合、被害を取り消すことは通常困難です。

Ethereum.orgのスマートコントラクトセキュリティガイドによると、デプロイ済みのスマートコントラクトのコードは通常変更が難しく、ブロックチェーンの不変性により盗まれた資産の回収も困難です。

そのため、事後の修復よりも予防がはるかに重要です。

リエントランシーの不具合は、流動性プール、ボールト、ブリッジ、ステーキングシステム、NFTマーケットプレイス、報酬コントラクト、貸付プロトコルから資金を流出させる可能性があります。

盗まれた資産を後から回収できた場合でも、ユーザーの信頼を損ねる可能性があります。

暗号資産において、スマートコントラクトのリスクは開発者だけの問題ではありません。

ユーザー、流動性、ガバナンス、評判に関する問題が同時に発生する可能性があります。

典型的なリエントランシー

典型的なリエントランシーでは、外部呼び出しを行った同じ関数に攻撃者が再び入ります。

最も一般的な例は、脆弱な出金関数です。

この関数はユーザーの残高を確認し、資金を送金してから残高を更新します。

攻撃者のコントラクトは資金を受け取り、残高が減る前に同じ出金関数を再度呼び出します。

こうして、同じ記録上の残高を複数回利用できるループが生じます。

典型的なリエントランシーは理解しやすいものですが、外部呼び出しを早い段階で行うコードを書く開発者がいるため、依然として危険です。

また、現代のコントラクトでは、単純な預入・出金の対応表より複雑な会計処理を行うことが多いため、注意が必要です。

脆弱な関数には、シェア、債務ポジション、報酬倍率、ボールト資産、流動性トークン、手数料計算が関わる場合があります。

典型例とは異なる形でも、根本的な問題が存在する可能性があります。

関数間リエントランシー

関数間リエントランシーとは、攻撃者が同じコントラクト内の別の関数に再び入る攻撃です。

攻撃対象の関数を単独で確認すると安全に見える場合があるため、典型的なリエントランシーより発見が難しくなります。

たとえば、ある関数が出金を開始し、外部呼び出しを行うとします。

その外部呼び出しの間に、攻撃者が同じ残高、シェア、権限の状態に依存する別の関数を呼び出す場合があります。

最初の関数が状態の更新を完了していなければ、2つ目の関数は古い情報を参照する可能性があります。

その結果、最初の操作が完了する前に、攻撃者が報酬を請求したり、シェアを移転したり、資産を借り入れたり、ポジションを変更したりできる場合があります。

関数間リエントランシーは、開発者が明らかな出金関数だけでなく、コントラクト全体の不変条件を考える必要があることを示しています。

コントラクトの不変条件とは、有効な操作の前後で常に成立していなければならないルールです。

外部呼び出しによって不変条件が一時的に崩れる場合、他の関数が攻撃経路になる可能性があります。

コントラクト間リエントランシー

コントラクト間リエントランシーでは、コールバックの経路が複数のコントラクトを通過します。

ボールト、戦略、ルーター、トークンコントラクト、オラクル読み取り機能、ステーキングモジュール、報酬配布者が相互に連携するDeFiシステムで発生する場合があります。

ボールトが戦略を呼び出すことがあります。

戦略がトークンや別のプロトコルを呼び出すこともあります。

呼び出されたコントラクトがコールバックを発生させ、ボールトや、ボールトが依存する関連コントラクトへ処理を戻す場合があります。

脆弱な状態は、最初に外部呼び出しを行ったコントラクトと同じ場所にあるとは限りません。

Solidityのセキュリティに関する考慮事項では、リエントランシーはEtherの送金だけで発生するものではなく、複数のコントラクトにまたがる状況も考慮する必要があるとされています。

これは、現代の暗号資産アプリケーションが高いコンポーザビリティを持つため重要です。

コンポーザビリティによってプロトコル同士を連携させ、組み合わせて構築できますが、予期しないコールバックの経路も増えます。

読み取り専用リエントランシー

読み取り専用リエントランシーとは、未完了の状態遷移中に、view関数や読み取り関数が誤解を招く情報を返す攻撃です。

view関数は状態を直接変更しないため、一見すると無害に思えるかもしれません。

しかし、他のコントラクトがview関数を使い、価格、シェア、担保価値、為替レート、報酬額を計算する場合があります。

あるコントラクトが中間状態にあるときにコールバックが発生すると、view関数が信頼すべきでない一時的な値を返す可能性があります。

攻撃者は、その一時的な値に依存する別のコントラクトで値を悪用する場合があります。

これにより、通常の出金関数を直接利用して最初のコントラクトから資金を流出させなくても、オラクルに類する操作や会計ミスが生じる可能性があります。

読み取り専用リエントランシーは、関数がストレージに書き込むかどうかだけがセキュリティ上の論点ではないことを示しています。

他のコントラクトが未完了の状態を観察し、その情報に基づいて金融上の判断を行えるかどうかも重要です。

フックを利用したリエントランシー

フックを利用したリエントランシーとは、トークン規格やプロトコルのインターフェースが、移転や処理の間に受取側のロジックを意図的に呼び出すことで発生する攻撃です。

一部のトークン規格やNFT規格には、コントラクトが資産を受け取った際に処理を実行できる受取フックが含まれています。

フラッシュローンのシステムもコールバックを使用し、借り手が1回のトランザクション内で借りた流動性を使い、返済できるようにします。

こうしたフックは便利ですが、コールバックの機会も生み出します。

トークン移転は外部コードの実行を伴わない単純な処理だとコントラクトが想定している場合、その前提は誤りかもしれません。

トークン規格や実装によっては、移転時に受取側のロジック、オペレーターフック、その他のコントラクト処理が実行される場合があります。

開発者は、あらゆる外部トークン処理をリエントランシーが発生し得る箇所として確認してください。

多くのトークン、多数のボールト資産、複数の外部連携に対応するコントラクトでは、特に重要です。

リエントランシー攻撃の主な標的

出金関数は、コントラクト外へ資金を送ることが多いため、最も一般的な標的です。

ボールトの入金・出金関数も、シェア残高や資産会計を更新するため、よく標的になります。

貸付プロトコルは、担保、債務、利息、強制決済のしきい値、借入残高を管理するため、標的となる場合があります。

ステーキングコントラクトは、時間に応じて報酬を計算し、請求時に報酬トークンを移転する場合があるため、標的となる可能性があります。

NFTマーケットプレイスは、購入や支払いによってトークンの受取フックや外部のロイヤリティ処理が実行されることがあるため、標的となる場合があります。

ブリッジコントラクトは、クロスチェーンメッセージ、資産のロック、解放処理を管理するため、標的となることがあります。

ガバナンスの実行コントラクトは、提案の実行中に外部コントラクトを呼び出すため、標的となる場合があります。

フラッシュローンの借り手・提供者は、設計上コールバックに依存するため、標的となる可能性があります。

内部会計を完了する前に価値を送ったり、信頼できないコードを呼び出したりするスマートコントラクトはすべて、リエントランシー攻撃の標的となり得るものとして扱ってください。

Checks-Effects-Interactionsパターン

Checks-Effects-Interactionsパターンは、リエントランシー攻撃に対する最も重要な防御策の一つです。

Checks（確認）では、まずユーザーがその操作を実行する権限を持つか確認します。

Effects（状態更新）では、外部呼び出しの前にコントラクト内部の状態を更新します。

Interactions（外部との連携）では、確認と状態更新の完了後にのみ外部呼び出しを行います。

出金関数の場合、ユーザーの残高を確認し、残高を減らしてから資金を送る必要があります。

こうすれば、受取側が再入しようとしても、コントラクトの残高はすでに更新されています。

SolidityのChecks-Effects-Interactionsに関するドキュメントでは、このパターンはリエントランシー攻撃を防ぐ一般的な方法として紹介されています。

このパターンはシンプルですが、信頼できない外部コードと連携するコントラクトでは不可欠です。

状態を変更してからコントラクト外部を呼び出す関数では、常に適用する習慣を身につけてください。

リエントランシーガード

リエントランシーガードとは、最初の呼び出しが完了する前に、保護された関数へ再度入ることを防ぐロックです。

Solidityのコントラクトでは、実行中の関数を実行中と示すステータス変数を使って実装されることがよくあります。

再入呼び出しが同じ保護対象の経路に入ろうとすると、ガードがその呼び出しを拒否します。

OpenZeppelin Contracts 5.xのReentrancyGuardドキュメントでは、ReentrancyGuardは、ネストしたリエントランシー呼び出しを防ぐnonReentrant修飾子を提供するモジュールとして説明されています。

リエントランシーガードは、高リスクの関数に明確な保護層を追加できるため有用です。

ただし、ガードは適切な会計処理の代わりにはなりません。

開発者はChecks-Effects-Interactionsを適用し、すべての外部呼び出しを確認する必要があります。

OpenZeppelinは、nonReentrantガードが1つであるため、nonReentrantが付いた関数同士は直接呼び出せないとも説明しています。

一般的な回避策は、内部ロジックをprivateにし、nonReentrantで保護された別々の外部エントリーポイントを用意することです。

一時ストレージとリエントランシーロック

一時ストレージは、1回のトランザクション中だけ保持される一時的な値に使用できる、新しいEVM機能です。

呼び出しの終了後にロックを永続ストレージに残す必要がない場合があるため、リエントランシーロックに役立ちます。

OpenZeppelinのReentrancyGuardTransientドキュメントでは、EIP-1153に対応したチェーン向けに、一時ストレージを利用するReentrancyGuardのバリエーションが説明されています。

Solidityの一時ストレージに関するドキュメントによると、コールフレームの終了時にクリアされるリエントランシーロックに一時ストレージを使うことは安全です。

だからといって、すべてのコントラクトで一時ストレージを自動的に使うべきというわけではありません。

開発者は、対象チェーンが必要な機能に対応していること、ロックが正しく解除されることを確認する必要があります。

ロックの管理が不適切だと、コンポーザビリティが損なわれたり、複雑なトランザクションでコントラクトを使いにくくしたりする可能性があります。

最適な選択は、対象ブロックチェーン、コンパイラのバージョン、ライブラリのバージョン、アップグレード方式、監査要件によって異なります。

TransferやSendだけでは十分な防御にならない理由

Solidityの古いガイダンスでは、Gasに上限のある送金をリエントランシー対策として実用的な方法と見なすことがよくありました。

GasコストやEVMの挙動は時間とともに変化する可能性があるため、現在のガイダンスはより慎重です。

Solidityのaddressメンバーに関するドキュメントは、sendとtransferは非推奨であり、リエントランシー対策には別の方法を推奨すると警告しています。

Gas上限だけに依存すると、誤った安心感につながるおそれがあるため、重要な点です。

受取側に危険な処理を行うだけのGasがないと想定するのではなく、状態処理が正しいことによってコントラクトを安全にする必要があります。

より安全な方法は、外部呼び出しの前に状態を更新し、必要に応じてリエントランシーガードを使い、戻り値を確認し、出金処理を慎重に設計することです。

リエントランシーに対する主な防御策として、transferやsendに依存している古いコードも見直してください。

プロトコル規則、Gasコスト、一般的な攻撃手法の変化に伴い、暗号資産のセキュリティ対策も変わります。

防御策としてのPull Payment

Pull Paymentパターンでは、別の処理中にコントラクトが資金を送るのではなく、受取人自身が資金を引き出します。

コントラクトが支払予定額を記録し、受取人が別の手順で請求できるため、リスクの軽減につながります。

たとえばマーケットプレイスは、購入者の購入トランザクション内で販売者に直接資金を送る代わりに、販売代金を記録できます。

その後、販売者が出金関数を呼び出して資金を受け取ります。

このパターンにより、支払いを拒否したり、支払時に再入を試みたりする悪意のある受取人による被害を抑えられる場合があります。

OpenZeppelinのセキュリティユーティリティに関するドキュメントでは、PullPaymentはリエントランシー攻撃の回避に役立つパターンとして説明されています。

ユーザーに追加の手順が必要となる場合があるため、Pull Paymentがすべての設計に適しているとは限りません。

ただし、同じシステムから多くのユーザーやコントラクトに支払う場合には非常に有用です。

緊急停止機能

緊急停止機能を使うと、認可されたアカウントやガバナンスシステムが、インシデント発生時に重要な関数を停止できます。

不審な挙動やリエントランシー攻撃の可能性が検知された場合、被害の拡大を抑える助けとなります。

調査中に、出金、入金、報酬請求、新規借入、その他のリスクを伴う操作を停止する場合があります。

OpenZeppelinは、修正対応中に機能を停止する一般的な緊急対応手段としてPausableを挙げています。

停止システムは、ガバナンスや中央集権性とのトレードオフが生じるため、慎重に設計する必要があります。

停止権限が強すぎると、ユーザーは検閲や権限の悪用を懸念する可能性があります。

停止権限が弱すぎたり対応が遅すぎたりすると、攻撃が進行中の際に役立たない場合があります。

価値の大きい暗号資産プロトコルでは、緊急対応計画をセキュリティ設計の初期段階から組み込む必要があります。

開発者がリエントランシーリスクを検出する方法

コントラクト内のあらゆる外部呼び出しを確認することで、開発者はリエントランシーリスクを検出できます。

外部呼び出しには、ネイティブコインの送金、トークン移転、低レベル呼び出し、インターフェース呼び出し、フラッシュローンのコールバック、NFT受取フック、プロトコルモジュールへの呼び出しが含まれます。

各外部呼び出しについて、内部状態がすでに更新されているか確認してください。

外部呼び出し中に別の関数が呼び出され、古い状態を参照できるかも確認してください。

複数のコントラクトが共有する前提が、コールバックによって崩れる可能性がないか確認してください。

悪意のある受取コントラクトを使い、すべてのpublic関数やexternal関数へのコールバックを試してください。

静的解析、ファジングテスト、ユニットテスト、不変条件テスト、手動レビューを組み合わせてください。

Solidity SMTCheckerのドキュメントでは、不明なコードへの外部呼び出しに関連して分析できる動作の一つとして、リエントランシー特性が挙げられています。

単一のツールだけで、コントラクトの安全性を保証することはできません。

自動化ツールと経験豊富なセキュリティレビューを組み合わせることで、リエントランシーを最も効果的に検出できます。

ユーザーがリエントランシーリスクを考える際のポイント

ほとんどのユーザーは、スマートコントラクトを利用する前に完全な監査を行うことはできません。

それでも、強固なセキュリティ対策の兆候を確認することで、リスクを減らすことは可能です。

プロトコルは、監査、バグ報奨金プログラム、緊急管理機能、アップグレード権限、リスク開示について、明確な文書を公開する必要があります。

公開レビューがほとんどない一方で、多額の価値を保有する新しいコントラクトには注意してください。

収益の源やスマートコントラクトリスクを説明せずに、通常より著しく高い利回りを提示するプロトコルにも注意が必要です。

ユーザーインターフェースが洗練され、専門的に見えても、リエントランシーリスクが存在する可能性があります。

優れたインターフェースがあっても、基盤となるコントラクトのロジックが安全であるとは限りません。

監査を受けていないコントラクトや実験段階のコントラクトに、失ってもよい範囲を超える資金を預けないでください。

監査によってリスクは低減されますが、完全になくなるわけではないことも理解してください。

リエントランシーとDeFiのコンポーザビリティ

DeFiのコンポーザビリティとは、スマートコントラクトを金融上の部品のように相互接続できることです。

ウォレット、ボールト、貸付市場、スワップ、デリバティブ、ステーキングシステム、ガバナンスツールが連携できるため、暗号資産の強力な特徴の一つです。

しかし、1回のトランザクションが多くのコントラクトを通過する可能性があるため、コンポーザビリティはリエントランシーリスクも高めます。

あるコントラクトでは安全に見える操作が、別のコントラクトで複雑な処理を引き起こす場合があります。

コールバックが3つ目のコントラクトに到達し、最初のコントラクトが依存する値を変更することもあります。

価格、シェア価値、残高が、外部から参照されることを想定していない一時的な状態で読み取られる可能性があります。

このため、現代のリエントランシー分析では、連携経路全体を考慮する必要があります。

開発者は、各コントラクトを単独で存在するものとして審査すべきではありません。

ルーター、トークン、ボールト、フラッシュローン、外部戦略と組み合わせたときのコントラクトの動作を確認してください。

リエントランシーとフラッシュローン

フラッシュローンを利用すると、攻撃者は1回のトランザクション内で多額の一時的な流動性を確保できるため、リエントランシー攻撃の威力が増す可能性があります。

フラッシュローン自体はリエントランシー攻撃ではありません。

正当なアービトラージ、借り換え、強制決済、資本効率を高める操作にも使われます。

しかし、1回のトランザクション内で脆弱なコントラクトを操作できる場合、フラッシュローンによって攻撃を利益につなげるための十分な資金を得られる可能性があります。

コールバック型のシステムでは、意図的に別のコントラクトへ制御を渡すため、フラッシュローンのコールバックも慎重に設計する必要があります。

強い理由がない限り、あらゆるコールバックを信頼できない外部呼び出しとして扱ってください。

可能な場合はコールバック前に状態を更新し、コールバックから戻った後に最終返済、残高、不変条件を確認してください。

フラッシュローンの連携機能は、通常の借り手の例だけでなく、悪意のある借り手コントラクトでもテストしてください。

リエントランシーとアップグレード可能なコントラクト

アップグレード可能なコントラクトでは、リエントランシー対策に特別な注意が必要です。

アップグレード可能なプロキシでは、ユーザー向けのストレージと実装ロジックが分離されています。

リエントランシーガードがストレージを使う場合、ストレージレイアウトが正しく、アップグレード間で互換性があることを確認する必要があります。

ストレージレイアウトを誤って変更すると、ガードが機能しなくなったり、重要な状態変数が破損したりする可能性があります。

アップグレード可能なコントラクトを構築する際は、アップグレード対応のライブラリを使用してください。

新規デプロイだけでなく、過去のコントラクト状態を使ってアップグレードをテストしてください。

バージョン1では安全なコントラクトでも、後のアップグレードで呼び出し順序が変更されたり、新たな外部連携が追加されたりすると、脆弱になる場合があります。

アップグレード審査では、新たな外部呼び出しをすべてリエントランシーの観点から分析してください。

大きな価値を保有するプロトコルでは、アップグレードを実行するガバナンスや管理者のシステムにも、遅延、審査、緊急管理機能を設ける必要があります。

リエントランシー攻撃を防ぐベストプラクティス

外部呼び出しを行う前に、内部状態を更新します。

出金、請求、移転、スワップ、会計上の変更には、Checks-Effects-Interactionsパターンを適用します。

高リスクの外部エントリーポイントには、リエントランシーガードを適用します。

一部のトークン規格や実装ではフックやコールバックが実行される可能性があるため、トークン移転が常に単純な処理だと想定しないでください。

リエントランシー対策として、transferやsendのGas上限だけに依存しないでください。

直接支払いが不要なリスクを生む場合は、Pull Paymentパターンを使用します。

同じ関数内の典型的なリエントランシーだけでなく、関数間・コントラクト間のリエントランシーも確認します。

外部呼び出しのたびに再入を試みる悪意のある受取コントラクトを使ってテストします。

複雑な連携でも残高、シェア、債務、準備金の合計が正しく保たれることを、不変条件テストで確認します。

価値の大きいシステムには、緊急停止機能とインシデント対応計画を組み込みます。

ユーザー資金を保有するコントラクトをデプロイする前に、独立したセキュリティ審査を受けます。

依存関係を最新の状態に保ち、メジャーバージョンを変更する前にライブラリの移行に関する注意事項を確認します。

開発者によくある誤り

よくある誤りの一つは、資金を送金した後に残高を更新することです。

別のよくある誤りは、出金関数だけを保護し、関数間リエントランシーの対象となる関連関数を保護しないことです。

トークン移転で外部コードが実行されることはないと思い込むのも、よくある誤りです。

別のコントラクトで1つのリエントランシーガードを使いながら、会計上の前提を共有する関連コントラクトへの呼び出しを無視することも、よくある誤りです。

状態ロジックを適切に設計せず、古いtransferやsendの前提に依存することも誤りです。

アップグレード中に新たな外部連携を追加し、呼び出し経路全体を再確認しないことも、よくある誤りです。

複雑なトランザクション中に他のコントラクトが参照する場合でも、view関数を無害だと見なすことは誤りです。

悪意のあるコントラクトが、通常のユーザーとは意図的に異なる動作をする可能性を忘れることも誤りです。

セキュリティテストでは、通常のインターフェース利用だけでなく、敵対的な動作を想定してください。

FAQ

リエントランシー攻撃とは何ですか？

リエントランシー攻撃とは、最初の関数呼び出しが完了して状態が安全に更新される前に、悪意のあるコントラクトが脆弱なスマートコントラクトへコールバックする攻撃です。

暗号資産分野でリエントランシーが危険なのはなぜですか？

1回のトランザクション内で、資金の流出、報酬の複数回請求、会計の操作、コントラクトの前提の破壊につながる可能性があるためです。

リエントランシーはETHの送金に限られますか？

いいえ。Solidityのドキュメントでは、外部コントラクト呼び出しはどれもコールバックのリスクを生み得るため、リエントランシーはEtherの送金だけに関係するものではないと警告しています。

よく知られているリエントランシー対策は何ですか？

Checks-Effects-Interactionsパターンは、外部呼び出しの前にコントラクトの状態を更新するため、よく知られた対策の一つです。

ReentrancyGuardとは何ですか？

ReentrancyGuardは、nonReentrant修飾子を提供し、保護対象の関数へのネストした呼び出しを防ぐスマートコントラクト用ユーティリティです。

ReentrancyGuardですべてのリエントランシーの不具合を防げますか？

いいえ。ReentrancyGuardは特定のエントリーポイントを保護する助けとなりますが、開発者は適切な会計処理、安全な呼び出し順序、コントラクト間の審査も行う必要があります。

関数間リエントランシーとは何ですか？

関数間リエントランシーとは、最初の関数が未完了の間に、攻撃者が同じコントラクト内の別の関数へ再入することです。

読み取り専用リエントランシーとは何ですか？

読み取り専用リエントランシーとは、処理が未完了の間にview関数が誤解を招く一時的な状態を返し、別のコントラクトがその値に依存する攻撃です。

トークン移転がリエントランシーを引き起こすことはありますか？

はい。一部のトークン規格や実装ではフックやコールバックが実行される場合があるため、トークン移転も外部呼び出しの可能性がある処理として確認してください。

ユーザーはリエントランシーを理由にすべてのスマートコントラクトを避けるべきですか？

いいえ。すべてのスマートコントラクトを避ける必要はありませんが、強固な監査、明確な文書、継続的な監視、責任あるリスク管理を備えたプロトコルを選ぶべきです。

まとめ

リエントランシー攻撃とは、外部呼び出し中の未完了の状態を悪用するスマートコントラクトのエクスプロイトです。

攻撃者は最初の呼び出しが完了する前に脆弱なコントラクトへ再入し、古い会計情報を利用して許可された額を超える価値を得ます。

典型例は出金の繰り返しですが、現代のリエントランシーには関数間呼び出し、コントラクト間の処理、読み取り専用の状態、トークンフック、フラッシュローンのコールバック、DeFiのコンポーザビリティも関係します。

最も重要な教訓は、外部呼び出しのたびに、信頼できないコードへ制御が渡る可能性があると考えることです。

開発者は、Checks-Effects-Interactionsの適用、リエントランシーガードの利用、安全でない支払いパターンの回避、悪意のあるコールバックのテスト、コントラクト間の連携経路全体の審査によって、リエントランシーリスクを低減できます。

ユーザーは、スマートコントラクトのセキュリティを重視するプロトコルを選び、多額の価値を保有する未監査のシステムを避けることで、リスクへのエクスポージャーを抑えられます。

小さな処理順序の誤りが深刻な金融エクスプロイトにつながる可能性があるため、リエントランシーは暗号資産セキュリティにおける重要な概念です。

リエントランシーについて理解することは、開発者がより安全なコントラクトを構築し、ユーザーがスマートコントラクト監査、セキュリティパターン、リスク管理の重要性を理解する助けとなります。