見えるセキュリティ
CSRF
クロスサイト・リクエスト・フォージェリ / CROSS-SITE REQUEST FORGERY
この概念とは?
CSRFとは、ログイン済みの利用者のブラウザに、本人が意図していないリクエストを正規サイトへ送らせる攻撃です。ブラウザがCookieなどの認証情報を条件に応じて自動的に付けるため、Serverがそのリクエストを利用者本人の操作として受け入れると、意図しない処理が実行されてしまいます。
「ログイン済みであること」と「その操作を本人が意図したこと」は別です。ブラウザが認証情報を送る流れと、サーバーがCSRFトークンを検証する流れを比べます。
- THEME
- web-vuln
- KIND
- attack
- REVIEW
- self-reviewed ·
ログイン済みのブラウザから意図しない状態変更が送られる流れ
攻撃者がCookieを読むのではなく、ブラウザが条件に応じてCookieを付加する点に注目します。
図の読み方
時間は上から下へ ↓ /「次へ」で1 STEPずつ表示
攻撃者のサイト
罠を用意する
利用者のブラウザ
Cookieを保持する
対象Webサイト
要求を検証・処理する
STEP 1対象サイトへログインしている
ブラウザ内に保持
セッションCookie
対象Webサイトへログイン済み
STEP 01 / 6
対象サイトへログインしている
STEP 1 / 6: 対象サイトへログインしている
利用者は対象Webサイトへログイン済みで、利用者のブラウザにはログイン状態を表すセッションCookieがあります。
技術的な詳細を見る
この例は、ログイン済みのセッションをCookieで識別するWebサイトです。ログイン時などにサーバーのSet-Cookieヘッダーで保存された値が、後の対象サイトへの要求に使われます。図はログイン済みの状態から始め、ログイン処理やCookieの発行通信を省略しています。
この概念の要点
注意
CSRFはCookieの窃取そのものではない
この教材では代表例として、セッションCookieを利用するWebサイトを扱います。攻撃者はCookieの値を知ったり、対象サイトのレスポンスを読んだりする必要はありません。Cookieの送信条件を満たすとブラウザが認証情報を自動的に付加する点が利用されますが、CSRFはCookieを使う場合だけに限定されません。
要点
認証だけではCSRFを防げない
セッションCookieで確認するログイン状態だけでは、CSRFを防げません。この教材の対策側では、セッションに対応するCSRFトークンを検証します。トークンの検証は、本人の意思そのものを証明するものではありません。
要点
Cookieの送信条件も成立可否に関わる
Cookieがクロスサイトのリクエストへ付加されるかは、SameSite属性だけでなくリクエスト方法や遷移方法などにも左右されます。すべてのクロスサイトリクエストでCookieが送られるわけではありません。
理解確認
参考資料
- IPA安全なウェブサイトの作り方 - 1.6 CSRF(クロスサイト・リクエスト・フォージェリ)
CSRFの仕組みと意図しない処理を防ぐ対策
- OWASPCross-Site Request Forgery Prevention Cheat Sheet
CSRFトークンと多層防御の実装指針
- CWECWE-352: クロスサイトリクエストフォージェリ
CWE-352CWE-352の日本語分類とCSRFの定義
- 参考資料Using HTTP cookies
MDN:Cookieによるログイン状態の識別と要求への送信
- 参考資料Set-Cookie header
MDN:Cookieの送信条件、SameSiteとHttpOnlyの役割
- 参考資料Same-origin policy
MDN:他オリジンへの送信と情報の読み取りの違い
- 参考資料Cross-site request forgery (CSRF)
MDN:CSRFの成立条件とフォームへのトークンの組み込み