目次
管理画面へログインした利用者が、別のサイトを開いたことをきっかけに、意図しないメールアドレス変更や設定更新を実行させられる。CSRFは、認証情報を直接盗むことだけを狙う攻撃とは違い、ブラウザーが送る資格情報を利用して、本人の意思とは違う操作を成立させる問題です。
本稿は2026年10月18日にOWASPとMDNの資料を確認した実務解説です。新しい事件や特定製品の脆弱性の速報ではありません。以下の会員サイトは説明用の仮想例、実装の点検順序と試験表は本サイトの提案です。
スポンサーリンク
認証・認可・操作の意思を三つに分ける
認証は誰かを確認し、認可はその人が対象へ何をしてよいかを判断します。CSRF対策は、それらが成功した要求でも、意図しない外部の経路から起動されていないかを確かめるためのものです。ログイン中というだけでは、本人がその画面で変更を始めたことまで説明できません。
仮に会員本人のメールアドレスだけを変更できるAPIがあるとします。他人の情報を変更できない認可が正しくても、本人のブラウザーを使ってその更新を起動させられるなら、別の弱点が残ります。逆に、CSRFトークンが正しいことを理由に、他人の会員IDへの変更を許してはいけません。
業務の受け入れ条件には、本人確認、対象の所有関係、更新要求の検証を別々に書きます。どれか一つを通れば残りを省略する設計にはしません。トークンの検証エラーを、認証エラーと混ぜずに内部で識別できると、導入時の障害も調べやすくなります。
基本となる資料：OWASP：Cross-Site Request Forgery Prevention。
状態変更する入口を先に一覧にする
OWASPは、状態を変更する操作にGETを使わないことや、フレームワークが提供するCSRF保護を利用することを勧めています。フォームだけでなく、プロフィール更新、通知先の変更、権限付与、連携解除、支払い方法の変更など、実際に状態が変わる処理を探します。
本サイトの提案は、URL、メソッド、認証方式、対象データ、CSRF検証の実装場所を並べる方法です。同じ処理を通常フォーム、Ajax、旧APIから呼べるなら、入口ごとに確認します。一つの画面へトークンを付けても、別経路が検証を通らず同じ更新関数へ届けば、対応は終わっていません。
ログアウト、ログイン、アカウント連携のような処理も、単なる画面遷移と決め付けないでください。操作の性質と標準機能の仕様に沿って対策を選びます。外部サービスの正規コールバックがある場合は、通常フォームと同じ方式を無理に流用せず、そのプロトコルの検証も確認します。
スポンサーリンク
トークンは付けるだけでなくサーバーで検証する
セッションに結び付くCSRFトークンを、フォームの値や適切なカスタムヘッダーで送り、サーバーで期待値と照合する方法があります。OWASPは、状態を持つ構成の同期トークンや、署名付きのDouble Submit Cookieなどを説明しています。自作の乱数や署名方式を急いで増やすより、採用フレームワークの標準機能を優先します。
確認するのは、HTMLに値があることではありません。欠落、不一致、別セッションの値を送ったときに更新が実行されないことです。検証に失敗しても成功画面だけ返す構成では、試験結果を誤解しやすくなります。HTTP応答と保存後の実データを両方確認します。
トークンをURLへ入れると、履歴やログなどへ残す経路が増えるため避けます。障害調査の記録にも値そのものを残さず、検証の成否や対象の操作を必要な範囲で記録します。複数タブや長時間の編集で値が古くなる場合も、検証を外すのではなく、入力を保った再認証などの使い方を考えます。
SameSiteは有効な層だがサイトとオリジンは違う
SameSiteはクロスサイトの要求にCookieを送る条件を制御します。ただし、多くの構成で適切なCSRF対策を完全に置き換えるものではありません。OWASPは、安全とされるメソッドで状態変更する入口、同じ登録可能ドメイン配下の別ホスト、クライアント側の要求生成などの限界を挙げています。
たとえばapp.example.comと古いサブドメインを同じ信頼範囲としてよいかは、別の問いです。別オリジンでも同一サイトとして扱われる場合があります。「サブドメインが違うからSameSiteで止まる」という前提を置かず、実際のドメイン構成とCookieの範囲を調べます。
Strictへ変えればすべて解決するわけでもありません。外部からの正規の遷移や認証連携への影響を確認します。Noneが必要な機能も含め、値を用途ごとに判断してください。HttpOnlyとSecureも役割が異なり、付いているだけでCSRFが防げる属性ではありません。
スポンサーリンク
送信元の照合は文字列の部分一致にしない
Originや、必要に応じたRefererの検証は、防御を補う方法です。期待するオリジンはスキーム、ホスト、ポートを含めて厳密に判断します。許可した文字列が含まれるか、末尾が似ているかだけで認める方法は避けます。
プロキシ配下では、サーバーが考える外部向けのURLと、実際の公開URLが違う場合があります。信頼できる設定から期待する宛先を決め、クライアントが自由に送るHostや転送ヘッダーを無条件に採用しないようにします。どのプロキシの情報を信頼するかも構成管理の一部です。
ヘッダーがない場合やnullの場合の扱いは、正規の要求の種類を調べてから決めます。欠落をすべて無条件に通す設定は、対策を弱める可能性があります。一方、調査なしの一括拒否も正規連携を止め得ます。例外は対象と理由を限定し、トークンなど他の検証と合わせて評価してください。
SPAでは要求先を外部入力から自由に選ばせない
同一オリジンのJavaScriptが、URLの断片などを読み、その値から更新先やメソッドを作る構成にも注意が必要です。OWASPはクライアント側CSRFとして、正規のJavaScriptがトークン付きの要求を送ってしまう経路を説明しています。トークンを自動付与するだけでは、要求の選び方まで安全になりません。
本サイトは、操作名から事前に定義した要求へ対応付け、外部入力で任意の更新URLやメソッドを作らない設計を提案します。画面の遷移に使うパラメーターと、権限を使う更新処理のパラメーターを分けます。外部メッセージを受ける機能なら、その送信元と値も確認します。
これはXSS対策とも別の観点です。XSSがあればトークンの取得や正規操作の起動が可能になる場合があるため、出力処理の安全性も必要です。CSRF対策を実装したことを、ブラウザーで実行されるすべての入力を信頼してよい理由にはしません。
編集画面を例に確認項目を作る
仮想のCMSで、プロフィール、公開設定、APIからの記事更新という三つの入口を考えます。画面のフォームにはトークンがある一方、古い更新用URLだけがGETのまま残っていたとします。新しいフォームの対策が正しくても、古い入口で状態が変われば保護は完結しません。まず業務上の変更を一つ選び、同じ変更を起こせる経路を横断して探す方が有効です。
本サイトの提案は、機能ごとに「通常の操作」「ログインした別利用者」「送信元が異なる操作」「トークンを欠く操作」を並べることです。認可とCSRFの試験を別々に行うと、トークンが通れば他人の設定も変更できるという問題を見落としにくくなります。テストに使う値は専用アカウントへ限定し、元へ戻す操作も用意します。
例外を設けるときは、ブラウザーで使う経路と機械間の経路を同じURLへ曖昧に混在させないようにします。署名など別の認証を採用する連携は、その方式がブラウザーのCookieへ依存しないことを確認します。「外部サービスが呼ぶから」という説明だけで、Cookie付きの更新経路を丸ごと保護対象から外さないでください。
改修の完了条件には、通常操作が維持されることに加え、検証に失敗した要求がデータを一切変更しないことを入れます。CSRFの対策を足した後に画面だけがエラーを表示し、裏では保存されている状態を避けます。問い合わせ対応ではトークン全文を求めず、操作時刻と秘密を含まない識別子で照合します。
| 対象 | 正常時の確認 | 拒否時の確認 |
|---|---|---|
| プロフィール更新 | 本人と正しいトークンで保存できる | 別セッションのトークンで保存されない |
| 公開設定 | 権限を持つ担当者だけが変更できる | 無権限の担当者は正しいトークンでも拒否 |
| 古い更新URL | GETでは表示だけが行われる | リンクを開いただけで状態が変わらない |
| 連携用API | 定めた独立の認証で処理できる | Cookieだけでは例外経路へ入れない |
拒否と業務継続を対にして検証する
検証環境では、本人が正規画面で行う更新が成功することを最初に確認します。次に同じ利用者・同じ対象でトークンを欠落・変更した要求、別のセッションの値、許可しない送信元を試します。自分の管理範囲のテスト用アカウントとデータだけを使います。
成功か失敗かは、応答だけでなく実際の保存結果で判断します。フロントエンドでエラーが出ても、バックエンドで変更が済んでいる構成なら、防御の成功ではありません。再送、二重クリック、複数タブ、期限切れの編集といった業務条件も代表させます。
段階導入で記録を集める場合は、監視と遮断を区別してください。記録だけの期間を防御済みとは報告せず、例外を減らして強制する期限と担当を決めます。トークン、Cookie、送信元、認可の各層が何を保証するかを説明できることが、長く維持できる対策につながります。
スポンサーリンク
参考資料
以下は本文の作成時に直接確認した一次資料です。確認日は2026年10月18日です。設定や提供条件は、利用環境に対応した資料も確認してください。
