再入攻撃の「現在地」：単一関数からマルチコントラクトの死角を突く深淵
現場でコードをレビューしていると、いまだに「Checks-Effects-Interactions（CEI）パターンを守っています」と胸を張るエンジニアに出会う。だが、今の攻撃者はそんな教科書通りの罠にはかからない。
彼らが狙うのは、単一関数のロジックの欠陥ではない。「複数のコントラクトが共有する状態の不整合」という、いわばシステムのコンテキストスイッチの隙間だ。今回は、再入攻撃（Reentrancy）の高度な変種と、実戦で使える防御術を叩き込む。
—
1. なぜ「単一関数」の対策だけでは不十分なのか
従来の再入攻撃は、external callの直後に状態更新を行うコードが標的だった。しかし、現代の複雑なDeFiプロトコルやIoTゲートウェイ連携では、複数のコントラクトが複雑な依存関係で結ばれている。
攻撃者は、関数Aから関数Bを呼び出し、その途中で別のコントラクトCを介して状態を書き換え、関数Aに戻ってきた際に「前提条件が変わっていること」を悪用する。これが「クロスコントラクト再入（Cross-Contract Reentrancy）」だ。
単純に「再入防止（Mutex/ReentrancyGuard）」をかけただけでは、別コントラクトから呼び出された際にそのGuardが効かないという事態に陥る。
—
2. 脆弱な実装と攻撃のシナリオ
以下のコードを見てほしい。一見、セキュアに見えるかもしれないが、vaultコントラクトとtokenコントラクトが状態を共有している場合、致命的な欠陥がある。
// 脆弱なコントラクト例
function withdraw(uint256 _amount) public {
require(balances[msg.sender] >= _amount);
// 外部コントラクトへの転送
(bool success, ) = msg.sender.call{value: _amount}("");
require(success);
// 転送後に残高を更新（ダメ、絶対）
balances[msg.sender] -= _amount;
}この実装で何が起きるか。攻撃者はfallback関数を悪用して、withdrawが完了する前に再帰的にwithdrawを呼び出す。これが再入の基本だ。では、これを「マルチコントラクト」でやられたらどうなるか。
—
3. 実践的防御：コピペで使える「セキュアな設計」
防御の鉄則は、「状態を更新してから呼び出す」だけでなく、「呼び出し元が信頼できない場合、ローカル変数で状態を完結させる」ことだ。
Solidityでの推奨実装（OpenZeppelin ReentrancyGuardの利用）
自力でフラグを管理するのはバグの元だ。信頼できるライブラリを使いつつ、ロジックを再設計する。
// 堅牢な実装例
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
contract SecureVault is ReentrancyGuard {
mapping(address => uint256) public balances;
// 非再入可能修飾子を使用
function withdraw(uint256 _amount) public nonReentrant {
uint256 balance = balances[msg.sender];
require(balance >= _amount, "残高不足");
// 1. Effects: 外部呼び出しの前に状態を更新（重要！）
balances[msg.sender] -= _amount;
// 2. Interactions: 状態更新後に外部呼び出し
(bool success, ) = msg.sender.call{value: _amount}("");
require(success, "転送失敗");
}
}インフラ・Web層での防御：WAFによる保護
Web3のフロントエンドや、IoTデバイスがREST APIでコントラクトとやり取りする際、攻撃者がリクエストを連打（Replay）して再入のトリガーを引くことを防ぐために、Nginxでレートリミットを厳格に設定する。
# /etc/nginx/conf.d/security.conf
# APIエンドポイントへの過度なアクセスを制限
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;
server {
location /api/v1/transaction {
limit_req zone=api_limit burst=10 nodelay;
# 攻撃者のIPをブロックリストへ送るロジックを推奨
}
}—
4. セキュリティリサーチャーからの「現場の知恵」
最後に、一つだけ覚えて帰ってほしい。「ガードはあくまで保険である」ということ。
真に堅牢なシステムを作るのは、防御コードの羅列ではなく、「状態の非依存性」だ。複数のコントラクトにまたがる処理を行う場合、Flash Loan（フラッシュローン）攻撃を前提とした設計が必要になる。
1. Read-Only Reentrancyへの警戒: view関数であっても、他コントラクトの状態が更新中であることを知らずに参照すると、誤った計算結果を返す可能性がある。
2. イベントの活用: 状態変化は必ずeventを発行し、オフチェーンの監視システム（Fortaなど）で即座に検知できるようにしておく。
セキュリティは「防壁を作る」作業ではなく、「攻撃者が動ける範囲を極限まで狭める」作業だ。このコードをそのままコピペするだけでなく、君たちのシステムが「どの順序で状態が変化するのか」を一度紙に書き出してみること。そこに必ず、攻撃の糸口があるはずだ。
次は、より凶悪な「コントラクトのデプロイ順序を突いたフロントランニング」について話そう。まずはこの基礎を完璧に叩き込んでくれ。
コメント