概要

CSRF(Cross-Site Request Forgery)は、攻撃者が罠サイトを通じて、被害者のブラウザから正規サイトへ意図しないリクエストを送信させる攻撃です。被害者はすでに正規サイトにログイン済みであるため、サーバは正当なリクエストと区別できません。

仕組みと動作原理

攻撃の流れ

1. 被害者が正規サイト(bank.example.com)にログイン済み(Cookie保持)
2. 攻撃者が罠サイト(evil.example.com)に誘導
3. 罠サイトが自動的に正規サイトへリクエストを送信(被害者のCookieが添付される)
   例: <img src="https://bank.example.com/transfer?to=attacker&amount=100000">
4. サーバは正規ユーザからのリクエストと認識してしまい処理を実行
CSRF攻撃の流れ
1
被害者
正規サイトにログイン済み
Cookieを保持
2
攻撃者
罠サイトへ誘導
3
罠サイト
正規サイトへ自動でリクエスト送信
被害者のCookieが自動添付される
4
正規サイト
正規ユーザからの操作と誤認して処理を実行

CSRFが成立する条件

  1. 被害者が正規サイトに認証済みセッションを持っている
  2. 攻撃者がリクエストのパラメータを事前に特定できる
  3. サーバがリクエストの出所(Origin/Referer)を検証していない

CSRFとXSSの違い

観点CSRFXSS
攻撃者が利用するもの被害者の認証済みCookieWebサイトの脆弱性
悪意のあるコード実行場所サーバ(被害者に代わって)被害者のブラウザ
攻撃者の目的操作の強制実行情報窃取・改ざん
被害者の視点意図しない操作がされているスクリプトがブラウザで実行される
CSRF と XSS の比較
CSRF XSS
攻撃者が利用するもの
被害者の認証済みCookie
Webサイトの脆弱性
コード実行場所
サーバ(被害者に代わって)
被害者のブラウザ
攻撃者の目的
操作の強制実行
情報窃取・改ざん
被害者の視点
意図しない操作がされている
スクリプトが実行される

対策

CSRFトークン(最も一般的な対策)

1. サーバがランダムなトークンを生成してセッションに保存
2. フォームの hidden フィールドにトークンを埋め込む
3. 送信時にトークンをリクエストパラメータで送る
4. サーバがセッションのトークンと照合して一致すれば正規リクエストと判定

罠サイトは正規サイトの HTML を読み取れないため(Same-Origin Policy)、CSRFトークンを取得できません。

動作
Strictクロスサイトリクエストには一切Cookie送信しない
LaxGETリクエストと直接遷移のみCookie送信(フォームのPOSTはブロック)
None常に送信(Secure属性が必須)

SameSite=Strict は CSRF を効果的に防止しますが、外部サイトからの誘導後に認証状態が維持されない(ログイン画面にリダイレクトされる)ユーザビリティの問題があります。

その他の対策

対策説明効果
Origin/Refererヘッダ検証リクエスト元を確認(偽装可能なケースもあり)
二重送信CookieCookieとフォームパラメータにCookieのコピーを持たせて照合
CAPTCHA人間によるリクエストかを確認○(重要操作のみ)
再認証(パスワード要求)重要操作前にパスワードを再入力させる

SC試験での頻出ポイント

  • CSRF の本質:「Cookie が自動送信される」ことを悪用した攻撃
  • CSRFトークンが有効な理由:Same-Origin Policy により罠サイトはトークンを読み取れない
  • SameSite=Lax のデフォルト化:現代のブラウザの多くが SameSite=Lax をデフォルト設定し CSRF を緩和
  • JSONリクエストとCSRF:Content-Type が application/json のリクエストは通常の HTML フォームから送れないためCSRF が難しい(ただし Preflight の処理に依存)
  • CSRF と XSS の組み合わせ:XSS で CSRFトークンを盗取してからCSRF攻撃を行うパターン

よくある誤問・ひっかけパターン

誤り① 「CSRF は XSS と同じく、サーバへの不正入力を原因とする攻撃である」→ 。CSRF はサーバの脆弱性ではなく、Cookieが自動送信されるブラウザの仕様を利用します。

誤り② 「HTTPS を使えばCSRFを防げる」→ 。HTTPS は通信の暗号化と認証を行いますが、Cookie の自動送信という CSRF の根本原因には対処しません。

誤り③ 「Refererヘッダの検証は確実なCSRF対策である」→ 不十分。Refererが送信されない設定(プライバシー設定・noreferrer)や偽装の可能性もあるため、CSRFトークンと組み合わせて使うべきです。

関連用語

重要キーワード

用語説明
CSRF被害者の認証済みセッションを悪用して意図しない操作を実行させる攻撃
CSRFトークンフォームに埋め込む推測不可能なランダム値。サーバが照合して正規リクエストか確認
SameSite属性Cookieのクロスサイト送信を制御するCookie属性
Same-Origin Policy異なるオリジンのリソースへのアクセスをブラウザが制限するセキュリティ機構
二重送信CookieCookieとフォームパラメータでCookieの値を照合するCSRF対策
Referer検証リクエスト元URLを確認する対策(補完的)