CSRF — ログイン中を悪用して「勝手な操作」をさせる

CSRF の根っこは、ブラウザが対象サイトの Cookie を自動で付けるという性質です。あなたが正規サイトにログイン中なら、そのサイト宛のリクエストには（誰が発生源でも）ログイン状態の Cookie が付きます。

1. あなたが正規サイト（例＝銀行）にログイン中
2. 攻撃者の「罠ページ」を開く
3. 罠ページが、こっそり正規サイトへ「送金リクエスト」を送らせる
4. ブラウザが正規サイトの Cookie を自動で付けるので、サーバは本人の操作だと勘違いする

ポイントは、攻撃者は Cookie の中身を盗む必要がないことです。送らせるだけでよい。だから盗聴対策（暗号化）では防げません。

登場人物メモ：

• ※1 自動送信 — ブラウザが対象サイト宛リクエストに Cookie を勝手に付ける挙動
• ※2 安全なメソッド — GET など「取得だけで副作用を持たない」べき操作

対策は「この操作は正規の画面から始まったか」を確かめることに集約されます。

1. CSRFトークン — 推測できない値を正規フォームに埋め、送信時にサーバで照合する。罠ページはこの値を読めないので弾ける。なぜ効くか＝攻撃者が用意できない情報を必須にするため
2. SameSite Cookie — クロスサイト起点の（多くの）リクエストに Cookie を付けない設定。なりすましの前提（自動送信）を崩す（ただし既定の Lax では、リンク等のトップレベル GET 遷移には Cookie が付く。Strict や併用でさらに堅く）
3. Origin／Referer チェック — リクエストの発生源が自サイトかをヘッダで確認する補助策
4. 安全なメソッド設計 — 副作用のある操作を GET にしない。GET は「取得だけ」に保ち、状態変更は POST 等に限る
5. 重要操作は再確認 — 送金などはパスワード再入力や MFA を挟む

• 認証と混同 — ログイン（認証）していても防げない。CSRF は別軸の対策が要る
• GETで状態変更 — 「クリックしただけ」「画像を表示しただけ」で操作が起きる作りは危険（副作用のある操作は GET にしない）
• トークンの置き場所ミス — URL に露出させると Referer 経由で漏れうる。フォーム値やカスタムヘッダで渡す
• SameSite 過信 — 古いブラウザや例外的な遷移では抜ける場合があり、トークンと併用するのが基本