CSRFは「死んだ」わけじゃない。なぜ今、トークン実装で致命傷を負うのか
「最近はSPA（Single Page Application）だからCSRF対策は不要ですよね？」
コードレビューで後輩からそう言われ、私は思わず苦笑いした。
確かに、JSON API全盛の時代、セッションIDをCookieで管理しない構成ならCSRFのリスクは劇的に減る。だが、世の中のすべてのアプリケーションが理想的なモダン構成とは限らない。古いPHPの管理画面、Cookie認証を併用したハイブリッドなAPI、そして開発者が「とりあえず動けばいい」と実装した脆弱なトークン処理。
攻撃者は、あなたの書いたその数行の「手抜き」を虎視眈々と狙っている。今日は、実戦で通用する「本当に堅牢なCSRF対策」について、現場の視点から語ろう。
—
1. 攻撃者が笑う「アンチパターン」の正体
多くの開発者が陥る罠は、CSRFトークンの実装における「予測可能性」と「検証の甘さ」だ。
アンチパターンA：セッションIDの流用
トークンを生成するのが面倒で、セッションIDをそのままCSRFトークンとして使う手法だ。これは論外。セッションIDが漏洩した瞬間、攻撃者は認証もCSRF対策も同時に突破できる。
アンチパターンB：固定トークン
「毎リクエスト生成するのは負荷がかかる」という理由で、ログイン時に一度生成したトークンをセッション終了まで使い回す実装。これも危険だ。XSS等でトークンが一度盗まれたら、そのセッションが切れるまで攻撃され放題になる。
アンチパターンC：カスタムヘッダーのみの検証（罠）
「APIだから `X-Requested-With` ヘッダーを見ていればOK」という考え方。これはCORS設定が甘い環境下では、攻撃者がプリフライトリクエストを悪用して回避できる可能性がある。ヘッダーはあくまで「補完」であり、トークンという「秘密の値」による検証を省く理由にはならない。
—
2. 実践：PHPで組む「堅牢なトークン検証」
トークンは「推測不可能」かつ「リクエスト毎に有効」が基本だ。PHPでの実装例を見てみよう。
ここがポイント：
- `random_bytes(32)`: 暗号論的に安全な乱数を使うこと。`rand()`や`mt_rand()`は絶対NGだ。
- `hash_equals()`: 文字列比較によるタイミング攻撃を無効化する。地味だが、プロは必ずここを抑える。
—
3. モダンなフロントエンドとの連携
SPAやAJAXを使う場合、初回ロード時にmetaタグにトークンを埋め込み、それをヘッダーに乗せて送るのが定石だ。
HTML（テンプレート）:
4. インフラ側（Nginx）での防御という選択肢
コードだけで守りきれない場合、あるいはレガシーシステムを保護する場合、WAFやリバースプロキシで補強するのも手だ。しかし、Nginxで無理にトークン検証を行うより、SameSite Cookie属性を最大限に活用するのが現代のベストプラクティスだ。
Nginx設定例（Cookieに厳格な制限をかける）:
全てのSet-CookieヘッダーにSameSite=Strictを強制する
proxy_cookie_path / “/; SameSite=Strict; Secure; HttpOnly”;
これにより、クロスサイトなリクエストではCookie自体が送信されなくなるため、CSRFの攻撃経路そのものが断たれる。これが最もコストパフォーマンスの高い防御策の一つだ。
—
最後に：セキュリティは「多層」で考える
今回のコード例はあくまで「防御の一手」に過ぎない。
- SameSite属性の徹底
- 適切なCORSポリシーの設定
- XSS脆弱性の排除（トークンを盗ませない）
これら全てが組み合わさって初めて、あなたのアプリケーションは「堅牢」と呼べるようになる。
現場でインシデントに直面すると、教科書通りの回答がいかに無力かを思い知らされる。だからこそ、コードを書くときは常に「もし自分が攻撃者だったら、このトークンをどうやって回避するか？」と自問自答してほしい。その視点こそが、君をただのエンジニアから、信頼されるセキュリティ・アーキテクトへと引き上げるはずだ。
さあ、コードを開いて、自分の実装を確認してみよう。まだ「甘い」箇所が見つかるはずだ。
コメント