CSRFは、利用者のブラウザに、本人が意図しない要求を送らせる手口です。攻撃者はパスワードもCookieも盗みません。ログイン済みのブラウザなら、Cookieは勝手に付いて出ていく——この当たり前の仕組みだけを利用します。だから「盗まれていないのに操作された」という形になります。
先に押さえる
ブラウザは、そのサイト宛の要求なら、どのページから出た要求でもCookieを付けます。攻撃者のページに置かれた画像タグやフォームでも、宛先が標的サイトならログイン済みの資格情報が同乗します。標的サイト側から見ると「正しいセッションから来た、正しい形の要求」なので、中身だけでは見分けられません。
動きで見る
1利用者は先に標的サイトへログインしている
利用者のブラウザ標的サイトのセッションCookieを保持
2攻撃者のページを開かせる
攻撃者のページ標的サイト宛の要求を自動で出す仕掛けを置く
↓利用者がリンクを踏む／広告や掲示板から誘導される
利用者のブラウザ言われたとおり標的サイトへ送る
3標的サイトは「本人の操作」として処理する
利用者のブラウザCookieが自動で付く
↓パスワード変更・送金・設定変更などの更新要求
標的サイトセッションは正しい → 実行してしまう記録には本人の操作として残る
つまずきポイント
XSSと混ざりやすい所です。XSSは「標的サイトの中でスクリプトが動く」ので、画面の内容もCookieも読めます。CSRFは「外から送らせる」だけで、応答は攻撃者に見えません。読めないのに実行はできる——だから被害は参照ではなく更新に出ます。「情報が漏れたか」ではなく「何をさせられたか」を追うのが読み筋です。
効く対策と、効かない対策
効く
- 秘密のトークンを画面に埋める：正規の画面を経由しないと値が分からない。要求と一緒に送らせて照合する
- Cookieの送信範囲を絞る：他サイトからの遷移では送らない設定にする
- 重要操作で再認証：パスワードや追加の確認を挟む
効きにくい
- 参照元の情報だけに頼る：付かない・消される場合があり、判定材料として弱い
- 更新をPOSTにするだけ：攻撃者のページからでもPOSTは作れる
- 入力値の検査：値は正しいので止まらない（これは注入対策）
見抜きどころ
答案では「その要求が、自サイトの正規の画面から出たものだと確かめる」という言い方が芯です。トークンが効くのは、攻撃者が事前に知り得ない値だから。ここを「本人確認をする」と書くと、CSRFは本人のブラウザが送っているので的を外します。誰が送ったかではなく、どこから来たか——この置き換えが決め手です。