CSRF（クロスサイトリクエストフォージェリ）は、ログイン中の人を利用して、本人のふりで勝手な操作をさせる攻撃です。
初級の解説は準備中のため、初級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
どう起きる？
ブラウザは、あるサイトへのリクエストに、そのサイトのCookie（ログイン状態）を自動で付けます。攻撃者はこれを悪用します。
- あなたが銀行サイトにログイン中
- 別の「罠ページ」を開く
- 罠ページが、こっそり銀行への「送金リクエスト」を送らせる
- ブラウザは銀行のCookieを自動で付けるので、銀行は本人の操作だと勘違いする
アニメーション『CSRFの流れ（ログイン中を悪用）』を開く
- 被害者ブラウザ — 正規サイトにログイン中で、そのサイトのCookieを持っている利用者のブラウザ
- 正規サイト — 本人がログインしているサイト。Cookieが付いていれば本人の操作と信じてしまう
- 罠サイト — 攻撃者が用意したサイトやメール。被害者に勝手なリクエストを踏ませる
0 / 5
どう防ぐ？
- CSRFトークン — 正規の画面に「予測できない合言葉」を埋め、送信時に照合する。罠ページはこの合言葉を知らないので弾ける
- SameSite Cookie — 他サイト起点のリクエストにはCookieを付けない設定
- 重要操作は再確認 — 送金などはパスワード再入力やMFAを挟む
⚠️ 気をつける
- 認証と混同 — ログイン（認証）していても防げない。CSRFは別対策が要る
- GETで状態変更 — 「クリックしただけ」で操作が起きる作りは危険（副作用のある操作はGETにしない）
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. CSRFの代表的な防ぎ方は？
問2. CSRFが悪用するのは？
問3. 「ログイン（認証）さえしていれば、CSRFは自動的に防げる」——この説明は正しい？
問4. 副作用のある操作（送金など）をGETリクエストで実装するのが危険とされる理由は？
問5. SameSite Cookie が果たす役割として正しいのは？
問6. 送金など重要操作でCSRF被害をさらに減らすために追加で挟むとよいのは？
問7. ブラウザが対象サイトへのリクエストに自動で付けてしまう、ログイン状態を表す小さなデータを何と呼ぶか（カタカナで）。
問8. 正規のフォームに埋め込む「予測できない合言葉」で、送信時に照合してCSRFを防ぐ仕組みを何と呼ぶか。