【実務・中級編】再入攻撃(Reentrancy)の高度な検知とガードの実装 – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

再入攻撃(Reentrancy)の深淵：スマートコントラクトを「止める」のではなく「壊させない」ための防衛術

やあ。今日も脆弱なコードの残骸を整理しているのか？

SCADAやIoTの現場で、PLC（プログラマブルロジックコントローラ）のメモリを直接いじくり回す攻撃者を見てきた経験から言わせてもらうが、Web3の世界も本質は変わらない。「状態（State）を書き換える前に、外部の予期せぬ挙動を信じるな」。これがセキュリティの鉄則だ。

今日は、スマートコントラクト、特にEVM系で最も古典的かつ致命的な「再入攻撃（Reentrancy）」について、教科書的な説明はすっ飛ばして、現場で使える「泥臭い防衛戦術」を叩き込む。

—

1. なぜ「Checks-Effects-Interactions」が最強の盾なのか

再入攻撃の正体は、外部コントラクトへの呼び出し（Interaction）が完了する前に、攻撃者が再び自身の関数を呼び出し、まだ更新されていない「古い状態」を悪用することだ。

最も効果的な防衛は、複雑なガードよりも先に「Checks-Effects-Interactions」という設計思想を体に染み込ませることだ。

Checks: 入力値の検証と権限チェック（require文など）
Effects: 内部状態の変更（残高の減算など）
Interactions: 外部への送金や呼び出し

この順番を一つでも入れ替えれば、脆弱性が生まれる。Interaction（外部への送金）がEffects（残高の減算）よりも先に行われるコードは、攻撃者にとっての「金塊が詰まったATM」でしかない。

—

2. 実践的なガード実装：ReentrancyGuardの真実

OpenZeppelin等のライブラリにある nonReentrant 修飾子を使うのが現代の標準だが、中身を理解せずに使っていては、OT分野のエンジニアとしては失格だ。

不完全な実装（脆弱な例）

// 警告：これは脆弱なコードの例だ。決して真似をするな。
function withdraw(uint256 amount) public {
    require(balances[msg.sender] >= amount);
    
    // 外部呼び出しが先にあるため、再入攻撃が可能
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);

    // 状態更新が後回しにされている
    balances[msg.sender] -= amount; 
}

セキュアな実装（推奨パターン）

ReentrancyGuard は、実行中にフラグを立てて、関数が終了するまで再入を弾く「ロック」の仕組みだ。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

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

contract SecureVault is ReentrancyGuard {
    mapping(address => uint256) public balances;

    // nonReentrant 修飾子を付与することで、関数実行中の再入を防止
    function withdraw(uint256 amount) external nonReentrant {
        // 1. Checks: 検証
        require(balances[msg.sender] >= amount, "Insufficient balance");

        // 2. Effects: 状態更新を先に行う
        balances[msg.sender] -= amount;

        // 3. Interactions: 外部呼び出しは最後
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
    }
}

—

3. なぜ「クロス関数再入」に注意が必要か

多くのエンジニアが犯すミスは、nonReentrant を特定の関数にしか付けていないことだ。しかし、攻撃者は「別の関数」を介して再入を試みる。

例えば、withdraw() にはロックをかけても、同じ状態変数 balances を操作する transfer() や deposit() にロックがかかっていない場合、そこをフックされる。

現場のTips:

状態変数を共有するすべての関数に一貫してロックをかけること。
複雑なコントラクトであれば、状態変数のアクセスを限定した「アクセサ」を作り、そこで排他制御を行う設計を検討せよ。

—

4. 運用サイドからの視点：WAFとオフチェーンの防衛

スマートコントラクト外の話だが、Webアプリからコントラクトを叩くフロントエンドやバックエンド（Node.js/Python）も狙われる。

Node.js (ethers.js) でのトランザクション管理

バックエンドからコントラクトを操作する際、APIキーの漏洩以上に恐ろしいのは、非同期処理の競合だ。

// 非同期処理での連続実行を防ぐための簡易ロック
let isProcessing = false;

async function secureWithdraw(amount) {
    if (isProcessing) throw new Error("処理が進行中です");
    
    isProcessing = true;
    try {
        const tx = await contract.withdraw(amount);
        await tx.wait(); // トランザクション完了を待つ
    } finally {
        isProcessing = false;
    }
}

インフラ層（Nginx/WAF）の備え

もし君たちがWeb API経由でコントラクトを操作するDAppを運用しているなら、Nginx でリクエストのレートリミットを厳格にかけろ。

# Nginx設定例：短時間での連続リクエストを制限し、ボットによる攻撃を緩和
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=1r/s;

server {
    location /api/v1/withdraw {
        limit_req zone=api_limit burst=5 nodelay;
        # ... 後続の処理
    }
}

—

最後に：セキュリティとは「疑い続ける」こと

再入攻撃は、EVMの仕様を逆手に取った「仕様上のバグ」だ。どんなに優れたガードを実装しても、コードの複雑性が増せば、必ずどこかに綻びが出る。

一番の防御策は、「コードを極限までシンプルに保つこと」。複雑な機能が必要なら、それをコントラクトではなく、オフチェーンの演算で解決できないか常に疑え。

現場で何か困ったことがあれば、いつでも相談してくれ。だが、まずは目の前のその require 文が適切な場所にあるか、もう一度確認してからプルリクを出すように。健闘を祈る。