CSRFとは

詳細な図解

CSRFを読むときの前提

CSRF（Cross-Site Request Forgery）は、ログイン済み利用者のブラウザに意図しない操作を送らせる攻撃です。管理画面、設定変更、申請、承認、送金、メールアドレス変更など状態変更操作で重要です。

実務では、CSRF token、SameSite、Origin/Referer検証、再認証、HTTPメソッド、Cookie送信条件、CORSとの違いを確認します。

証跡には、対象操作、HTTPメソッド、Cookie送信有無、CSRF token有無、Origin/Referer、SameSite、再現HTML、成功/拒否結果を残します。

ログイン済みCookieが送られる前提を見る

CSRFは、攻撃者がCookieを盗む必要はありません。利用者のブラウザが正規サイトへCookieを自動送信する性質を使い、意図しない状態変更を狙います。

GETで状態変更できる、POSTでもCSRF tokenがない、SameSiteが緩い、Origin検証がない場合は注意します。読み取りAPIよりも状態変更操作を優先して確認します。

• 状態変更操作を洗い出す。
• Cookie送信条件を確認する。
• GETで変更していないか確認する。

CSRF tokenとSameSiteを併用する

CSRF tokenは、正規画面から発行された値を状態変更時に検証する仕組みです。SameSiteはCookie送信条件を絞り、攻撃成立条件を減らします。

どちらか一方だけに頼るより、重要操作ではtoken、SameSite、Origin/Referer、再認証を組み合わせます。外部IdPや決済戻りでSameSiteを緩める場合も、状態変更側のtoken検証を残します。

• tokenが利用者セッションと紐付くか確認する。
• SameSite値を確認する。
• Origin/Referer検証を確認する。

CORSと混同しない

CORSはブラウザがJavaScriptへ応答を渡すかを制御する仕組みで、CSRFそのものを防ぐ仕組みではありません。CORSで読めなくても、リクエスト自体は送られる場合があります。

認証付きAPIでは、CORS許可、SameSite、CSRF token、Authorization方式をまとめて確認します。SPAではプリフライト成功とCSRF防御を分けて見ます。

• CORS成功をCSRF対策とみなさない。
• リクエスト送信と応答読取を分ける。
• 認証方式ごとの対策を確認する。

変更証跡と引き継ぎ

CSRF対応では、対象操作、対策方式、除外理由、外部連携影響、テスト結果、監査ログを残します。状態変更操作は業務影響が大きいため、例外を作る場合は理由が必要です。

引き継ぎでは、アプリ担当、認証基盤担当、セキュリティ担当、関連語としてSameSite、Cookie、Origin、CORSを残すと確認しやすくなります。

• 状態変更APIの一覧を残す。
• token検証の失敗ログを確認する。
• 外部連携の例外を記録する。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能