Hello there, ('ω')ノ
✅ 問題の本質：リクエストメソッドによってCSRFトークン検証をスキップしている
多くのアプリケーションでは、
- POSTリクエストにはCSRFトークンを求めて厳密に検証するが
- GETリクエストにはトークンを求めない or チェックしないという実装ミスが存在します。
📚 実例：メールアドレス変更リクエスト
GET /email/change?email=pwned@evil-user.net HTTP/1.1 Host: vulnerable-website.com Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
- 本来この操作はCSRFトークンを含むPOSTでなければならないが、
- GETでも同じ処理が通ってしまうため、CSRFトークンの存在意味がなくなっている
🎯 攻撃者のバイパス戦略
| 条件 | 攻撃内容 |
|---|---|
| POST + トークン必須 | 通常は攻撃困難 |
| GET + トークン不要 | URLにパラメータを付けるだけで攻撃可能になる |
✅ 攻撃HTMLの例（画像タグCSRF）
<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">
- 被害者がこのページを読み込むだけでCSRF成立（ノークリック攻撃）
⚠️ なぜこれは危険なのか？
- GETリクエストでも処理内容に副作用（状態変更）があるのは設計ミス
- HTTPの設計思想では「GETは読み取り専用」なので、状態変更を伴う操作にはPOST/PUTなどを使うべき
✅ 防御策（開発者向け）
| 対策 | 内容 |
|---|---|
| 全メソッドに対してCSRFトークン検証を行う | GETでも重要操作なら検証必須 |
| 状態変更を伴う操作にはGETを使わない | POST/PUT/DELETEなどを使う |
| SameSite Cookie設定 | 外部からのGETリクエストでもCookieを送らないよう制御可能 |
| リクエスト制限（CSP/Refererチェック） | 複数層のチェックで補強可能 |
✅ まとめ
「GETだから大丈夫」という思い込みは極めて危険です。
- 状態変更機能がGETで動作するなら、CSRFトークンは無力
- 攻撃者はこの隙をついて画像タグやリンクだけでCSRF攻撃を成立させます
Best regards, (^^ゞ
