クロスサイト・リクエスト・フォージェリ（CSRF）

概要

クロスサイトリクエストフォージェリ（Cross-Site Request Forgery：CSRF）とは、攻撃者がユーザー本人に代わって不正なリクエストを送信させる手法です。攻撃者自身がサーバーを乗っ取るのではなく、すでに認証済みのユーザーを“踏み台”として利用します。

具体的には、以下のような手順で攻撃が行われます。

実際の被害の具体例としては以下のようなものがあげられます。

対策は大きく「クライアント（利用者）側」と「サーバー（管理者）側」に分けられます。

不要なログイン状態の回避
- 利用後は必ずログアウトする。
- 公共の端末や共有PCでは、ブラウザを閉じるだけでなく、明示的にログアウトを行う。
ブラウザ設定の見直しや拡張機能の利用
- サードパーティCookieをブロックする（プライバシー設定で「サードパーティCookieを許可しない」等）。
- SameSite属性付きクッキーの挙動をサポートする最新ブラウザを利用する。
- NoScript や uBlock Origin といったスクリプト制御・広告ブロッカーで、外部サイトからの意図しないリクエスト発行を制限する。
リンクやフォームの取り扱いへの注意
- メールやSNSで送られてきた怪しいリンクは開かない。

CSRF トークンの導入（ワンタイムトークン）
- フォーム送信やリクエストごとにサーバーがランダムなトークンを発行し受信時に必ず検証する。
- トークンは一度しか使えない／短時間で期限切れになるようにし、不一致や未送信の場合はリクエストを拒否する。
SameSite 属性付きクッキーの設定
- セッション管理用クッキーにSameSite=Strict（またはLax）を設定することで厳密に管理する。
  - Strict：完全にクロスサイト送信をブロック（ただしメールやSNSリンク経由でもログイン状態が維持されない場合あり）。
  - Lax：通常のリンク移動（GET）ではクッキーを送信し、その他のクロスサイトリクエスト（POSTや画像読み込みなど）をブロック。
Origin/Referer ヘッダー検証
- リクエストに含まれる Origin ヘッダー（スキーム＋ホスト＋ポート）を優先してチェックし、自ドメイン以外であればリクエストを拒否する。
- Originがない場合はRefererヘッダー（直前に閲覧していたページのURL）を確認し、自ドメイン起点でないときは拒否する」。
- HTTPSで常時運用し、ヘッダー省略や改ざんを想定して他の対策と必ず併用する。

名前や内容が類似しているクロスサイトスクリプティング（XSS）との比較表を以下に示します。

項目	CSRF	XSS
攻撃の主体	外部サイトやメールから仕込まれたリクエスト	悪意あるスクリプト（JavaScript など）をウェブページに注入
攻撃対象	ログイン中のユーザーが意図せず実行するアクション	表示部分の脆弱性を突いたスクリプト実行
脆弱性の原因（発生条件）	認証後セッション継続が条件（特にページの脆弱性は不要）	入力値の適切なサニタイズ／エスケープ不足
主な被害	送金指示や注文、設定変更などユーザー権限で可能な操作の横取り	クッキーの窃取、画面改ざん、フィッシング誘導など
主な対策	CSRF トークン、SameSite、Referer チェック等	入力値のエスケープ、コンテンツセキュリティポリシー（CSP）