CSRFの成立条件と多層防御の原理

CSRF（Cross-Site Request Forgery）は「攻撃者のサイトから、被害者の認証情報を使って、別サイトへ副作用のあるリクエストを飛ばす」攻撃です。鍵は、攻撃者がレスポンスを読む必要が一切ないこと。送金や設定変更が「実行されさえすれば勝ち」という構造が、CORSやSame-Origin Policyでは防ぎきれない理由になっています。

なぜ他サイト発のリクエストにCookieが付くのか

ブラウザのCookie送信ルールは「宛先（リクエスト先）のドメインに紐づくCookieを自動付与する」というものです。リクエストの発信元がどこかは、従来は問われませんでした。つまり攻撃者のページ evil.example に置かれたフォームが bank.example へ POST すると、ブラウザは律儀に bank.example のセッションCookieを添えて送ります。

この自動付与こそがCSRFの土台です。攻撃者はCookieの値を知る必要がありません。読めなくても、ブラウザが勝手に正しいCookieを付けてくれるからです。

<!-- evil.example に置かれた罠。被害者が開くだけで送金が走る -->
<form action="https://bank.example/transfer" method="POST" id="f">
  <input type="hidden" name="to" value="attacker">
  <input type="hidden" name="amount" value="100000">
</form>
<script>document.getElementById('f').submit();</script>

成立の3条件

CSRF が刺さるには、次の3つが同時に成り立つ必要があります。逆に言えば、どれか1つでも崩せば成立しません。

3つ目は攻撃の本質なので除去できません。だから現実の防御は、上の2つ（自動付与される認証情報／推測可能なリクエスト）のいずれかを成立させないことに集約されます。

トークン同期（Synchronizer Token）

最も古典的かつ堅い防御です。サーバーがセッションごとにランダムなトークンを生成・保持し、フォームの hidden フィールドに埋め込みます。送信時にサーバーは「セッションに紐づくトークン」と「リクエストに付いてきたトークン」を比較し、一致しなければ拒否します。

効く理由は、攻撃者がトークン値を知り得ないからです。トークンはレスポンスHTMLの中にあり、攻撃者は被害者のレスポンスを読めません（SOPが効く）。よって正しい hidden 値を埋めたフォームを攻撃者は構築できず、条件②（推測可能性）が崩れます。

1. GET /form → サーバーが token=Q7x... を生成しsessionに保存、HTMLに埋込
2. POST /transfer (token=Q7x... を含む)
3. サーバー: session.token == body.token か検証 → 不一致なら 403

二重送信Cookie（Double Submit Cookie）

サーバーに状態を持たせない方式です。ランダムなトークンを Cookie とリクエスト本体（hidden もしくはカスタムヘッダ）の両方に入れ、サーバーは「2つの値が一致するか」だけを見ます。セッションストアへの照合が不要なのでステートレスに組めます。

効く理屈は、攻撃者は Cookie の値を読めない（SOPで遮断）うえ、別ドメインから bank.example の Cookie を任意の値に書き換えることもできないから、Cookie 側とボディ側を一致させられない、というものです。

Origin / Referer ヘッダ検証

ブラウザが付ける Origin（および Referer）はリクエストの発信元を示します。サーバー側で「発信元が自分のオリジンか」を確認すれば、evil.example 発の POST を弾けます。条件②ではなく「発信元の素性」を直接見る防御です。

Origin は CSRF に効きやすいヘッダです。クロスサイトの POST には付与され、JS から偽装できません（fetch でも Origin はブラウザが上書きするユーザー制御不可ヘッダ）。

SameSite Cookie

そもそも条件①（クロスサイトでCookieが自動付与される）をブラウザ側で断つのが SameSite 属性です。Cookie 自体に「別サイト発のリクエストには付けるな」と指示します。

既定が Lax になったことで、フォーム POST のようなクロスサイトの副作用リクエストには Cookie が付かなくなり、典型的なCSRFの多くが自動的に無力化されました。ただし Lax は「トップレベル GET ナビゲーション」には Cookie を送るため、状態変更を GET で実装していると穴になります。状態変更は必ず POST 等にすること。

多層で組む

各防御は前提と効きどころが異なります。実務では複数を重ね、どれか1つが破れても全体が崩れないようにします。

推奨の重ね方は、(a) すべての認証 Cookie に SameSite=Lax（最低限）＋ Secure ＋ HttpOnly を付ける、(b) 状態変更は必ず非 GET にする、(c) その上で同期トークンまたは署名付き二重送信を必須化、(d) Origin 検証を fail-closed で追加、という構成です。

なお、JS から読み書きするトークン方式は XSS に弱い点に注意してください。XSS があればトークンは漏れ、CSRF 防御は丸ごと迂回されます。CSRF 対策と並行して、入力のサニタイズや Content Security Policyの内部動作と回避耐性 による XSS 抑止を組み合わせるのが本筋です。

土台となる認証情報の運び方は Cookie とセッション と Cookie・セッション・JWT（Web認証） を、なぜ「読む防御」と「送る防御」が別なのかは 同一オリジンポリシーとサイト分離の信頼境界 もあわせてどうぞ。