はじめに
―「ログイン中」を悪用する、最も誤解されやすいWeb攻撃―
Web セキュリティを学び始めると、必ず出てくる CSRF。
- XSS と混同されがち
- 「Cookieが原因？」とぼんやり理解されがち
- SPA / API 時代になって「もう不要では？」と誤解されがち
しかし現実には、今でも事故が多い脆弱性です。
この記事では、
- CSRF の正体
- なぜ起きるのか
- なぜ Same-Origin Policy では防げないのか
- 実務で「確実に防ぐ」設計
を 図と実例ベースで整理します。
1. CSRFとは何か（本質から）
CSRF（クロスサイト・リクエスト・フォージェリ） とは、
ユーザーがすでにログインしている状態を悪用し、
本人の意思とは無関係な操作を「本人として」実行させる攻撃
です。
重要なのは次の一点：
なりすましログインではない
正規ログイン状態の“横流し”
2. なぜCSRFは成立するのか
キーワードはこの3つ
- ブラウザ
- Cookie
- 自動リクエスト
3. 攻撃の全体像（時系列）
Step 1：ユーザーが正規サイトにログイン
https://bank.example
- セッションCookieが保存される
- 例：
session_id=abc123
Step 2：別タブで攻撃者サイトを開く
https://evil.example
ユーザーは 何かをクリックした意識すらない。
Step 3：攻撃者サイトに仕込まれたHTML
<img src="https://bank.example/transfer?to=attacker&amount=100000">
もしくは：
<form action="https://bank.example/transfer" method="POST">
<input type="hidden" name="to" value="attacker">
<input type="hidden" name="amount" value="100000">
</form>
<script>
document.forms[0].submit();
</script>
Step 4：ブラウザが勝手にやること
- HTMLを解釈
- リクエスト送信
- Cookieを自動添付
POST /transfer
Cookie: session_id=abc123
Step 5：サーバーの誤認
Cookie正しい → 本人操作だ！
攻撃成功
4. 「攻撃者が送っている」のではない
ここが最重要ポイント。
❌ 攻撃者サーバー → 被害サイト
⭕ ユーザーのブラウザ → 被害サイト
攻撃者は リモコンを渡しただけ。
実際にボタンを押したのはブラウザ。
5. Same-Origin Policyはなぜ無力か？
多くの人がここで誤解します。
Same-Origin Policy が守るのは：
| 許可 | |
|---|---|
| 他サイトへのリクエスト送信 | ⭕ |
| 他サイトのレスポンス参照 | ❌ |
つまり：
<form action="https://victim.example/delete">
これは 完全に合法。
SOPは「見るな」
CSRFは「押すな」
守備範囲が違います。
6. 被害が起きやすい操作
- パスワード変更
- メールアドレス変更
- 送金
- 管理画面操作
- 権限変更
特に危険：
GET /deleteUser?id=1
GET × 副作用 = CSRF即死
7. CSRFとXSSの違い（混同禁止）
| CSRF | XSS | |
|---|---|---|
| 攻撃元 | 外部サイト | 被害サイト内 |
| Cookie | 自動送信 | JSで盗む |
| 主目的 | 操作強制 | 情報窃取 |
| 対策 | CSRFトークン | エスケープ/CSP |
XSSがあるとCSRF対策は突破される
8. CSRF対策の本質
CSRF対策とは何か？
「この操作は本当に、この画面から来たか？」
をサーバーが確認すること
9. 王道対策①：CSRFトークン（最重要）
仕組み
- フォーム表示時にランダム値生成
- セッションに保存
- リクエスト時に照合
<input type="hidden" name="csrf_token" value="RANDOM">
攻撃者サイトは この値を取得できない。
これが最強
10. 王道対策②：SameSite Cookie
Set-Cookie: session=abc; SameSite=Lax
| 設定 | 効果 |
|---|---|
| Strict | クロスサイト完全拒否 |
| Lax | ほぼCSRF防止 |
| None | CSRF防止なし |
現代ブラウザでは Laxがデフォルト
11. 補助対策
Origin / Referer チェック
Origin: https://example.com
- 自ドメイン以外拒否
- プロキシで消えることあり
単独では弱い
12. SPA / API時代のCSRF
誤解されがちですが：
| 認証方式 | CSRF |
|---|---|
| Cookie + Session | 必須 |
| Cookie + JWT | 必須 |
| Authorization Header | 原則不要 |
⚠️ Cookieを使う限りCSRFは生きている
まとめ
- CSRFは「認証済み」を悪用する
- 攻撃者は送らない、ブラウザが送る
- SOPでは防げない
- CSRFトークン + SameSite が鉄板
「ログインしている＝安全」
それを信じた瞬間、CSRFは勝つ。