クロスサイトリクエストフォージェリ(CSRF)
Cross-Site Request Forgery (CSRF)
ログイン済みのユーザーのブラウザを悪用し、本人が意図しないリクエスト(送金・設定変更など)を勝手に送らせる攻撃。Cookieが自動送信される性質を突く。防御はCSRFトークンとSameSite Cookie。
CSRFとは何か(たとえ話)
**CSRF(Cross-Site Request Forgery, シーサーフ)**は、ログイン済みのあなたのブラウザを利用して、あなたが頼んでもいない操作を勝手に実行させる攻撃です。
たとえ話: あなたが銀行サイトにログインしたまま(セッション有効)、別タブで攻撃者の罠ページを開いたとします。その罠ページには『あなたの銀行口座から攻撃者へ送金する』リクエストを自動で送る仕掛けが隠れています。ブラウザは銀行のCookieを自動で付けて送るため、銀行サーバから見ると『本人からの正規の送金依頼』に見えてしまう——これがCSRFです。
ポイントは、攻撃者はあなたのパスワードもCookieの中身も知らなくていいこと。ただ『ブラウザがCookieを自動送信する』性質を悪用するだけで成立します。
図を描画中...
XSSとの違い(混同注意)
この2つは必ずセットで問われます。
| XSS | CSRF | |
|---|---|---|
| 何をする | 攻撃者のスクリプトを実行させる | 被害者になりすまして偽リクエストを送らせる |
| 攻撃者が必要なもの | スクリプトを注入できる隙 | 被害者がログイン中であること+罠を踏ませる |
| 主な防御 | 出力エスケープ、CSP | CSRFトークン、SameSite Cookie |
一言でいうと、XSSは『コードを動かす』、CSRFは『本人になりすます』。
防御1: CSRFトークン
仕組みはシンプルです。サーバが**ランダムな合言葉(トークン)**を発行し、正規のフォーム/ページに埋め込んでおきます。リクエストが来たら、その合言葉が一致するか確認します。
罠サイトはこの合言葉を知らない(別オリジンからは読めない)ので、偽リクエストには正しいトークンを付けられず、サーバに弾かれます。『正規の画面を経由した証拠』を要求する、という発想です。
防御2: SameSite Cookie
もっと根本的な対策。Cookieに SameSite 属性を付けると、別サイト発のリクエストにはCookieを自動送信しないようブラウザに指示できます。CSRFは『Cookieの自動送信』を悪用する攻撃なので、その自動送信を止めれば成立しなくなります。
SameSite=Strict: 別サイトからのリクエストには一切Cookieを送らない。最も安全だが、外部リンクから来た時にログインが切れて見える等、使い勝手が落ちる。SameSite=Lax: 通常のリンク遷移(GET)では送るが、フォーム送信などの危険な操作では送らない。実用上の落とし所で、近年のブラウザの既定値。
さらに、送金など**特に重要な操作では再認証(パスワード再入力)**を求めると、なりすましをもう一段防げます。
つまずきポイント
- CSRFは『読み取り』ではなく『状態変更』を狙う。送金・パスワード変更・退会など『副作用のある操作』が標的。だからGET(参照)よりPOST/PUT/DELETE(変更)に対策が要る。
- トークンとSameSiteは併用が安心。SameSiteはブラウザ依存・例外もあるので、CSRFトークンと多層で守るのが定石。
- CORSはCSRF対策ではない。CORSはブラウザがレスポンスを読めるかを制御するだけで、リクエストの送信自体は止めません。混同注意(CORSは別項)。
📊 図解
CSRF 攻撃の流れ(シーケンス図)
被害者が罠ページを開くと、ブラウザが Cookie を自動付与して正規サイトへ送信します。
図を描画中...
防御後の流れ(CSRFトークンで検証)
正規画面を経由した証拠であるトークンを要求し、罠サイトのリクエストを弾きます。
図を描画中...