`tx.origin`による認可はなぜ危険なのか

:::認証と認可の違い

認証と認可は似ているが、意味は異なる。

認証は、「相手が誰であるか」を確認することである。たとえば、「この署名はAliceの秘密鍵で作られたものか」「このウォレットを操作しているのはAlice本人か」と確認する処理が認証にあたる。

一方、認可は、「その相手に特定の操作を行う権限があるか」を確認することである。たとえば、「Aliceはownerか」「このアドレスはMINTER_ROLEを持っているか」「このアドレスはtransferOwnership()を実行してよいか」と確認する処理が認可にあたる。

スマートコントラクトの onlyOwner や onlyRole は、主に認可ロジックである。つまり、呼び出し元が誰かを見たうえで、そのアドレスに関数を実行する権限があるかを判定している。

本記事で問題にしている tx.origin の使い方も、厳密には「認証の問題」ではなく「認可の問題」である。tx.origin == ownerというチェックは、「トランザクションを開始したアドレスに、この管理者関数を実行する権限があるか」を判定しているためである。

ただし、実務上は「認証チェック」「権限チェック」といった言い方が混ざって使われることもある。本記事では、正確さを優先し、管理者関数を実行できるかどうかの判定を「認可」または「権限チェック」と呼ぶ。

:::

Solidityでは、権限チェックに tx.origin を使うべきではない。

理由は、tx.origin を使うと、攻撃者が所有者本人をフィッシングで誘導し、悪意あるコントラクト経由で管理者関数を実行できてしまうためである。

:::phishing = 人を騙して情報や署名を引き出す攻撃

フィッシング（phishing）は、英語の fishing、つまり「釣り」に由来すると言葉である。

攻撃者が偽サイト、偽メール、偽dAppなどを「餌」として用意し、ユーザーがそれに引っかかって認証情報、秘密情報、署名、トランザクション承認などを与えてしまう様子が、魚釣りにたとえられている。

fishing ではなく phishing と書くのは、電話網のハッキングを指す古いハッカー用語 phreaking の影響を受けた表記とされる。phreaking は phone と freak に由来するとされる。

スマートコントラクト文脈では、フィッシングは単にパスワードを盗むだけではない。ユーザーに悪意あるdAppを操作させ、危険なトランザクションや署名を承認させる攻撃も含まれる。

:::

一見すると、tx.origin は「トランザクションを開始した本人」を確認できるため、安全に見えるかもしれない。しかし、そこが落とし穴である。

tx.origin は、トランザクションの最初の送信者を表す。つまり、ユーザーがどのコントラクトを経由していても、最初にウォレットで署名した本人のアドレスが入る。

一方、msg.sender は、その関数を直接呼び出してきた相手を表す。直接呼び出してきた相手がユーザーのウォレットであればウォレットアドレスになり、別のコントラクトであればそのコントラクトアドレスになる。

この違いが、アクセス制御では非常に重要である。

tx.origin  // トランザクションを最初に開始したウォレット
msg