分散型金融 (DeFi) エコシステムと Web3 の発展は、人々がデジタル資産を扱う方法に革命的な変化をもたらしました。しかし、自動トランザクションの利便性の裏には複雑な権限構造があり、ユーザー エクスペリエンス (UX) とセキュリティの間のトレードオフにより大きな脆弱性が生じています。スマート コントラクトのアクセス権は、単なる「承認」ボタンではありません。これは資産所有権の委任メカニズムであり、悪用された場合、単一のトランザクションでウォレット全体が枯渇する可能性があります。 Tan Phat Digital によると、このレポートでは、無限のトークン承認、オフチェーン署名を介したフィッシング攻撃、プロトコル ガバナンスの集中リスクによる技術的リスクの分析を詳しく分析し、ゼロ トラストの考え方とロールベースのアクセス管理 (RBAC) に基づいたセキュリティ ロードマップを提案します。
トークン承認の技術的メカニズムと無限の承認によるリスク
スマート コントラクトについては、本質的に、トークン承認から資産を任意に移動することはできません。ユーザーの財布。分散型取引所 (DEX) でのスワップや NFT の上場などの操作を実行するには、ユーザーはトークン承認と呼ばれるメカニズムを通じてスマート コントラクトを承認する必要があります。
承認メカニズムの 3 段階の構造
ERC-20 および ERC-721 標準は、ユーザーに代わって送金を行うための特定のプロトコルを定義しています。このメカニズムには 3 つの主要なコンポーネントが含まれています:
Approve(spender, amount) 関数: アクセス権を承認します。技術的な役割は、ブロックチェーン状態での支出が許可されている残高のマッピングを更新することです。
機能許可 (所有者、支出者): 権限をチェックします。技術的な役割は、特定のアドレスが所有者から引き出すことができるトークンの量をクエリすることです。
関数 transferFrom(from, to, amount): 資産の移動を実行します。技術的な役割は、ユーザーのウォレットからトークンを引き出し、ターゲット アドレスに転送することです。
ユーザーが承認関数を呼び出すと、支出者のアドレスが自分のアドレスから一定量までのトークンを引き出す権利があるという不変のコミットメントがブロックチェーン上に記録されます。危険は、要求されたトークンの量が許容制限内にある限り、ユーザーからのさらなる確認なしに、将来いつでもスマート コントラクトによって transferFrom 関数を呼び出すことができるという事実にあります。
参照: 承認の取り消しとは何ですか?
利便性のパラドックス: 無限の承認トークン
実際には、エクスペリエンスを最適化しガスコストを最小限に抑えるために、ほとんどの分散型アプリケーション (dApps) はユーザーに「無限」の承認を要求します。権限 (通常は整数変数 $2^{256} - 1$ の最大値)。これにより、ユーザーはトランザクションごとに署名する必要がなく、1 回の承認に対してガス料金を支払うだけで済みます。
ただし、この利便性にはセキュリティの点で高い代償が伴います。無制限の承認権が付与されると、明示的に取り消されるまで、その承認権はブロックチェーン上に永続的に存在します。ユーザーがアプリケーションの Web サイトからウォレットを切断した場合でも、その権限はオンチェーンに残り、スマート コントラクトがいつでも資産にアクセスできるようになります。そのスマート コントラクトが失敗するか、攻撃者によって制御されている場合、ユーザーのウォレット内のそのトークンの残高全体がすぐに枯渇します。
ストレージの脆弱性と永続性の分析
承認データはユーザーのウォレット内ではなく、そのトークン コントラクトのストレージ (ストレージ) にあります。これにより、認識上の盲点が生じます。ユーザーはウォレット内の残高を頻繁にチェックしますが、その残高を「ロック解除」する権限を持つエンティティのリストをチェックすることはほとんどありません。 Revoke プラットフォームの統計によると、2020 年以降、承認権の乱用に関連する脆弱性により 4 億 7,500 万ドル以上が盗まれています。 Tan Phat Digital は、これは技術的な欠陥であるだけでなく、Web3 業界全体のユーザー エクスペリエンス (UX) 設計の失敗でもあると強調します。
オフチェーン承認メカニズムによるフィッシング攻撃の進化
コミュニティが承認ごとのガス料金の煩わしさを軽減する方法を模索する中で、EIP-2612 (Permit) や Uniswap Permit2 などの新しい標準が登場しました。これらはコスト面でのメリットをもたらしますが、より高度なフィッシング攻撃に新たな道を開きます。
許可メカニズムと関連リスク
ERC-20 承認: オンチェーン トランザクションを介した許可。透過的で追跡が簡単であるという利点がありますが、欠点は、実行ごとにガスがかかり、無制限のアクセス許可を付与すると潜在的なリスクがあることです。
EIP-2612 許可: オフチェーン署名を介したアクセス許可の付与。ユーザーはガス代を回避できますが、署名メッセージは読みにくく、異常を検出するのが難しいことが多いため、「ブラインド署名」フィッシング攻撃に対して脆弱です。
許可 2: 事前の承認に基づく署名。優れた柔軟性と集中管理を提供しますが、だまされて悪意のある Permit2 メッセージに署名すると、攻撃者はこの契約の承認済みトークンをすべて排出する可能性があります。
EIP-7702: EOA ウォレットの「トロイの木馬」
2025 年 5 月の Pectra アップグレードで導入された EIP-7702 により、アカウントを所有者 (EOA) に一時的に「変換」させることができます。スマートコントラクトウォレット。攻撃者はユーザーをだまして、悪意のある「家政婦」契約の承認に署名させます。この認証が有効になると、攻撃者は被害者のアカウントに自動引き出しロジックを直接インストールすることができます。 Dune Analytics のデータによると、2025 年 6 月までに、EIP-7702 プロキシ トランザクションの 97% 以上が、犯罪行為に関連する悪意のあるコントラクトをターゲットにしていました。
一元化された管理者権限と特権機能によるリスク
ユーザーのリスクに加えて、プロトコル自体内の権限構造も脅威です。集中化の欠陥は、システム全体の崩壊を引き起こす可能性のある単一の弱点が設計によって生じた場合に発生します。
単一署名付きミント機能 (MFS): 単一のアドレスで無制限のトークンを印刷できるようになり、ハイパーインフレにつながります。
タイムロックなしの管理 (MT): 重要な変更がすぐに実装され、コミュニティが対応できなくなる可能性があります。
重要変数操作 (CVS): 金利、リスク パラメーター、またはデータ フィード (オラクル) を変更する権限を持つ単一のアカウント。
単一プロキシ管理者 (SPA): スマート コントラクト ロジック全体をアップグレードする権利を制御するアドレス。
Chaina Analysis が報告したように、約ブロックチェーン ハッキングで盗まれた資金の 43.8% は、特権アカウントの秘密キーの漏洩に由来しています。
こちらも参照: 危険性承認詐欺
アップグレードとストレージの衝突（ストレージ衝突）のリスクの技術分析
DeFi プロトコルは、エラーを修正したり、機能を追加したりするためにプロキシ モデルを使用することがよくあります。ただし、このメカニズムはデリゲートコールに依存しているため、ストレージ衝突のリスクが伴います。新しい論理コントラクト内の変数の順序が古いコントラクトと比較して正しくない場合、保存されている値は上書きされます。攻撃者はこれを利用して、プロキシを悪意のある論理コントラクトに誘導し、ユーザーの資産を流出させる可能性があります。
さらに、Initializer Vulnerability の脆弱性も非常に一般的です。開発者が初期化関数の保護を忘れた場合、攻撃者はこの関数を呼び出して自分自身を所有者として識別し、システム全体を制御する可能性があります。
実際の攻撃からの教訓
Tan Phat Digital は、過去のインシデントの分析により、認可の脆弱性が実際にどのように悪用されているかを明らかにしています。
ステップ ファイナンス (2026 年 1 月): 被害額は約 3,000 万ドル。攻撃者は運営チームのデバイスに侵入し、それによって財務ウォレットにアクセスし、261,854 SOL を引き出しました。
CrossCurve (2026 年 2 月): 被害額は 300 万米ドル。この攻撃は、クロスチェーン メッセージ ロジックの実装エラーを悪用し、攻撃者がなりすましメッセージを送信して認証を回避し、不正な引き出しを行うことを可能にします。
Radiant Capital (2024 年 10 月): 5,000 万ドルの損失。マルウェアは開発者のデバイスに感染し、マルチシグ トランザクションのペイロードをサイレントに置き換えて、契約の所有権を攻撃者に譲渡しました。
Poly Network (2021): 被害額は 6 億 1,100 万ドル。アクセス ロジック エラーにより、クロスチェーン呼び出しによる入力パラメータの操作が可能になります。
Bybit (2025 年 2 月): イーサリアムで 15 億ドル近くの損失を伴う記録盗難。認証の脆弱性の壊滅的な規模が示されています。
推奨ソリューション: スマート コントラクト用のゼロトラスト セキュリティ フレームワーク
常に継続的に認証する: すべてのアセット アクセス リクエストは実行時に認証される必要があります。
リースト アクセス権 (RBAC): 完全な所有者権限を割り当てるのではなく、権限を Minter、Pauser などの特定の役割に分割します。
システム前提が侵害されている: 自動サーキットブレーカーとリアルタイム監視を導入します。
よくある質問 (FAQ)
1.トークン承認とは何ですか? dApps にそれが必要な理由 トークン承認は、スマート コントラクトに付与するオンチェーン アクセス許可であり、個別のトランザクション アクションごとに署名を必要とせずに、ウォレット内の特定量のトークンにアクセスできるようになります。
2. 「無制限」のアクセス許可 (無制限の承認) を付与することは安全ですか? 安全ではありません。 dApp がハッキングされているか詐欺である場合、攻撃者はこの権限を使用して、いつでもウォレットからトークンを完全に排出できます。
3.ウェブサイトからウォレットを切断すると、 付与されていた権限は取り消されますか? いいえ、切断すると、ウェブサイトがウォレットのアドレスを参照できなくなるだけです。承認権限は、特定の取り消しトランザクションを実行するまで、ブロックチェーン上に永続的に残ります。
4. 1 回の承認により、ウォレット内のすべての資産を失うことはありますか?承認トランザクションは通常、特定のトークン (たとえば、WETH のみ) にのみ適用されます。 NFT の SetApprovalForAll などのより複雑な権限に署名しない限り、攻撃者は承認したトークンのみを入手できます。
5.付与した権限のリストを確認するにはどうすればよいですか?Revoke.cash、Etherscan Token Approval Checker、De.Fi Shield などの信頼できるツールを使用して、さまざまなネットワーク上のすべてのアクティブな権限をスキャンできます。
6. Permit (EIP-2612) は従来の Approve とどのように異なりますか? Approve では、すぐにガスがかかるオンチェーン トランザクションが必要です。 Permit はオフチェーン署名を使用し、ユーザーのガスを消費せずにアクセス許可を承認できるようにします (ガス料金は通常、後でトランザクションが行われるときにプロトコルによって支払われます)。
7.疑わしいサイトで誤ってオフチェーンの許可/署名に署名した場合はどうすればよいですか?すぐに失効ツールにアクセスして、署名がオンチェーンで有効になっているかどうかを確認する必要があります。ただし、オフチェーンの署名は攻撃者によってほぼ即座に実行されることが多いため、破壊するのは困難です。
8.マルチシグ ウォレット (Safe など) が依然としてハッキングされる可能性があるのはなぜですか? マルチシグ ウォレットのハッキングは、多くの場合、所有者のデバイスがマルウェアに感染していることが原因で、攻撃者が署名時にユーザーの知らない間に実際のトランザクション コンテンツを悪意のあるトランザクションに置き換えることができます (インターフェイス フィッシング)。
9.タイムロックとは何ですか? プロジェクトにタイムロックが必要な理由 タイムロックは、管理コマンドの実行を遅らせるメカニズムです (例: 48 時間の遅延)。これにより、コミュニティは変更をテストし、管理者からの暴利が検出された場合は資産を引き出すことができます。
10.技術的リスクと管理的リスク (集中化リスク) の違いは何ですか? 技術的リスクは、コード内の論理エラー (再入可能など) から発生します。ガバナンスのリスクは、権限が 1 人の個人に過度に集中することで生じ、その個人が重要なパラメータを変更したり、契約を恣意的にアップグレードしたりできるようになります。
11. 「approve-to-zero-then-set」 設計パターンとは何ですか?これは、一部の古いトークン標準における競合状態攻撃を防ぐために、新しい承認レベルを設定する前に承認レベルをゼロにすることをユーザーに要求するセキュリティ プロセスです。
12. EIP-7702 はどのようなセキュリティ上の利点をもたらしますか? EIP-7702 により、ウォレットは「セッション インテント」を実行できるようになり、承認とアクションを 1 つのトランザクションにグループ化するため、トランザクション完了後にブロックチェーン上で無制限のアクセス許可が一時停止される可能性が最小限に抑えられます。
13.プロジェクトをいつ再監査する必要がありますか?新たな脆弱性が導入されないように、コードの大幅な変更、契約ロジックのアップグレード、または新しいサードパーティ プロトコルとの統合が行われた場合は必ずプロジェクトを再監査する必要があります。
14.スマート コントラクトが安全であることを確認するにはどうすればよいですか?評判の良い企業からの監査レポートがあるかどうか、テストネットでの活動履歴、バグ報奨金プログラムがあるかどうか、ソース コードがブロック エクスプローラーで公開されているかどうかを確認する必要があります。
15.コールド ウォレット (ハードウェア ウォレット) はフィッシング攻撃から私を守ってくれますか? コールド ウォレットは秘密鍵をマルウェアによる盗難から守ります。ただし、騙された場合に悪意のあるトランザクションへの署名 (ブラインド署名) を防ぐことはできません。確認する前に、必ずコールドウォレット画面のパラメータを確認してください。
Tan Phat Digital は、エンド ユーザーが Revoke.cash、De.Fi Shield、Etherscan Token Approval などのツールを使用して定期的に承認を確認し、取り消すことをお勧めします。トランザクションに署名するときは、デフォルトの無制限の承認レベルを受け入れるのではなく、常に「権限の編集」機能を使用してトークンの数を制限してください。
スマート コントラクトの権限は、実際には私たちが想像しているよりも危険です。技術ソリューションとゼロトラストの考え方を緊密に組み合わせることが、持続可能で信頼できる Web3 エコシステムを構築するための重要な基盤です。
シェア
