プロトコルには監査レポートがあるのに、なぜそれでも古い承認によって資金を抜き取られてしまうのか？
監査レポートが検証するのは、監査が行われた時点でのコントラクトのコードロジックであり、そのコントラクトが将来永遠に問題を起こさないことの保証でも、そのコントラクトとやり取りしたすべてのユーザーが保守的な許可額を設定していることの保証でもない。Li.Fiを例に取ると、2024年に問題となったのは後になって発見されたコントラクト自体の脆弱性であり、監査が不十分だったわけではない——しかし実際の損失規模を左右したのは、どれだけ多くのユーザーアカウントに、それ以前のやり取りで承認した無制限の許可がまだ有効なまま残っていたかだった。もしすべてのユーザーが当初、必要な分だけの額を承認していたなら、たとえコントラクトに脆弱性があったとしても、攻撃者が奪えたのはその一回の取引に必要な分だけであり、ウォレット全体の残高ではなかったはずだ。
つまり監査が解決するのは「コントラクトのロジック自体に欠陥がないか」という問題であり、ユーザー自身がどれだけ古い承認を残しているかは、まったく別のリスクの層であり、プロトコルが監査を受けたからといって自動的に安全になるわけではない——だからこそ、監査記録が充実している有名なプロトコルであっても、定期的に承認を確認し、使わなくなったものを取り消すことが推奨されているのだ。
もし自分の承認額のほとんどがすでに必要な分だけに設定されているなら、時間をかけて取り消す必要はまったくないのでは？
必要な分だけの額を設定することは、単一の脆弱性がもたらす損失の上限を大幅に引き下げており、これは正しい方向であり評価に値する。しかしこれは取り消し作業がまったく不要であることを意味しない——古い承認は、額が限定されていても依然として攻撃対象面だ。長らく使っていないプロトコルのメンテナンスが停止したり、そのコントラクトの権限が悪意ある形で奪われたりすれば、額が限定されていても何らかの方法で悪用される可能性はまだ残る。また、額が限定された承認は、複合的な攻撃に利用されることもある——他の脆弱性と組み合わせて、複数の限定額承認を積み重ね、より大きな損失に至らせるケースだ。
より実際的な考慮点は、承認リストが長くなればなるほど、「このspenderアドレスは一体どのプロトコルなのか、自分はまだ使っているのか」を記憶し識別する手間が大きくなるということだ。何年も動かしていない十数個から二十個ほどの承認が並んだリストは、それ自体がどれが安全でどれが期限切れで取り消すべきかの判断を難しくする。より現実的なやり方は、すべての取引の後に即座に取り消すことを自分に課すのではなく、定期的に（例えば四半期ごとに）承認リストを確認する習慣を身につけ、明らかに使わなくなったプロトコルの承認を整理し、リスト自体を一つ一つ識別し判断できる規模に保つことだ。
PermitやPermit2といった署名ベースの承認メカニズムは、より安全に聞こえるのか、それともより危険に聞こえるのか？
どのような文脈で使われるかによる。Permit（EIP-2612）とPermit2という2つのメカニズムは、もともと従来のapproveフローが抱えていた「まず承認トランザクションを送信し、その後実際の操作トランザクションを送信する」という2段階でガス代を2回支払わなければならない手間を解決するために設計されたものだ——このうち一つのオンチェーントランザクションを署名で置き換えることは、理論上は正当な利用シーンにとってより効率的で、ガス代を節約できる設計であり、セキュリティメカニズムを回避するために生まれたものではない。
しかし、この署名がガス代を必要とせず、ブロックエクスプローラーにも即座に表示されないからこそ、フィッシング攻撃においてますます好まれる手口になっている——被害者は自分が「ただ署名しただけ」だと感じ、「トランザクションを送信する」ことに対するよりもはるかに低い心理的警戒しか働かないが、実際に署名によって承認される内容は、従来の承認トランザクションとまったく同じ効力を持つ。つまりメカニズム自体がより危険というわけではなく、危険なのはユーザーが「署名」という行為に対して、一般的に「トランザクション」に対してよりも警戒心が低いという点にある。リスクを判断する上で重要なのは、どのメカニズムが使われているかではなく、署名やトランザクションのリクエストがポップアップ表示されるたびに、その中に記載されているspenderアドレス、許可額、コントラクトの所在地を真剣に確認しているかどうかなのだ。
十数件の一度も整理していない承認が溜まっていることに気づいた場合、どの順番で取り消すべきかどう決めればよいか？
第一の優先順位は「現在の残り許可額」を確認することだ——EtherscanやRevoke.cashで、ある承認の数値が天文学的な数字に近ければ、それは無制限の許可であり、この種の承認はダメージの上限が最も高い（何かあれば、トークン残高全体が失われる可能性がある）ため、優先的に対応すべきだ。第二の優先順位は、このspenderコントラクトをまだ認識していて、まだ使っているかどうかだ——もう何カ月、あるいは何年もやり取りしていないプロトコルであれば、額の大小にかかわらず取り消す価値がある。なぜなら、そのプロトコルのセキュリティ状況や運営の進捗をもはや継続的に把握していないからだ。
第三の優先順位は、その承認に対応するトークン自体の価値と保有量だ——ウォレット内のそのトークンの残高が少なければ、たとえ承認額が無制限であっても、実際に生じうる損失は限定的だ。逆に、それがウォレット内で最大の保有資産であれば、たとえ承認額が妥当に見えても、そのspenderコントラクトの現在のセキュリティ状況を優先的に確認する価値がある。取り消し自体にはガス代がかかるため、リストのすべての項目を即座に処理する必要はなく、「無制限額を優先、長期未使用を優先、高価値資産を優先」という3つの観点で順位付けすれば、通常は本当に対応すべき数件を絞り込むことができる。
ほとんどのDeFiプロトコルで最初の取引を行う前に、「承認」（approve）と呼ばれる確認ポップアップが表示されるだろう——あなたはおそらく深く考えずに確認をクリックしたかもしれない。クリックしなければ先に進めないからだ。この動作がしていることは、スマートコントラクトが将来的にあなたのウォレットからある種のトークンの残高を動かせるようにすることであり、多くのウォレットはデフォルトで「今回使う分の量」ではなく、無制限の許可（通常は2^256-1という天文学的な数字で表される）を要求する。これはつまり、そのコントラクトのコードに脆弱性が見つかったり、その権限が攻撃者に奪われたりすれば、あなたがかつて与えた承認だけで、誰かが一回の取引であなたのそのトークンの残高をすべて抜き取ることができるということだ——秘密鍵は不要だ。なぜならあなたがすでに自分自身でその権限を渡してしまっているからだ。
よくある誤解の一つは、あるウェブサイトからウォレットの接続を解除すればリスクがなくなると考えることだ。実際はまったくそうではない——許可（allowance）はオンチェーンに書き込まれた記録であり、トークンコントラクト自体に属するものであって、ウェブサイトのフロントエンドとあなたのウォレットの接続状態ではない。接続を解除しても、そのサイトが一時的にあなたのウォレットアドレスを見られなくなるだけであり、「このコントラクトがあなたのトークンを動かせる」という記録は、あなたが能動的にそれを取り消すトランザクションを送信するまで、オンチェーンに無期限に残り続ける。だからこそ承認を確認する作業は、「最近このサイトと関わったかどうか」を基準にすることはできず、自分のウォレットアドレスについて、これまでどの承認を与えてきたか、そして現在もどれが有効なままかを、直接チェーン上で確認する必要がある。
Ethereumを例に取ると、最も直接的な無料ツールはEtherscanに組み込まれているToken Approvalsページだ。etherscan.io/tokenapprovalcheckerにアクセスし、「Connect to Web3」をクリックしてウォレットを接続する（これは読み取り専用の照会であり、いかなるトランザクションへの署名も求められない）。インターフェースには、そのアドレスの現在有効なすべての承認が一覧表示され、各承認の「元の許可額」（Original Allowance）と「現在の残り許可額」（Current Allowance）も含まれる——もし現在の残り許可額が天文学的な数字に近い値を示していれば、それは無制限承認だということだ。取り消したい項目を見つけて対応する「Revoke」ボタンをクリックすると、ウォレットがトランザクションリクエストをポップアップ表示する。このトランザクションは本質的に該当トークンコントラクトのapprove関数を呼び出し、許可額をゼロに再設定するものであり、有効にするにはガス代の支払いが必要となる——取り消し自体もオンチェーンのトランザクションであり、無料ではない。複数チェーンを利用するユーザーは、Revoke.cashやDebankといったサードパーティツールを使えば、複数のチェーン上の承認状況を一度にまとめて確認することもできる。
無制限承認が悪用されるのは仮定の話ではない。2023年、ハードウェアウォレットメーカーLedgerのConnect Kitコンポーネントがフィッシング攻撃を受け、ユーザーを騙して無制限承認に署名させ、資金の盗難につながった。2024年には、クロスチェーンプロトコルLi.Fiのコントラクトの脆弱性が悪用され、多くのユーザーアカウントにすでに存在していた無制限承認に起因する約970万ドルの損失が発生した。同年、分散型取引所集約プロトコルParaSwapのAugustus V6コントラクトに脆弱性があり、以前に承認を与えていたユーザーが影響を受けた。ステーブルコインプロトコルSenecaUSDはコントラクトの欠陥により攻撃者が既存の承認を悪用し、約650万ドルを失った。クロスチェーンブリッジプロトコルSocketDotTech（Bungee）は入力検証の不備により、無制限承認を持つユーザーが約330万ドルを失った。流動性プロトコルConcentricFiは、アップグレード可能なコントラクトの制御権を攻撃者に奪われたことで約172万ドルの損失を被り、事後に公式がすべてのユーザーに承認を取り消すよう公に勧告した。これらの事例に共通するのは、問題の根本原因は各プロトコル自身のコントラクトにあったが、実際にどれだけ資産が抜き取られたかは、被害者がすでに取り消しておくべきだった古い承認をまだ保持していたかどうかに左右されたという点だ。
近年のフィッシング攻撃は、被害者に明らかに疑わしく見えるオンチェーントランザクションの送信を求めることが減り、代わりにEIP-2612（Permit）やPermit2といった署名メカニズムを利用するケースが増えている——この種の署名はブロックエクスプローラーに即座には表示されず、ガス代を支払う必要もないため、「無料で無害な」一回限りの署名行為のように見えるが、実際に署名する内容は、従来の承認トランザクションを送信するのとまったく同じ効果を生む。つまりリスクをチェックする際は、ウォレットが「トランザクション確認」画面をポップアップ表示する時だけでなく、「署名リクエスト」画面をポップアップ表示する時にも、その中に記載されているspenderアドレス、許可額、コントラクトの所在地を注意深く確認する必要があり、ポップアップが出たら反射的に確認をクリックしてはならない。