ステートレスな環境でのCSRF対策：ダブルサブミットクッキー法の「真実」と「罠」
やあ。現場で泥をすすりながらシステムを守り抜いている諸君、お疲れ様。
今日は、多くのエンジニアが「なんとなく」実装し、そして「なんとなく」突破されるCSRF（クロスサイトリクエストフォージェリ）対策、特にダブルサブミットクッキー（Double Submit Cookie）法について深掘りしよう。
「サーバー側に状態（セッション）を持たせたくない」。マイクロサービス化が進む現代において、この要望はもっともだ。だが、ステートレスにするということは、防御のバリアも薄くなるということ。この危ういバランスをどう制御するか、現場の視点で語る。
—
1. なぜ「ダブルサブミット」なのか？
通常、CSRF対策の王道は「同期トークンパターン」だ。サーバー側でセッションにトークンを保持し、リクエストと照合する。しかし、サーバーが分散環境にあったり、純粋なAPIサーバーとして振る舞う場合、このセッション管理がボトルネックになる。
そこで登場するのがダブルサブミットクッキー法だ。ロジックは単純。
1. ランダムな値を生成する。
2. その値を「クッキー」と「リクエストボディ（またはヘッダー）」の両方に仕込む。
3. サーバー側は、クッキーの値とリクエストの値が一致するかどうかだけをチェックする。
「サーバーは何も記憶しなくていい」。これがこの手法の最大の魅力だ。だが、ここには致命的な盲点がある。
—
2. 攻撃者が狙う「サブドメイン」という死角
攻撃者は、君が書いたロジックが「ドメインの一致」しか見ていないことを知っている。もし、君のサービスが app.example.com で動いていて、同じドメイン配下の blog.example.com がXSS（クロスサイトスクリプティング）に対して脆弱だったとしたらどうなるか？
攻撃者はその脆弱性を突き、blog.example.com のコンテキストで example.com 配下のクッキーを書き換えることができてしまう。
PoC（攻撃イメージ）:
1. blog.example.com のXSSで、攻撃者が csrf_token=fake_token というクッキーを example.com ドメインに対してセットする。
2. 被害者が app.example.com にアクセスする際、ブラウザは「偽のトークン」を送信する。
3. 攻撃者は被害者のブラウザから app.example.com へリクエストを送る際、同じ fake_token をパラメータに含める。
4. サーバーは「クッキーとパラメータが一致した！」と判断し、攻撃を許可してしまう。
これが、ダブルサブミットクッキーを実装する際の最大の落とし穴だ。
—
3. 実践：セキュアなダブルサブミットの実装例
この脆弱性を封じるには、クッキーに __Host- プレフィックスを付けるのが鉄則だ。これにより、サブドメインからの干渉を物理的に遮断できる。
PHPによるセキュアな実装例
time() + 3600,
‘path’ => ‘/’,
‘secure’ => true,
‘httponly’ => true,
‘samesite’ => ‘Strict’
]);
// サーバー側の検証ロジック
function validate_csrf($request_token, $cookie_token) {
// 比較にはハッシュ関数を使うことでタイミング攻撃を防止
if (!isset($cookie_token) || !hash_equals($cookie_token, $request_token)) {
throw new Exception(“CSRFトークンが無効です”);
}
return true;
}
?>
Nginxでの防御設定（ヘッダーによる強化）
アプリケーションコードだけでなく、インフラ側でも「そもそも怪しいリクエストを通さない」姿勢が重要だ。
CSRFトークンが含まれていない、あるいはOriginが不正なPOSTリクエストを弾く
if ($request_method = POST) {
# 実際はmapモジュール等で動的に検証するのが望ましい
add_header X-Frame-Options “DENY”;
add_header Content-Security-Policy “default-src ‘self’;”;
}
—
4. チーフエンジニアからの提言：完璧を求めて
ダブルサブミットクッキー法は、ステートレス環境において極めて強力な武器になる。しかし、実装する際は必ず以下の3点を守れ。
1. __Host- プレフィックスを必ず使う: これを忘れると、サブドメインからの攻撃に対する防御壁は無力化する。
2. SameSite=Strict (または Lax) を併用する: ブラウザの標準的なセキュリティ機能を最大限活用しろ。
3. hash_equals() を使う: 文字列比較の際、単純な == を使うとタイミング攻撃でトークンが推測される可能性がある。常に一定時間で比較する関数を使え。
セキュリティとは、「魔法の杖」を探すことではない。「脆弱性が生まれる構造を理解し、それを一つずつ丁寧に潰す泥臭い作業」の積み重ねだ。
君たちが書くその一行が、明日、どこかのユーザーの大切な情報を守るかもしれない。自信を持って、しかし疑心暗鬼になりながら実装を続けてくれ。コードレビューでまた会おう。
コメント