tx.origin と msg.sender の違いは何ですか?また、tx.origin を避けるべき理由は何ですか?

Ethereum スマート コントラクトの tx.origin と msg.sender について理解する

1. tx.origin は、途中で発生したコントラクト呼び出しの数に関係なく、トランザクションを開始した元の外​​部アカウントを指します。これは、ユーザーがコントラクト A と対話するトランザクションを送信し、その後コントラクト B を呼び出す場合でも、コントラクト B の tx.origin の値は依然としてユーザーのウォレット アドレスを指すことを意味します。

2.一方、msg.sender は、外部所有アカウント (EOA) であっても、別のコントラクトであっても、現在の関数の直接の呼び出し元を表します。同じ例で、契約 A が契約 B を呼び出すと、契約 B 内の msg.sender は元のユーザーではなく契約 A のアドレスになります。

3. この区別は、アクセス制御や取り消しメカニズムなど、許可に依存する機能において重要になります。 tx.origin に依存すると、ロジックが認証に tx.origin に依存している場合、ユーザーによって呼び出された悪意のあるコントラクトが (間接的であっても) 権限を偽装できるため、脆弱性が生じる可能性があります。

4. たとえば、tx.origin が所有者のアドレスと一致する場合にのみ引き出しを許可するスマート コントラクトを考えてみましょう。攻撃者は、所有者が知らずに操作する悪意のあるコントラクトを作成する可能性があります。そのコントラクトがトリガーされると、被害者コントラクトの撤回関数が呼び出されます。 tx.origin は所有者のアドレスのままであるため、チェックはパスし、適切な所有権チェックにもかかわらず盗難が可能になります。

5. この動作は、安全なコーディングにおける最小特権の原則を損なうものです。スマート コントラクトは、誰がチェーンを開始したかではなく、誰が直接呼び出したかに基づいて検証する必要があります。 msg.sender を使用すると、構成可能性が向上し、コントラクトが日常的に相互作用する分散型アプリケーションで予期されるパターンに適合します。

tx.origin の使用に伴うリスク

1. tx.origin を認証に使用すると、フィッシング攻撃が容易になります。ユーザーは、より深い呼び出しチェーンをトリガーする一見無害なトランザクションを承認する可能性があり、攻撃者が tx.origin を誤って信頼する契約から資金を流出させる可能性があります。

2. tx.origin の存在により、誤った安心感が生まれます。開発者はエンドユーザーを検証していると思っているかもしれませんが、実際には、中間コントラクトを通じてシステムをプロキシエクスプロイトにさらしていることになります。

3. tx.origin を制限またはサニタイズする組み込みメカニズムはありません。直接スプーフィングすることはできませんが、イーサリアムの実行環境に固有の委任モデルをバイパスするため、その性質上、アクセス制御には適していません。

4. アップグレード可能な契約や複雑な DeFi プロトコルは、多くの場合、階層化された相互作用に依存しています。 tx.origin がコア ロジックに埋め込まれている場合、これらのシステムは正規のコントラクト間操作中に中断する危険があり、予期しない取り消しや権限エラーが発生します。

5. コミュニティ標準や Consensys Best Practices などの監査フレームワークでは、認可目的で tx.origin を使用しないことを明示的に推奨しています。主要なプロトコル監査では、その使用が高リスクであるとのフラグが立てられ、初期世代のトークン契約における現実世界の悪用の一因となっています。

安全な契約設計のベスト プラクティス

1. 元のトランザクション開始者を参照する非常に具体的かつ正当な理由がない限り、コントラクト内のアクセス許可を確認するときは常にmsg.senderを使用します。その場合でも、細心の注意が必要です。

2. OpenZeppelin の Ownable や AccessControl などの確立されたライブラリを使用してロールベースのアクセス制御を実装します。これらのライブラリは msg.sender を中心に設計されており、tx.origin に依存せずに詳細な権限管理をサポートします。

3. カスタム認証ロジックを最初から作成することは避けてください。十分にテストされ、コミュニティで精査されたパターンを活用して、分散環境での本人確認に関連するよくある落とし穴を防ぎます。

4. 認証フローに焦点を当てた徹底的なセキュリティレビューを実施します。静的分析ツールと正式な検証方法は、tx.origin の不適切な使用を検出し、より安全な代替手段を提案できます。

5. EVM の実行モデルについて開発チームを教育します。コールスタックがどのように伝播するか、およびコントラクト呼び出し中に送信者のコンテキストがどのように変化するかを理解することは、tx.origin セマンティクスの誤解に根ざした設計上の欠陥を防ぐのに役立ちます。

よくある質問

tx.origin は安全に使用できるのでしょうか?はい、ただし、分析や非クリティカルな状態の追跡のために元のイニシエーターをログに記録するなど、非常に限定されたシナリオでのみ可能です。その場合でも、開発者はアクセスの決定や資金移動に影響を与えないようにする必要があります。

msg.sender を使用すると、なりすましのリスクはすべて回避できますか?単一の変数ですべてのリスクを排除することはできませんが、msg.sender はイーサリアムが意図するセキュリティ モデルと一致しています。なりすましを防止するには、入力検証、再入ガード、安全な設計パターンなどの追加の対策も必要です。

コントラクトが tx.origin を使用し、別のコントラクトによって呼び出された場合はどうなりますか? tx.origin は元のユーザーのアドレスのままであるため、意図しない認可結果が生じる可能性があります。 EOA からの直接対話を期待する契約では、元の署名者が有効であるという理由だけで、誤って悪意のある仲介契約へのアクセスを許可する可能性があります。

tx.origin の悪用を検出するツールはありますか?はい、Slither、MythX、Solhint などのセキュリティ スキャナーは、承認コンテキストで tx.origin の使用にフラグを立てます。これらのツールは CI/CD パイプラインに統合されており、展開前に危険なパターンを特定するのに役立ちます。