Hello there, ('ω')ノ
✅ 現代のWebアプリで一般的に導入されているCSRF防御
CSRF攻撃はシンプルですが、その分対策もしやすく、 最近のWebアプリでは防御手段が複数組み合わされていることが一般的です。
以下に、最も一般的な3つの対策を紹介します。
1️⃣ CSRFトークン
🔐 仕組み：
- サーバーが一意・秘密・予測不能なトークンを生成
- フォームやリクエストに隠しフィールドやヘッダーとして埋め込む
- サーバーは受け取ったリクエストのトークンが正しいかどうかを検証
✅ 強力な理由：
| 項目 | 内容 |
|---|---|
| 攻撃者はトークンを知り得ない | 攻撃ページからはサーバーのHTMLにアクセスできないため |
| セッションに紐づいている | 攻撃者がトークンを予測・再利用できない |
| リクエスト改ざんを防止できる | トークンが一致しなければ処理されない |
2️⃣ SameSite Cookie属性（ブラウザのセキュリティ機能）
🔐 仕組み：
- クッキーに
SameSite=LaxやStrictを指定すると、クロスサイトからのリクエスト時にクッキーが自動送信されなくなる
✅ モードの違い：
| 属性 | 挙動 |
|---|---|
SameSite=Lax |
外部ページからのGETリクエストにはクッキーを送らないが、内部ナビゲーションなどには送信 |
SameSite=Strict |
完全にクロスドメインからのリクエストではクッキーを送信しない（最も安全） |
SameSite=None |
クッキーは常に送信されるが、Secure属性が必須になる（HTTPSのみ） |
✅ 実務ポイント：
- Chromeは2021年からLaxをデフォルトに
- ほぼすべての主要ブラウザがこれを標準化しつつある
3️⃣ Referer（リファラ）ヘッダーの検証
🔍 仕組み：
- リクエストのHTTPヘッダーに含まれる
Referer値を確認し、正規ドメインからのリクエストかどうかを検証
⚠️ 限界：
| 問題点 | 説明 |
|---|---|
| Refererが空になることがある | プライバシー設定やHTTPS→HTTP遷移で消えるケースがある |
| 偽装されるリスクがある | JavaScript経由での動作が絡むと信頼性が落ちる |
| CSRFトークンより弱い | 本格的なセキュリティ対策には不十分 |
✅ まとめ：CSRF対策は「多層防御」が鉄則
| 防御策 | 効果 | 推奨度 |
|---|---|---|
| ✅ CSRFトークン | 高精度・確実 | ★★★★★ |
| ✅ SameSite Cookie | ブラウザ側で自動防御 | ★★★★☆ |
| ✅ Referer検証 | 補助的なチェック | ★★☆☆☆ |
「トークン＋SameSiteの併用」が現代の標準防御です。
一方で、CSRFトークンを正しく検証しないケースや誤実装も少なくないため、 ペネトレーションテストではバイパス可能な構造を丁寧に調査する必要があります。
Best regards, (^^ゞ
