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

「また再入攻撃か」と言わせない。スマートコントラクトを鉄壁にするための防衛術

現場の最前線でインシデント対応をしていると、驚くほど同じ過ちが繰り返されていることに気づかされます。「再入攻撃（Reentrancy）」――ブロックチェーン界隈における、いわば古典にして最強の資金流出バグです。

「外部コントラクトへ送金する前に状態を更新する」。教科書にはそう書いてありますが、なぜこれほどまでに被害が絶えないのか。それは、エンジニアが「論理」ではなく「直感」でコードを書いているからです。今日は、この泥沼から抜け出し、二度と再入攻撃を許さないための「防衛の思考法」を伝授します。

—

なぜ「外部呼び出し」が危険なのか

再入攻撃の正体は、言ってみれば「手続きの割り込み」です。銀行のATMで残高が引き落とされる前に、通信ラグを突いて何度も「引き出し」ボタンを連打するようなものです。

スマートコントラクトにおいては、外部コントラクト（call）を呼び出した瞬間、制御権が相手側に移ります。相手が悪意あるコントラクトであれば、送金処理が終わる前に、自身の関数を再帰的に呼び出し、残高が減る前に何度も送金要求を繰り返してきます。

攻撃者の視点：PoCのイメージ

攻撃者は以下のような「罠」を仕掛けます。

// 攻撃者のコントラクトイメージ
function attack() external {
    target.withdraw(); // ターゲットの引き出し関数を叩く
}

// target.withdraw()が送金時に実行するfallback関数
fallback() external payable {
    if (address(target).balance >= amount) {
        target.withdraw(); // 再帰的に引き出しを呼び出し続ける（残高が枯渇するまで）
    }
}

—

防御の鉄則：Checks-Effects-Interactions (CEI)

「送金した後に残高を引けばいいや」という安易な実装は即刻廃止してください。必ず以下の順序を死守します。

1. Checks（確認）: 残高は十分か？不正な呼び出しではないか？（Require文）
2. Effects（更新）: 自分の状態（残高）を先に書き換える。
3. Interactions（相互作用）: その後に外部呼び出し（送金）を行う。

セキュアな実装例（Solidity）

これをコードで体現すると以下のようになります。

// 正しい実装例：CEIパターン
function withdraw(uint256 _amount) public {
    // 1. Checks: まず条件を確認
    require(balances[msg.sender] >= _amount, "残高不足");

    // 2. Effects: 先に状態を更新（これぞ鉄則）
    balances[msg.sender] -= _amount;

    // 3. Interactions: 最後に外部呼び出しを行う
    (bool success, ) = msg.sender.call{value: _amount}("");
    require(success, "送金失敗");
}

—

最後の砦：ReentrancyGuard（Mutex）の活用

CEIパターンは強力ですが、複雑なロジックになると見落としが発生します。そこで、プロの現場では OpenZeppelin の ReentrancyGuard を必ず導入します。これは、関数に「実行中はロックする」というフラグを立てる仕組み（Mutex）です。

実装サンプル

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

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

    // nonReentrant修飾子をつけるだけで、実行中の二重呼び出しをブロックできる
    function withdraw(uint256 _amount) external nonReentrant {
        require(balances[msg.sender] >= _amount, "残高不足");

        uint256 amount = balances[msg.sender];
        balances[msg.sender] = 0; // Effects

        (bool success, ) = msg.sender.call{value: amount}(""); // Interactions
        require(success, "送金失敗");
    }
}

—

Web3インフラの盲点：Nginxやクラウドでの防御は？

スマートコントラクトの脆弱性はオフチェーンのWAFでは防げません。しかし、Web3アプリ（DApp）のフロントエンドやバックエンドAPIを守ることは可能です。

もし、あなたがAPI経由でコントラクトを操作するシステムを構築しているなら、Nginxの設定で「同じIPからの短時間のリクエスト」を厳格に制限してください。

# /etc/nginx/conf.d/limit_rate.conf
# APIエンドポイントへの連続攻撃をレートリミットで物理的に遮断する
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; # 1秒1回、バースト5回まで
        proxy_pass http://backend_cluster;
    }
}

最後に：セキュリティは「疑うこと」から始まる

「自分のコードは大丈夫だ」という思い込みが、一番の脆弱性です。再入攻撃を防ぐためのチェックリストは、以下の3点に集約されます。

状態変更は常に外部呼び出しの前に行うこと。
外部呼び出しの結果（bool success）を必ず確認し、失敗時はロールバックすること。
再入の可能性がある関数には、迷わず nonReentrant 修飾子をつけること。

コードを書く際、常に「もしこの行の実行中に相手が割り込んできたらどうなるか？」を自問自答してください。その泥臭い執念こそが、顧客の資産を守る唯一の手段です。さあ、今すぐコードベースの withdraw 関数を総点検しましょう。