接続・署名・Claimの前に、最低限どんなフィッシング対策をすればいい？

結論（Conclusion）

フィッシングはだいたい同じ流れ。

• 偽の入口 → 接続/署名させる → 権限で抜く

だから防御は2つに集約できる。

1. 入口（URL）を固定する（ブックマーク/公式ソース）
2. 署名前に権限を読む（Approve/Permit/SetApprovalForAll）

違和感が出たら止める。押し切らない。

背景（Explanation）

危ないのは送金（Transfer）より 承認（Approval） であることが多い。

代表的に危険な権限：

• Approve（ERC-20）：トークン支出権限（無制限が特に危険）
• Permit（EIP-2612系）：署名だけで承認が成立
• SetApprovalForAll（NFT）：コレクション単位の移転権限

目的は「怪しいコントラクトに権限を渡さない」こと。

実務手順（Practical Guide）

手順1：入口を固定する（クリック前）

• 検索結果（特に広告）から入らない
• 入口はこれだけ：
  • 公式Docs
  • 公式X/Discordの固定メッセージ
  • 自分のブックマーク（最強）
• ドメインを声に出して読む（似た文字に強い）
• サブドメイン偽装に注意（official.example.com.attack.tld）

手順2：露出を減らす（接続前）

• 常時接続しない
• ウォレットを用途で分ける：
  • メイン資産（触らない）
  • 実験用（エアドロ/DeFi）
• チェーン/アカウントが想定通りか確認

手順3：署名画面で権限意図を読む（署名前）

見ること：

• Approve / Permit / SetApprovalForAll が含まれていないか
• 無制限（Unlimited）になっていないか
• spender/contract が正規アプリに見えるか

迷ったら：

• キャンセル
• 別端末で公式URL確認
• 公式Docsに同じ操作が載っているか確認

手順4：万一を小さくする（操作後）

• Disconnect
• 権限棚卸し（毎月、エアドロ勢は毎週）

失敗パターン（Pitfalls）

• 公式っぽい広告が検索上位
• DMサポート誘導（基本詐欺）
• 焦らせる文言（今だけ、期限）

チェックリスト（Checklist）

• [ ] 入口はブックマーク/公式ソース（広告/検索から入らない）
• [ ] ドメイン確認（似た綴り/サブドメイン偽装）
• [ ] ウォレットは常時接続しない
• [ ] チェーン/アカウント確認
• [ ] 用途分離（メイン/実験）
• [ ] 署名画面でApprove/Permit/SetApprovalForAllを確認
• [ ] 無制限承認を避ける（意図がない限り）
• [ ] spender/contractを確認（不明なら中止）
• [ ] 操作後にDisconnect
• [ ] 権限棚卸しの頻度が決まっている
• [ ] revokeの手順/ツールを把握している

FAQ

Q1. 「リンクを踏むな」は現実的？

現実的ではない。現実的なルールは「入口を固定して毎回ドメイン確認」。

Q2. なぜ承認の方が危ない？

送金は一回だが、承認は継続的に抜かれる権限になり得る。放置すると被害が広がる。

Q3. すでに署名してしまったら？

追加操作を止めて、承認を確認して怪しいものはrevoke。必要なら資産を安全なウォレットへ退避。

内部リンク（Internal links）

• 親記事（Hub）：Web3安全運用：まずはここから
• 関連記事：
  • エアドロの安全なClaimチェックリスト
  • 署名（Sign）画面の読み方
  • EVMのトークン承認（Approve）を見直す方法

参考（一次情報）

• MetaMask Security: https://support.metamask.io/
• EIP-2612 Permit: https://eips.ethereum.org/EIPS/eip-2612

免責

投資助言ではありません。セキュリティの一般的な注意喚起です。