【実務・中級編】再入攻撃(Reentrancy Attack)のメカニズムと防御策 – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

制御システムとWeb3の境界線：再入攻撃（Reentrancy）を完封する「実戦的思考法」

現場でインシデント対応をしていると、脆弱性の本質が「技術的な欠陥」というより「設計者の慢心」にあることに気づかされます。特にスマートコントラクトにおける「再入攻撃（Reentrancy Attack）」は、DAOハックの時代から現代まで、形を変えて数多のプロジェクトを破綻させてきました。

IoTやSCADAのバックエンドでWeb3技術が統合される今、この脆弱性を理解することはもはや「Web3エンジニアの教養」ではなく、「システムを守るエンジニアの生存条件」です。

—

1. 再入攻撃の「解剖学」：なぜシステムは欺かれるのか

再入攻撃の根幹は、「処理の順序」に対する勘違いにあります。外部コントラクトやAPIへのコールバックが発生した際、「自らの状態（残高など）が更新される前に、相手に制御権を渡してしまう」こと、これが全ての元凶です。

攻撃者は、コントラクトが残高を減算処理する前に、意図的に別の関数を呼び出し、再帰的に資金を引き出し続けます。これはSCADAの制御ロジックでいえば、「センサー値が正常範囲に戻ったと判断する前に、異常検知のトリガーを二重に引かせる」ようなものです。

攻撃のロジック（PoCの概念）

もしあなたが決済処理を実装する際、以下のようなコードを書いていたら、即座に修正が必要です。

// 危険な実装例（アンチパターン）
function withdraw() public {
    uint balance = userBalances[msg.sender];
    require(balance > 0);

    // 1. 外部呼び出し（ここで制御が攻撃者に移る）
    (bool success, ) = msg.sender.call{value: balance}("");
    require(success);

    // 2. 状態更新（攻撃者はこの前に再度withdrawを呼ぶ）
    userBalances[msg.sender] = 0; 
}

攻撃者のコントラクトが fallback() や receive() 関数内で再度 withdraw() を呼び出すと、状態が 0 になる前に次の引き出しが許可されてしまい、銀行の残高が物理的に存在しないはずの数字になるまで吸い取られます。

—

2. 鉄則：Checks-Effects-Interactions パターン

この脆弱性を叩き潰すための唯一無二の正解が「Checks-Effects-Interactions（CEI）」パターンです。

1. Checks (チェック): 要求条件（残高確認など）を検証する。
2. Effects (効果): 内部状態を先に更新する。
3. Interactions (相互作用): 最後に外部コントラクトと通信する。

この順序を守るだけで、たとえ再帰的に呼び出されても、すでに残高はゼロになっているため、攻撃は無効化されます。

// 安全な実装例
function withdraw() public {
    uint balance = userBalances[msg.sender];
    require(balance > 0); // 1. Checks

    userBalances[msg.sender] = 0; // 2. Effects (先に状態をクリア)

    (bool success, ) = msg.sender.call{value: balance}(""); // 3. Interactions
    require(success);
}

—

3. 「保険」としての ReentrancyGuard

エンジニアは往々にしてミスをする生き物です。だからこそ、OpenZeppelinが提供する ReentrancyGuard という「物理的な鍵」をかけておきましょう。これは関数呼び出しの最中にフラグを立て、再帰的なアクセスをハードウェアのインターロックのようにブロックします。

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SecureVault is ReentrancyGuard {
    // nonReentrant修飾子をつけるだけで、二重呼び出しを物理的に遮断
    function withdraw() public nonReentrant {
        uint balance = userBalances[msg.sender];
        require(balance > 0);
        
        userBalances[msg.sender] = 0;
        (bool success, ) = msg.sender.call{value: balance}("");
        require(success);
    }
}

—

4. Web3セキュリティの「盲点」を突く運用上の注意

スマートコントラクトだけでなく、Webバックエンド側でIoTデバイスやWeb3ウォレットと連携している場合、以下の設定も確認してください。

WAF / Nginx の設定ポイント

Web3 APIをラップするAPIゲートウェイがある場合、不自然な短期間でのリクエスト重複を検知し、レートリミットをかける設定が必要です。

# nginx.conf: APIの同時接続数を制限し、再入攻撃のような高速な連打を抑制
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;

server {
    location /api/v1/withdraw {
        limit_req zone=api_limit burst=10 nodelay; # 5回/秒以上の急激なアクセスを遮断
        proxy_pass http://backend_cluster;
    }
}

—

結びに代えて：セキュリティは「性悪説」で設計せよ

私がインシデント対応で現場に呼ばれるとき、その多くは「まさかこんな呼ばれ方をされるとは思わなかった」という開発者の声を聞きます。しかし、ハッカーは「想定外」を「想定内」にして攻めてきます。

状態更新は常に一番最初に行う。
外部からの入力やコールバックは、常に「悪意がある」と仮定する。
自動化されたガード（ReentrancyGuard等）を過信せず、ロジック自体を堅牢にする。

この3点を徹底するだけで、あなたのコードは格段に強固になります。技術は日々進化しますが、攻撃者の狙う「人間の綻び」はいつの時代も同じです。常に疑い、常に検証し、コードを磨き続けてください。それが、我々エンジニアに課せられた責務なのです。