【実務・中級編】クロスサイトリクエストフォージェリ(CSRF)のトークン検証とSameSite属性 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

CSRFは「終わった脆弱性」か？――現場で直面する防御の限界と真の対策

「CSRF対策？ SameSite=Lax を設定しておけば終わりでしょ？」

もし君がそう思っているなら、残念だがレッドチームの標的としては格好のカモだ。教科書的なセキュリティガイドラインは、あくまで「最低限の土俵」に過ぎない。現実の攻撃現場では、ブラウザの挙動の隙間や、開発者がつい見落とすアプリケーションのロジックの不整合を突いてくる。

今日は、CSRF対策の「盲点」について、実務的な視点で深掘りしよう。

—

1. なぜ SameSite 属性だけでは不十分なのか

SameSite 属性は非常に強力な防御策だ。だが、過信は禁物だ。

Lax の限界: SameSite=Lax は、トップレベルのナビゲーション（GETリクエスト）を許可する。もし君のWebアプリが「GETリクエストで状態変更（データの削除や決済など）を実行する」という設計ミスを犯していれば、SameSite=Lax は無力だ。
レガシーブラウザ: 現代ではほぼ淘汰されたが、古い環境をサポートする必要がある場合、SameSite を解釈できないブラウザは無防備になる。
サブドメインの汚染: もし攻撃者が君の管理下にあるサブドメイン（例: dev.example.com）でXSSを仕込めた場合、同一サイト（Site）とみなされるため、SameSite の制限を回避されてしまう。

結論: SameSite は「多層防御の一枚」に過ぎない。本丸はやはり「ステートフルなトークン検証」だ。

—

2. CSRF トークン検証の「鉄則」

CSRFトークンは「予測不可能」かつ「セッションに紐づく」必要がある。攻撃者が推測できるトークンや、他人のトークンが使い回せるような実装は、無いも同然だ。

安全なPHP実装例

セッションを利用した、現場で使えるCSRFトークンの生成と検証ロジックだ。

<?php
// セッション開始（必ず最初に行う）
session_start();

/**
 * CSRFトークンの生成（フォーム描画時に呼び出す）
 */
function get_csrf_token() {
    if (empty($_SESSION['csrf_token'])) {
        // 暗号論的に安全な乱数を生成
        $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
    }
    return $_SESSION['csrf_token'];
}

/**
 * トークンの検証（POST受取時に呼び出す）
 */
function validate_csrf_token($token) {
    if (!isset($_SESSION['csrf_token']) || $token !== $_SESSION['csrf_token']) {
        // ログ出力して即座に終了させる
        error_log("CSRF attack detected: Invalid token.");
        die("不正なリクエストです。");
    }
}
?>

<!-- フォームへの埋め込み例 -->
<form method="POST" action="/update_profile.php">
    <input type="hidden" name="csrf_token" value="<?php echo htmlspecialchars(get_csrf_token(), ENT_QUOTES); ?>">
    <button type="submit">送信</button>
</form>

—

3. インフラレイヤーでの補完策：NginxとCookie設定

アプリケーションコードだけでなく、Webサーバーの設定でも防壁を固めよう。特に Set-Cookie ヘッダーの設定は重要だ。

nginx.conf で、すべてのCookieに SameSite と Secure 属性を強制的に付与する設定だ。

# Nginxの設定例: 全てのレスポンスヘッダーにセキュアなCookie属性を適用
server {
    ...
    # HttpOnly: JSからのアクセス禁止
    # Secure: HTTPSのみで送信
    # SameSite=Lax: 外部サイトからのPOSTを拒否
    proxy_cookie_path / "/; HTTPOnly; Secure; SameSite=Lax";
}

—

4. レッドチームからの忠告：ここを狙う

最後に、私が攻撃者として現場に入るとき、どこをチェックするかを教える。

1. 「GETで状態変更」: 開発者が index.php?action=delete&id=1 のように書いていないか？これを見つけたら、SameSite があろうがなかろうが、攻撃者は <img> タグ一つで攻撃を成立させる。
2. 「トークンの検証漏れ」: 一部のAPIエンドポイントや、ファイルアップロード機能でトークンチェックが抜けていることが本当によくある。
3. 「セッション固定化」: ログイン前後でセッションIDが切り替わっていないと、トークン自体を先回りしてセットされるリスクがある。

防御のためのチェックリスト

[ ] 全てのステート変更（POST/PUT/DELETE）には必ず独自のCSRFトークンを要求しているか？
[ ] セッション開始時に session_regenerate_id(true) を呼んでいるか？
[ ] 重要なCookieには __Host- プレフィックスを付けているか？（例: Set-Cookie: __Host-SessionId=...）

セキュリティは「完成」しない。だが、コードの端々にこうした執念を込めることで、攻撃者のコストを跳ね上げ、結果として君のシステムを「割に合わないターゲット」にすることができる。

今日のコードを明日からの開発に組み込んでくれ。君の書くコードが、鉄壁の防壁になることを期待している。