幻の「$Version」CookieでWAFをすり抜ける――Cookieパーサ差分が生む防御の盲点

本記事は、PortSwigger Research による「Bypassing WAFs with the phantom $Version cookie」（以下、元ソース）を基にまとめたものです。元ソースでは、HTTP Cookieが重要機能の制御に使われている一方で、その長く複雑な歴史が“解釈のズレ”を生み、パーサ差分に起因する脆弱性につながり得ること、そして危険だが見落とされがちな手法として「phantom $Version cookie」に焦点を当てることが述べられています。

概要

Cookieは、ログイン状態や権限、A/Bテスト、言語設定、トラッキング、機能フラグなど、サイトの意思決定に直結する情報を運びます。だからこそWAF（Web Application Firewall）がCookieを検査対象にしているのは自然ですが、問題は「WAFが見ているCookie」と「アプリ（またはその前段のプロキシ/フレームワーク）が最終的に解釈するCookie」が一致するとは限らない点です。

元ソースが指摘するのは、Cookieの仕様や互換性の積み重ねが、実装者ごとの解釈差を生みやすいという現実です。WAFが“無害”と判断して通したリクエストが、バックエンド側では別の意味として解釈されてしまうと、検知や遮断の前提が崩れます。「phantom $Version cookie」は、そのズレを生み出す足場の一例として扱われています。

詳細

なぜCookieのパーサ差分が危険なのか

Web防御はしばしば「同じ入力を同じように読める」ことを暗黙の前提にしています。しかし実際には、Cookieのように歴史が長く、実装や互換挙動が多層化した領域では、同一のヘッダー値でもコンポーネントごとに切り出し方や優先順位が揺れることがあります。WAFは特定の規則でCookieを分解して検査しますが、アプリ側（あるいは言語/フレームワーク/ライブラリ）が異なる規則で再解釈すると、攻撃者は「WAFが見落とす形で、アプリには届く形」を狙えます。

このタイプの問題は、単にフィルタをすり抜けるという話に留まりません。Cookieはセッションや機能フラグなど“結果に直結する”情報なので、解釈のズレが成立すると、認可の誤作動、条件分岐のすり替え、入力検査の迂回など、影響が大きくなりがちです。元ソースが強調する「重要機能を制御するCookie」と「パーサ差分脆弱性」の組み合わせは、まさにここにあります。

「phantom $Version cookie」という観点

元ソースは、危険だがあまり知られていない手法の一つとして「phantom $Version cookie」を取り上げています。ここで重要なのは、特定の“文字列”そのものというより、「ある実装では特別扱いされ、別の実装では無視されたり、逆に別の切り方を誘発したりする可能性がある要素が存在する」という視点です。

WAFの検査ロジックが、ある要素を前提にCookieを正規化・分解している一方で、バックエンドのCookieパーサは別の前提で処理していると、攻撃者はその境界で意味をずらせます。結果として、WAFが想定する“危険なCookie値の形”を外しつつ、アプリ側には別の形で目的の値を到達させる、といった迂回の余地が生まれます。

実務上の備え（設計・実装・運用）

1つめの備えは、「どこでCookieが解釈されているか」を分解して把握することです。WAF、CDN、リバースプロキシ、アプリサーバ、アプリケーション、そしてアプリ内のフレームワーク/ミドルウェアが、それぞれCookieを読み取ります。どこか一段でも解釈が違えば、検査の“見た目”と実際の“効果”が乖離します。

2つめは、防御の責務をWAFだけに寄せないことです。WAFは有効な層ですが、解釈差の問題は「WAFが完全に同じ解釈をする」ことを前提にしがちで、運用の現実と衝突します。アプリ側でも、重要な判定に使うCookieは厳格に扱い、想定外の形式や重複、曖昧な表現を検知したら安全側に倒す（拒否する/再認証させる/機能を無効化する）といった方針が必要になります。

3つめは、テスト観点の更新です。単純なペイロード検査だけでなく、「WAFのログ上は問題なしだが、アプリの挙動が変わる」という“差分”を発見するテストが重要です。PortSwigger Research では、別テーマとしてCSP nonceのバイパス探索を動的解析で行う話題や、XSSチートシートへのコミュニティ貢献の紹介なども扱われていますが、これらに共通するのは「仕様や表面的なルールだけでなく、実装の現実（挙動）を観測して攻撃/防御を組み立てる」という姿勢です。

最後に、周辺の反応として、元ソース記事自体がSNS上で共有・言及されていることも補足できます。LinkedInの投稿では本件に触れつつ、別の重要脆弱性（LFI/RFI）についても言及があり、X（旧Twitter）でも元ソースを“良い記事”として紹介する投稿が見られます。技術記事が広く拡散されるほど、攻撃側・防御側双方の学習速度が上がるため、セキュリティ担当者は「見落とされがちな入力面（Cookie等）」の点検優先度を再評価するきっかけとして捉えるとよいでしょう。