【実務・中級編】 tx.originとmsg.senderの混同によるフィッシング脆弱性 – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

認証の「真実」を見誤るな：tx.originが招くスマートコントラクトの死角

現場でコードを叩いていると、たまに「なぜこんな設計になったんだ？」と頭を抱えたくなる瞬間に遭遇する。今日取り上げる tx.origin と msg.sender の混同は、まさにその筆頭だ。

多くのジュニアエンジニアは、Solidityのグローバル変数を見て「どっちも送金元だし、なんとなく似たようなものだろう」と考える。だが、セキュリティの最前線にいる我々にとって、この二つは「鍵の持ち主」と「部屋のドアを叩いた訪問者」ほど決定的に違う。この違いを理解していないと、君が書いたスマートコントラクトは、フィッシング攻撃に対して無防備なATMと化す。

なぜ tx.origin を使ってはいけないのか

結論から言おう。tx.origin は「トランザクションの発信源（EOA: 外部所有アカウント）」を指すが、msg.sender は「現在その関数を呼び出している当事者」を指す。

攻撃者が狙うのは、コントラクトが「認証」のために tx.origin を参照しているケースだ。もしコントラクトAが tx.origin で認証を行い、コントラクトB経由で呼び出された場合、tx.origin は依然としてユーザー本人を指すが、msg.sender はコントラクトBになる。

ここに「フィッシング」の隙が生まれる。

攻撃のシナリオ：巧妙な罠

1. 被害者：権限のあるコントラクト（例：ウォレットコントラクト）をデプロイしている。
2. 攻撃者：悪意のあるコントラクト（AttackContract）を作成し、被害者に「このリンクを踏むと報酬がもらえる」と騙す。
3. 実行：被害者が悪意あるコントラクトを呼び出すと、そのコントラクトが被害者のウォレットを「被害者自身の権限で」操作し、資産を抜き取る。

被害者は「自分のウォレット」を呼び出しているつもりだが、実際には攻撃者がバックドアとして仕込んだコントラクトを介して実行される。このとき、tx.origin は「被害者」のままなので、認証をやすやすと通過してしまうのだ。

実践的修正：msg.sender を使え

防御策はシンプルだ。「認証には必ず msg.sender を使う」。これだけで、コントラクト間呼び出しにおいて、一つ前の呼び出し元（＝認証すべき対象）が自分自身であることを強制できる。

脆弱なコード（絶対に書くな）

// 悪用される可能性が高い実装
function transferAll(address payable _recipient) public {
    // tx.originは外部から攻撃コントラクト経由でも偽装できないため、
    // 逆に「本人」を特定しすぎてしまい、フィッシングに悪用される。
    require(tx.origin == owner, "あなたには許可がありません");
    _recipient.transfer(address(this).balance);
}

セキュアな実装（推奨される書き方）

// msg.senderを使用することで、呼び出し元が直接自分であることを保証する
function transferAll(address payable _recipient) public {
    // msg.senderは直接呼び出しているアドレスを指すため、
    // 悪意のあるコントラクトが介入した場合、msg.senderは「攻撃コントラクト」になる。
    // そのため、コントラクト間呼び出しによる不正操作を防げる。
    require(msg.sender == owner, "許可されていません");
    _recipient.transfer(address(this).balance);
}

フロントエンド（JavaScript）からの安全な接続

コントラクトが堅牢でも、それを叩くWeb3アプリケーション側で「誰が署名しているか」の確認を怠ってはいけない。ethers.js や viem を使用する際は、必ずユーザーにトランザクションの意図を確認させるUIを実装すること。

// フロントエンドでのセキュアな呼び出し例
async function withdrawFunds(contractAddress, signer) {
    const contract = new ethers.Contract(contractAddress, ABI, signer);
    
    try {
        // トランザクション発行前に、ユーザーへ明示的に確認を促すUIを出す
        console.log("資金を引き出そうとしています。宛先を確認してください。");
        const tx = await contract.transferAll(RECIPIENT_ADDRESS);
        await tx.wait();
        console.log("完了しました");
    } catch (err) {
        console.error("ユーザーが拒否したか、不正な呼び出しです:", err);
    }
}

現場のエンジニアへ：最後の防衛ライン

スマートコントラクトのセキュリティは、単にコードを書くことではない。「攻撃者の思考をシミュレートすること」だ。

ルール1：tx.origin は、特定の目的（コントラクト間での認証の回避など）以外では絶対に使用しないこと。
ルール2：msg.sender は、常に直前の呼び出し主を指す。この性質を理解し、コントラクト間の継承や呼び出しにおいて「誰が権限を持っているか」を厳格に管理すること。
ルール3：Web3アプリ開発では、署名リクエストの内容をユーザーが理解可能な形で提示すること。

もし、今君が保守しているシステムで tx.origin が使われていたら、明日すぐにコードレビューの議題に上げろ。泥臭いようだが、こういった小さな実装の積み重ねこそが、何百万ドルもの資産を流出から守る唯一の手段だ。

セキュリティは「チェックリスト」を埋める作業ではない。コードの裏側に潜む「意図」を読み解く、知的格闘技であることを忘れないでほしい。