最初に押さえる判断の軸
CSRFは、利用者がログイン済みのブラウザを利用して、本人の意図しない要求をサービスへ送らせる問題です。Cookieが自動で送信される認証では、ログインしていることだけではその操作を本人が意図した根拠になりません。認証と要求の正当性を分けて検証する必要があります。
対策にはフレームワークの保護機能、CSRFトークン、送信元の確認、SameSite Cookieなどを目的に応じて組み合わせます。SameSiteだけで全ての構成を保護できるとは限りません。状態を変更する操作をGETへ置く問題や、同一サイト内の経路、XSSなども考えます。個別実装より、利用するフレームワークの指針と試験を確認します。
混同しやすい状態を比較する
CSRF対策は認可の代わりではありません。正当な要求でも対象の操作権限があるかを、サーバー側で別に確認します。
- 認証どの主体としてログインしているか。
- 要求の正当性本人の意図した要求か、保護の条件を検証。
- 認可その主体が対象へ操作できるか。
SameSiteの設定だけで、認可や全構成の保護を代替しない。
当サイト独自の説明図。領域の面積や並びは、被害件数・発生確率・出題比率を表していません。
| 確認する対象 | 見落としやすい点 | 判断に使う根拠 |
|---|---|---|
| 認証 | Cookieがあれば本人の意図 | 操作の正当性 |
| SameSite | 単独で全構成を保護 | 要求方式とサイトの境界 |
| 認可 | トークンがあれば全操作 | 対象ごとの権限 |
確認問題
独自ケースで判断を練習する
設定変更のAPIはログインCookieだけを確認します。開発者はSameSiteを設定したので、要求の正当性や状態変更の方式を試験しなくてよいと判断しています。
次のうち、ケースの情報から優先する対応はどれでしょうか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解：1。Cookieは認証の材料で、本人が意図した操作の証拠とは別です。SameSiteの条件とフレームワークの保護を確認し、状態変更の要求を許可された環境で検証します。認可やXSSへの対策も独立して必要です。一つの設定名で全てのWebの問題が解決したと考えないことが大切です。
POINT
当サイト独自の確認問題です。実際の事件・公式問題・過去問を再現していません。
確認と見直しを業務へつなげる
状態変更を行う経路を一覧にし、管理画面だけでなくAPIや古い経路も確認します。正当な操作が失敗しないことと不正な要求を拒否することを分けて試します。
- 1
経路
状態変更と認証方式を洗い出す
- 2
仕組み
フレームワークの保護を確認する
- 3
保護
トークンや送信元・SameSiteを評価する
- 4
認可
認可と正規操作も併せて検証する
実施したことと、結果を確認できたことを区別する。
実操作が必要な項目は管理者の承認と組織の手順に従ってください。
検証は自分が管理または許可された環境で行います。第三者のサービスに無断で操作要求を送ることを学習の確認にしないでください。
実務で見落としやすい条件を掘り下げる
読み取り用に見える経路で設定を変える設計は、要求の分類を難しくします。状態を変更する操作を整理し、フレームワークの想定に合う経路で保護します。例外的なAPIを作った場合も、なぜ同じ保護が適用されるかを確認して記録します。
正規操作の試験だけでは、境界の保護を確認できません。保護に必要な材料が欠けた要求を拒否し、かつ認可のない対象へは進めないことを確かめます。テスト用の主体とデータで行い、実利用者の設定を変更して検証しないようにします。
次に読む記事と、理解の確認
サイバーセキュリティの学習ガイドで、このテーマをメール・ブラウザとWebの中に位置付けてください。関連する前提はセッションタイムアウトの設計、APIのオブジェクトレベル認可で確認できます。
資格対策との接点は情報・サイバーセキュリティ管理士の概要へ。用語を理解した後は登録不要の無料お試し20問で、別の状況でも判断できるか確かめてください。記事のテーマを全て公式の出題項目とする説明ではありません。