はじめに
クロスサイトリクエストフォージェリ (CSRF) 攻撃について学習する備忘録です。
改訂履歴
- 2026/09/17 : 初版公開。
本文
1. 概要
クロスサイトリクエストフォージェリ (Cross-Site Request Forgery / CSRF) 攻撃は、Web アプリケーションがリクエストを送信したユーザーの意図を適切に検証しないことによって、攻撃者が用意した Web ページ等を経由して、被害者のブラウザから意図しないリクエストを送信させる攻撃手法です。
CSRF によって発生する影響は Web アプリケーションの機能によって異なります。例えば、アカウント情報や各種設定の変更、不正送金や不正購入等の操作が、被害者の意図しない形で実行される可能性があります。
この攻撃は主にセッション管理を悪用されて行われる（厳密にはブラウザが認証に必要な Cookie 等の認証情報をリクエストに自動的に付与する性質を悪用する）ため、対策としては、Cookie の SameSite 属性を適切に設定すること、Cookie とは別のトークンを使用すること、重要な操作について再認証や追加の確認を要求すること等が挙げられます。
よく混同されるクロスサイトスクリプティング (Cross-Site Scripting / XSS) 攻撃との違いは、その仕組みです。CSRF はセッションを悪用し「サーバーに意図しないリクエストを送信」させるのに対し、XSS では「ブラウザ上で攻撃者のスクリプトを実行」させます。
2. 攻撃の仕組み
CSRF 攻撃では、概ね次のような流れで攻撃が成立します。
3. 対策
3-1. Cookie の SameSite 属性を指定する
CSRF 攻撃は認証済みの Cookie を悪用することが多いため、正規のサイトが発行する Cookie に SameSite 属性を指定することで、ある程度の対策ができます。SameSite 属性では、サイトをまたがったアクセス（クロスサイト）要求に対して、Cookie をどのように取り扱うかを設定できます。
| 設定値 | 設定説明 |
|---|---|
Strict |
クロスサイトのリクエストでは Cookie を基本的に送信しない。 |
Lax |
クロスサイトのリクエストでは原則として Cookie を送信しないが、トップレベルナビゲーション等の一定の条件では送信される。 |
None |
クロスサイトのリクエストでも Cookie を送信する。現行の一般的なブラウザでは SameSite=None を指定する場合、あわせて Secure 属性も指定する必要がある。 |
SameSite=Lax の場合でも一定のクロスサイトリクエストでは Cookie が送信されるため、SameSite 属性だけで CSRF 対策が完結するとは限りません。
3-2. トークンを使用する
Cookie とは別のトークンを使用することで、CSRF を防御する手法です。サーバー側でセッション等に紐付けた専用のトークンを発行し、hidden フィールド等を利用してリクエストに含め、サーバー側で正しいトークンであることを検証します。攻撃者のサイトからは、通常、正規サイトが発行した有効なトークンを取得できないため、トークンを検証することで意図しないリクエストを拒否できます。
3-3. Origin / Referer の検証
リクエストに含まれる Origin ヘッダーや Referer ヘッダーを確認し、正規のサイトから送信されたリクエストであることを検証する方法です。
Origin ヘッダーは、クロスオリジンのリクエスト等で送信され、リクエストの生成元（スキーム・ホスト・ポート）を確認するために利用できます。一方 Referer ヘッダーには直前に閲覧していた URL が含まれます。ただし Referrer-Policy 等の設定によっては送信されない場合があるため、Referer のみに依存する設計には注意が必要です。
3-4. 再認証や追加の確認を要求する
確定時、パスワードの再入力や CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) を要求することも、CSRF の対策になります。
4. 参考
おわりに
気付きがあれば、追記します。