// シス担のミカタ
Webアプリケーション攻撃

CSRF（クロスサイトリクエストフォージェリ） くろすさいとりくえすとふぉーじぇり

クロスサイトリクエストフォージェリセッショントークン不正リクエストWebセキュリティ認証
CSRFについて教えて

簡単に言うとこんな感じ！

ログイン中のあなたを「罠サイト」に誘い込んで、あなたが気づかないうちに別のサービスに「勝手に操作」をさせる攻撃だよ！本人が操作したように見せかけるから、サービス側もなかなか気づけないんだ。

CSRFとは

CSRF（Cross-Site Request Forgery：クロスサイトリクエストフォージェリ） は、ログイン済みのユーザーを悪意あるWebページに誘導し、そのユーザーが意図しない操作を正規サービスに対して実行させる攻撃手法です。日本語では「クロスサイトリクエスト強要」とも呼ばれます。

Webサービスは「ログイン中のユーザーからのリクエストは本人のもの」として処理します。CSRFはこの仕組みを悪用し、ブラウザが自動的にセッション情報（Cookieなど）を送信する性質を利用して、被害者に気づかれないまま不正な操作を実行させます。たとえば、銀行サービスにログイン中のユーザーが罠サイトを開いただけで、攻撃者の口座への送金リクエストが送られてしまうといった被害が起こり得ます。

パスワードを盗む攻撃とは異なり、CSRFは「正規ユーザーの権限そのものを乗っ取る」攻撃です。ユーザー自身は何も入力していないのに操作が成立するため、被害に気づきにくいという特徴があります。

CSRFの仕組み・攻撃の流れ

攻撃が成立する3つの条件

条件内容例
① ユーザーがログイン済み対象サービスにセッションが存在するネットバンキングにログインしたまま
② Cookieが自動送信されるブラウザがCookieを自動的に付与するセッションCookieが有効
③ リクエストの正当性を検証しないサーバー側が「誰が送ったか」を確認しないトークンなどの対策がない

攻撃の流れ（ステップ）

[1] ユーザーが正規サービスにログイン
      ↓
[2] ログインしたまま、罠サイトを開く（メールのリンク・広告など）
      ↓
[3] 罠サイトが自動的に正規サービスへリクエストを送信
    （例: <img src="https://bank.example/transfer?to=attacker&amount=100000">）
      ↓
[4] ブラウザが自動でCookieを添付して送信
      ↓
[5] 正規サービスは「本人のリクエスト」と判断して処理実行
      ↓
[6] ユーザーは知らないうちに送金・設定変更・投稿などが完了

被害の具体例

対象サービス起こりうる被害
ネットバンキング不正送金
ECサイト住所変更・不正購入
SNS意図しない投稿・フォロー
社内システム設定変更・データ削除
メールサービス転送設定の変更

覚え方

「C」ross-site「S」ite「R」equest「F」orgery＝「他のサイトから偽のリクエスト」

語呂合わせ：「クロス（×）サイトで、スリ（SR）してフォージェリ（偽造）」
＝ 別サイトから、こっそり偽のリクエストを送る攻撃！

歴史と背景

  • 2001年頃 — CGI全盛期に概念が認識され始める。フォーム送信の仕組みを悪用した攻撃として報告される
  • 2004年 — セキュリティ研究者Peter Watkins がCSRFという名称を正式に広める
  • 2007年 — GMail・NetflixなどのメジャーサービスでCSRF脆弱性が発見・報告され、業界に衝撃を与える
  • 2010年 — OWASP（Webセキュリティの国際標準団体）が「OWASP Top 10」に CSRFをランクイン。開発者への周知が加速
  • 2013年 — RailsなどのWebフレームワークがCSRFトークン検証をデフォルトで組み込み始める
  • 2016年頃 — SameSite Cookie属性が提案・実装され始め、ブラウザレベルでの対策が広まる
  • 2021年 — OWASP Top 10から独立項目としては除外（対策が普及したため）。ただし依然として発生し続けており注意が必要

CSRFの対策方法と比較

主な対策は「サーバー側の検証強化」と「ブラウザ側の制御」の2方向があります。

CSRF対策の2つのアプローチ サーバー側の対策 ① CSRFトークン フォームに秘密の使い捨て文字列を 埋め込み、送信時に一致を確認 ② Refererヘッダー検証 リクエスト元のURLを確認して 外部サイトからの送信を拒否 ③ Double Submit Cookie CookieとリクエストのトークンをW で送り両方が一致するか確認 ④ カスタムリクエストヘッダー APIで独自ヘッダーを必須にする ブラウザ側の対策 ① SameSite Cookie属性 Strict: 外部サイトからのCookie送信を完全拒否 Lax: 一部の安全なリクエストのみ許可 None: 制限なし（HTTPS必須） ② CORS設定 許可するオリジン（送信元）を サーバー側で厳密に限定する ③ ブラウザのデフォルト強化 Chrome等が SameSite=Lax を デフォルト化（2020年〜） ★ 現在は①CSRFトークン ＋ SameSite属性 の組み合わせが推奨 ★ フレームワーク（Rails/Spring等）は自動対応済みが多い

CSRFトークンの仕組み（最も一般的な対策）

[サーバー] フォームを返すとき、秘密のトークンを埋め込む
  ↓
<form>
  <input type="hidden" name="csrf_token" value="a1b2c3d4e5f6（ランダム文字列）">
  <input type="text" name="amount">
  <button>送金する</button>
</form>
  ↓
[ユーザー] フォーム送信 → トークンも一緒に送られる
  ↓
[サーバー] トークンが正しいか照合 → 一致すれば処理、不一致なら拒否
  ↓
[攻撃者] 罠サイトからはトークンの値が分からないので攻撃が成立しない！

XSSとCSRFの違い

項目XSSCSRF
正式名Cross-Site ScriptingCross-Site Request Forgery
狙いユーザーのブラウザで悪意あるスクリプト実行ユーザーの権限で不正リクエスト送信
主な被害Cookie盗難・画面改ざん不正操作・設定変更・送金
対策の方向出力のエスケープトークン検証・SameSite属性
攻撃の起点正規サービスにスクリプトを注入外部の罠サイトからリクエスト送信

関連する規格・RFC

規格・RFC番号内容
RFC 6265HTTP Cookie の仕様（SameSite属性の基礎）
RFC 7231HTTP/1.1 セマンティクス（Refererヘッダーの定義）
OWASP CSRF Prevention Cheat SheetCSRFトークン実装のベストプラクティス集
SameSite Cookie（RFC草案）Cookie の SameSite 属性の標準化

関連用語