「署名なしで」ウォレットが空になると言われる理由
このガイドの目的: approval、allowance、spender、operator、revoke の仕組みを分解し、
EVM は、同じスマートコントラクト実行ルールを共有する互換ネットワーク群です。
Ethereum、Arbitrum、Optimism、Polygon、BSC などでは、トークンやNFTの操作が許可システムの上に作られています。
approve、allowance、
問題の中心は、「資産を動かすたびに必ず別の署名が出るはずだ」という思い込みです。 ウォレット画面では「許可」「接続」「スワップのために承認」といった普通の操作に見えるため、 ユーザーは送金ではなく、あとから使える権利を契約に記録していることに気づきにくくなります。
ステーブルコインに対する不要な allowance
（コントラクトに記録された、使える最大トークン量）
や、NFTの
Approvals だけでなく、dAppのフロントエンド、ブリッジ、MEV、管理鍵、署名時の操作ミスも同じリスク面に含めて見る必要があります。 DeFiセキュリティのチェックリスト は日本語版が用意でき次第リンクします。
Approval phishing は、approve/permit
（allowanceを作成または変更する操作）
や
approve、permit、
Approval phishing とは何か、そしてなぜ「正直そう」に見えるのか
この章の用語:
- Spender — owner のERC-20トークンを allowance の範囲内で
transferFrom できるコントラクトまたはアドレス。 - Operator —
setApprovalForAll によりNFTコレクション全体を移動できるアドレス。 - Allowance — spender が使える最大量としてERC-20コントラクトに保存される値。
- Revoke — allowance を0に戻す、または operator を無効にして支出権限を止めるトランザクション。
Approval phishing は標準的な権限機構を使うため、署名時点では正規の操作に見えます。資産がすぐ減らないこともあり、危険を見落としやすいのが特徴です。
Approval phishing とは、ユーザーにトークンやNFTを管理する permission、つまり approval/allowance を付与させ、その権限を使って資産を抜き出す攻撃です。危険な操作は「スワップのために承認」「mintのために許可」「claimのために署名」「depositのためにアクセスを許可」といった普通のUI文言に隠されます。
秘密鍵を盗まなくても、攻撃者は十分なことがあります。ERC-20では spender、NFTでは operator に対して、ユーザーが一度だけ権限を付与すれば、その後の引き出しはウォレットの新しい確認画面なしで実行できます。
ブロックチェーン上では、これらのトランザクションは有効です。ユーザー自身がコントラクトの状態を変え、特定アドレスに権限を与えています。そのためウォレットは形式的には「侵入」されておらず、資産は署名の回避ではなく、既に与えられた権限を通じて移動します。
Approve は通常、すぐに資産を移動しません。トークンコントラクトに allowance を記録し、その後 spender が
残高が変わらないため、署名が安全に見えることがあります。しかし unlimited approval や setApprovalForAll では、現在の資産だけでなく将来そのアドレスに入る資産までリスクに入ります。
簡単に言うと: approve は送金ではなく、特定アドレスに支出権限を与える操作です。Approval phishing は、その権限付与をスワップ、mint、claimの普通の手順に見せかける攻撃です。
この攻撃は、正規の権限を使うからこそ危険です。署名のあとに有効な支出権限が残り、それが所有者の参加なしで使われます。
EVMの権限は一回限りのボタンではなく、コントラクトに残る状態です。だから approve は数か月残り、再署名なしで使われることがあります。
EVMの権限: allowance、spender、「無制限approve」の仕組み
EVMの permission は、トークンまたはNFTコントラクトの状態に保存されるレコードです。自分のアドレスと spender/operator が結びつき、どの資産をどこまで動かせるかを決めます。
- ERC-20: approve → allowance → transferFrom
- ユーザーが approve(spender, amount) を呼び、spenderアドレスを指定します。
- トークンコントラクトは allowance、つまり spender が使える最大量を保存します。
- Spender は transferFrom を呼び、allowance が0になるか使い切られるまで新しい署名なしでトークンを移動できます。
- コントラクトが確認するのは allowance であり、各支出ごとに所有者へ新しい署名を求めるわけではありません。
- Allowance は owner → spender → token の組み合わせに紐づく
- 許可は特定トークンと特定 spender のためだけに存在します。
- USDTのapproveはUSDCに影響せず、別のコントラクトにも広がりません。
- 新しいトークンや新しい spender には、別の approve が必要です。
- Unlimited approval は最大値に近い allowance
- 無制限approveでは、allowance に非常に大きな数値が記録されます。
- Spender はそのトークンについて、現在残高と将来入金分を含め、上限内で支出できます。
- サービスを使わなくなっても、revoke するまで権限は残ります。
- NFT: setApprovalForAll は数量制限のない operator 権限
- setApprovalForAll(operator, true) は、NFTコレクション全体について operator を有効にします。
- これは金額や枚数の上限ではなく、setApprovalForAll(operator, false) まで続く状態です。
- Operator が悪用されると、NFTは所有者の新しい確認なしで移動される可能性があります。
ERC-20の unlimited approve は
EVMの権限は長期に残るアクセス権です。Approve は何か月も残り、unlimited は支出可能額を広げ、
Permit署名は、アプリに allowance を設定する権利をメッセージ署名で渡します。アプリはその署名を使い、権限付与と操作を同じトランザクションで実行できます。
Permit、Permit2、メッセージ署名: approveなしで権限が出る仕組み
通常の approve 以外にも、EVMには別トランザクションなしで権限を与える方法があります。ユーザーは メッセージに署名 し、アプリはその署名を自分のトランザクションに入れて、権限付与とスワップ、deposit、claim をまとめて実行します。代表例が permit と Permit2 です。
UX上は便利です。approveのためのガス代や一手間を減らせるからです。しかしフィッシングでは、ユーザーが「メッセージ署名なら送金ではない」と誤解しやすい点が悪用されます。
Permit が危険になる場面
- 署名内容が allowance を作るのに、UIが「claim」「login」「verify」のように見せる。
- spender が実サービスのコントラクトではなく、攻撃者のアドレスになっている。
- 期限やamountが広すぎ、短期操作のはずが長期権限になる。
Permit2 で確認すべき点: Permit2 は複数トークンの権限管理を簡単にする一方で、署名パラメータの確認がさらに重要になります。token、spender、amount、expiration、nonce を読まずに承認すると、普通のapproveと同じか、それ以上の範囲で権限が残ることがあります。
署名メッセージで見るべき項目:
- Spender: 権限を受けるアドレスが公式コントラクトか。
- Token: 権限対象が想定したトークンか。
- Amount: 操作に必要な量だけか、無制限に近い値か。
- Deadline/expiration: 権限が不必要に長く残らないか。
- Chain: 正しいネットワークで署名しているか。
「メッセージ署名だから安全」とは限りません。permit系の署名は、送金トランザクションではなくても、あとから支出に使える権限を作れます。
Permit は便利な仕組みですが、approval phishing では「署名だけ」という心理的な軽さが狙われます。送金ではない署名でも、spender と amount を必ず確認する必要があります。
典型的な approval phishing では、「Claim」「Mint」「Deposit」などの口実で approve、permit、
よくある approval phishing の流れ: 「正しい」署名へ誘導する方法
攻撃は見慣れた画面と通常のワークフローを使います。だから権限付与が、単なるサービス利用の一手順に見えます。
多くの攻撃は同じ順序です。ユーザーをdApp風のページに誘導し、支出権限やoperator権限を作る署名を求め、あとからその権限を使って資産を引き出します。直接送金を求めない点が、見抜きにくい理由です。
- 人気サービスのコピー
- 偽ドメインや広告リンクがDEX、NFTマーケット、claimページのコピーに誘導します。
- 画面は「swapのためのapprove」や「NFT listingのためのsetApprovalForAll」を求めます。
- 署名パラメータの spender/operator は本物のサービスではありません。
- 公式チャネルの侵害やなりすまし
- Discord、Telegram、Xでプロジェクトやモデレーターを装ってリンクを投稿します。
- 「契約移行」「バグ対応」「最後のmint」など、急がせる言葉を使います。
- リンク先は攻撃者アドレスへの approve/permit を要求します。
- サポートを装ったソーシャルエンジニアリング
- 「詰まったトランザクションをキャンセルする」といった理由でDMが届きます。
- 実際には permit や approve を第三者アドレスへ与えさせます。
- 被害者は資産移動ではなく、修復手順だと思って署名します。
- 署名の意味をすり替える
- ウォレット画面が技術的なcallを出すだけで、UIが意味を説明しません。
- ユーザーは spender/operator と限度額を確認せずに承認します。
- リスクは、spender、limit、permission type が見えにくいときに高くなります。
例: ユーザーが「airdrop」ページでClaimを押し、ステーブルコインのunlimited approveに署名します。残高はすぐ変わりません。しかし後日そのアドレスに資金が入ると、spender が
攻撃者はすぐに引き出す必要がありません。残高が増えるまで待ち、権限が残っている間に実行できます。
典型的な手口は、権限付与を普通の操作に見せることです。allowance や operator が有効な限り、攻撃者は新しい確認なしで使えます。
多くの損失は、危険な署名ひとつだけでなく、過去に残した approvals、役割分離のないウォレット、見直し不足が重なって起きます。
ユーザーがやりがちなミス: approvals が蓄積して脅威になる理由
Approvalリスクは一回の操作では終わりません。古い許可が何か月も残り、別の事件や偽UIと組み合わさって損失を大きくします。
- 無制限approveを標準設定として受け入れる。 便利ですが、被害上限も広がります。
- 使い終わったdAppの権限を消さない。 サイトを閉じても、オンチェーン権限は残ります。
- 保管用ウォレットで実験する。 主要資産があるアドレスで新規dAppやairdropを試すと、失敗時の被害額が大きくなります。
- ネットワークごとの権限を見ない。 Ethereumだけ確認しても、Arbitrum、Optimism、Polygon、BSCの権限は別に残ります。
- ウォレット接続解除をrevokeと勘違いする。 接続解除はサイトセッションを消すだけで、allowanceやoperatorを変更しません。
Approval は「いつか使われるかもしれないアクセス権」です。使っていない権限が多いほど、将来の事故で一気に被害へ変わる面積が広がります。
損失を防ぐには、署名する瞬間だけでなく、署名後に何が残るかを確認する必要があります。残るものが allowance や operator なら、定期的なrevokeが必要です。
確認すべき対象は、spender、operator、token、network、amount、expiration です。ブランド名やサイトデザインではなく、オンチェーンに残った権限を見る必要があります。
権限をどこで確認するか: 何をどの順番で見るべきか
Approval の確認は「どのネットワークで、どのトークンに、どのspender/operatorが、どれだけの権限を持つか」を順番に確認する作業です。
1) ERC-20 allowances
最初に確認するのは、ステーブルコイン、主要トークン、流動性の高い資産に対する allowance です。USDT、USDC、ETH系ラップ資産、取引所トークンなどは優先度が高くなります。
- spenderアドレスが公式コントラクトか。
- amount が操作に必要な量を超えていないか。
- 古いdAppに大きな allowance が残っていないか。
2) NFT operators
NFTでは、
- listingが終わったマーケットのoperatorが残っていないか。
- ゲーム、mint、claimで一時的に使ったoperatorが残っていないか。
- 知らないoperatorが有効になっていないか。
3) Permit と期限付き権限
Permit系の署名では、expiration、nonce、spender、amount を確認します。署名がまだ使われていない場合でも、条件が有効ならアプリ側のトランザクションで使われる可能性があります。
- ネットワークごとに確認する。
- 流動性の高いトークンを先に見る。
- 知らないspender/operatorを優先して削除する。
- 長期保管アドレスには不要なapprovalを残さない。
権限確認は、サイトの接続履歴を見るだけでは足りません。コントラクト内の allowance と operator 状態をネットワークごとに見て、不要なものを0またはfalseに戻します。
Revoke は、過去の損失を戻す操作ではなく、今後使える権限を閉じる操作です。ERC-20では allowance を0にし、NFTでは operator をfalseにします。
Revoke の正しい使い方: トークン、NFT、よくある誤解
Revoke は、コントラクト状態を変更して支出権限を止めるトランザクションです。サイトを切断する、アプリを削除する、ブラウザ履歴を消すこととは違います。
| 対象 | 残る権限 | 止め方 |
|---|---|---|
| ERC-20 | allowance(owner, spender) | approve(spender, 0) または revoke ツール |
| NFT | operator status | setApprovalForAll(operator, false) |
| Permit | 署名条件またはPermit2権限 | 期限、nonce、Permit2のallowanceを確認 |
Revoke は既に実行されたトランザクションを取り消しません。将来の支出を止めるだけです。疑わしい権限がある場合は、revokeより先に資産を安全なアドレスへ移す必要があることもあります。
ガス代を節約するために revoke を後回しにすると、権限が残ります。特にステーブルコイン、流動性の高いトークン、NFTコレクションのoperatorは優先して処理します。
Revoke後は、同じdAppを再利用するときに再approveが必要になる場合があります。これは不便ですが、不要な長期権限を残さないためのコストです。
危険な approve を出した可能性がある場合、順番が重要です。権限に触れられる資産を減らし、その後 allowance や operator を閉じます。
危険な approve を出した後の被害縮小プラン
疑わしい権限が既に使える状態なら、資金が入った瞬間に支出される可能性があります。調査より先に、アクセス可能な資産量を減らす判断が必要です。
- 資産をクリーンなアドレスへ移す。 新しいシードフレーズのウォレットなら、古いownerアドレスに紐づく approvals とは切り離されます。
- 危険なアドレスで revoke する。 ステーブルコインと流動性の高いトークンから優先します。
- NFT権限を確認する。 不要な
setApprovalForAll を無効化します。 - dAppセッションを切る。 これは allowance を変えませんが、追加署名の誘導を減らします。
- 環境を分離する。 拡張機能や偽サイトの疑いがある場合は、別ブラウザまたは別端末を使います。
知らない相手からの「テスト送金」「安全確認」「資金回収」に応じないでください。新しい署名や直接送金を取るための口実であることが多いです。
危険な権限を出した後は、allowance/operatorで到達できる資産を減らし、次にrevokeで権限を閉じます。権限が残る間は、新しい確認なしで支出が起こり得ます。
予防の中心は、誰に権限を与えるか（spender/operator）と、どれだけ広い権限を与えるか（allowanceまたは
権限を出しても狙われにくくする予防策
Approval phishing の予防は、ウォレットの役割分離、allowanceの制限、作業後のoperator無効化という実務で決まります。
ウォレットの役割を分ける
保管、取引、実験を同じアドレスで行うと、ひとつの approve が全残高に影響します。役割を分けることで、権限が触れられる資産量を小さくできます。
🧩 3つのアドレス設計
- 保管用: 長期資産、dApp利用を最小化、active approvals を残さない。
- 運用用: 通常のDeFi操作、限定残高、定期的なallowance確認。
- 実験用: airdrop、NFT、新規プロジェクト。失ってよい範囲だけ入れる。
各permissionの範囲を小さくする
信頼できるサービスでも、spender/operatorのバグや侵害を想定します。ERC-20では allowance、NFTでは
- 正確な上限を使う。 allowance は spender が使える最大量です。
- 作業後にallowanceを戻す。
transferFrom の権限を止めます。 - spenderアドレスを見る。 権限は「サイト」ではなく、署名内のアドレスに与えられます。
- setApprovalForAllを作業後に無効化する。 listingやゲームセッション後にoperatorを残さない。
- 急かされて承認しない。 急ぎの文言は署名内容を読ませないために使われます。
いつ approvals を見直すか
- 単発操作の後。 定期利用しないサービスなら、操作後に allowance/operator を閉じます。
- DeFi運用アドレス。 1〜2週間ごとに不要な権限を削除します。
- 実験用アドレス。 新規dAppやairdropの後は毎回確認します。
Approve/permit は特定アドレスへ権利を与え、allowance は限度額を決め、revoke は限度額を0にするか operator を無効化します。
予防は抽象論ではありません。アドレス分離、正確なallowance、作業後のoperator無効化により、再署名なしで支出される資産量を減らせます。
Approve はDeFiの利便性を支える仕組みですが、UXを良くするための長期権限が、そのまま攻撃面にもなります。
仕組みとしての approve: 強みと内蔵されたリスク
Approve があるから、DEX、lending、staking、NFTマーケットは毎回ユーザー資産を直接送金させずに動けます。しかし同じ仕組みが、支出権限の残留というリスクを作ります。
| 強み | リスク | 管理方法 |
|---|---|---|
| スワップやdepositをスムーズにする | spenderが広い権限を持つ | 必要量だけapprove |
| 複数操作をまとめやすい | 署名内容が読みづらくなる | spender、amount、期限を見る |
| NFT listingを簡単にする | operatorが全コレクションを動かせる | 取引後に無効化 |
つまり approve は「悪い機能」ではありません。問題は、ユーザーが権限の残り方を見ず、アプリが必要以上に広い権限を求め、古い権限が放置されることです。
DeFiの便利さは、コントラクトがユーザー資産に限定的にアクセスできることから生まれます。安全性は、その限定が本当に限定されているかに依存します。
Approve を使うなら、支出権限を一時的かつ最小限にする設計が必要です。無制限かつ長期の権限は、将来の攻撃やバグの被害上限を引き上げます。
実際の被害は、いつも「悪いコントラクト」だけで起きるわけではありません。古い権限、フロントエンドの差し替え、管理鍵、偽サポートが組み合わさります。
ケースと教訓: 「正しいコントラクト」でも問題になる理由
Approvalリスクは積み上がります。今は安全に見える権限でも、あとからUI、spender、operator、プロトコル管理が変わると、被害の入口になります。
ケース1: 古いDEX allowance
ユーザーが数か月前にDEXへunlimited approveを出し、その後サービスを使わなくなりました。残高が増えたあと、偽フロントエンドや悪意あるspenderに誘導されると、古い権限がそのまま資産移動に使われます。
使っていないサービスの allowance は、残高が増える前に閉じるべきです。
ケース2: NFT marketplace operator
NFTをlistingするために
NFTのoperatorは数量制限がないため、取引後の無効化が必須です。
ケース3: ClaimページのPermit
偽airdropページが「claim」と表示し、実際にはpermit署名を求めます。残高はすぐ変わらないため安心しがちですが、署名条件が有効な間にアプリ側が権限付与トランザクションを送れます。
メッセージ署名でも spender、amount、expiration を確認します。
ケース4: サポートを装うDM
「出金が詰まっている」「トランザクションを解除する」と称して、署名ページへ誘導されます。ユーザーは修復だと思って署名しますが、実際には権限を作っています。
サポートDMから署名ページへ行かない。公式URLと署名内容を別々に確認します。
実務上の見方: approvals は蓄積リスクです。権限が広く、長く残るほど、正規サービスでさえ事故時の被害源になり得ます。
実際のインシデントでは、コントラクトの良し悪しだけでなく、過去に出した権限が鍵になります。定期的な監査とrevokeは、被害の最大値を下げるための基本作業です。
FAQでは、どの署名が権限を作るのか、revokeが何を変えるのか、なぜ再確認なしで支出が起きるのかを整理します。
Approval phishing、approve、revoke のFAQ
「署名なしで抜かれた」と言うのは、何かには署名したのでは？
多くの場合、署名したのは送金ではなく権限付与です。approve、permit、
Unlimited approve は常に間違いですか？
必ずしも機能として間違いではありませんが、allowance に非常に大きな値を入れるため、spenderが使える最大量が広がります。必要量だけのapproveの方が被害上限を小さくできます。
Revoke は盗まれた資金を戻せますか？
戻せません。Revoke は将来の状態だけを変えます。allowance を0にする、またはoperatorを無効にする操作であり、既に実行されたトランザクションは取り消せません。
ウォレット削除やサイト切断で approvals は消えますか？
消えません。権限はトークンやNFTコントラクトのオンチェーン状態に保存されています。サイト切断やアプリ削除は、allowanceやoperatorを変更しません。
Approve はどこに保存されますか？
スマートコントラクトの状態です。ERC-20では allowance(owner, spender)、NFTでは approvals と operators が該当します。
Approve を特定金額に制限できますか？
できます。approve の amount が allowance になります。spender は現在の allowance を超えて支出できません。
トークンapproveとNFTのsetApprovalForAllはどちらが危険ですか？
多くの場合、
L2やサイドチェーンでも approvals を確認すべきですか？
はい。各ネットワークは独自のコントラクト状態を持ちます。EthereumのallowanceとArbitrumのallowanceは別物なので、1つのネットワークだけ見ても十分ではありません。
ハードウェアウォレットなら approval phishing を防げますか？
ハードウェアウォレットは秘密鍵と署名プロセスを守りますが、署名する内容の意味は変えません。危険な approve/permit や
FAQの要点は、署名が必ず送金を意味するわけではないという点です。権限付与の署名は、あとから使える支出権限をコントラクトに残します。
誤った approve/permit または
Approval phishing から身を守り、権限を管理する方法
Permission はDeFiの土台ですが、allowance と operator 状態こそが、不要なアドレスへ権限を渡したときに資産を動かせる原因になります。
Approval phishing は、正規の権限を悪用する攻撃です。一度の approve/permit または
アドレスに危険な権限を残さないため、次の操作を習慣にします。
- アクセス先アドレスを確認する。 重要なのはブランドやデザインではなく、署名内とapprovals一覧の spender/operator です。
- Allowanceを制限する。 unlimitedではなく作業に必要な上限を設定し、不要になったら0に戻します。
- NFT operatorを無効化する。
setApprovalForAll を取引後に残さない。 - 全ネットワークを見る。 allowance と operator はネットワークごとに別々です。
- ウォレットを役割で分ける。 アドレス上の残高が、active rightsで到達できる最大額になります。
Approvals は、コントラクトに記録された有効なアクセス権として扱います。最小限の allowance、operator無効化、全ネットワークの見直しにより、再署名なしで支出される資産量を小さくできます。