Webキャッシュポイズニング：HTTPの「曖昧さ」を突く深淵なる罠
Webキャッシュポイズニングは、単なる設定ミスではない。それはHTTPというプロトコルが孕む「解釈の揺らぎ」と、キャッシュサーバーがその揺らぎをどう正規化（Normalization）するかという、低レイヤの不整合を突く芸術だ。
我々のようなペネトレーションテスターから見れば、キャッシュサーバーは「最も信頼してはならないゲートキーパー」である。なぜなら、彼らは往々にしてWebアプリケーションの背後にいるオリジンサーバーとは異なる言語（仕様解釈）で会話しているからだ。
1. プロトコル解釈の乖離：キャッシュキーの崩壊
キャッシュポイズニングの根源は、キャッシュキー（Cache Key）の生成ロジックにある。多くのエンジニアは「URLとホスト名さえ合っていれば問題ない」と考えがちだが、現代のCDNやリバースプロキシは、数多のHTTPヘッダーを解釈する。
特に危険なのは、X-Forwarded-Host や X-Original-URL といった非標準的だが広く実装されているヘッダーだ。もしバックエンドのフレームワークが Host ヘッダーではなく、これらのプロキシ由来のヘッダーを優先して絶対パスを生成する場合、攻撃者はキャッシュサーバーの「裏」をかくことができる。
例えば、以下のようなPHPコードを考えてみよう。
<?php
// 脆弱な実装例: HTTPヘッダーを信頼してリンクを生成
$host = $_SERVER['HTTP_X_FORWARDED_HOST'] ?? $_SERVER['HTTP_HOST'];
$url = "https://" . $host . "/assets/js/app.js";
// このURLがレスポンスボディに埋め込まれると、キャッシュキーは汚染される
echo '<script src="' . $url . '"></script>';
?>攻撃者が X-Forwarded-Host: evil-attacker.com を付与してリクエストを送ると、キャッシュサーバーは「正規のドメインへのリクエスト」として処理するが、オリジンは「攻撃者のサーバーからスクリプトを読み込め」というレスポンスを返す。キャッシュサーバーはこれを「正当なレスポンス」として保存し、以降の全ユーザーに毒を撒き散らすことになる。
2. 攻撃の解像度を上げる：HTTPリクエストスマグリングとの併用
単体のヘッダーインジェクションで防がれている場合、我々は「HTTPリクエストスマグリング」を併用し、キャッシュサーバーとオリジンサーバー間の通信をデシンクロさせる。
キャッシュサーバーが Content-Length を信じ、オリジンが Transfer-Encoding: chunked を信じる場合、リクエストの境界線がずれる。これにより、キャッシュサーバーが「これは別々のリクエストだ」と認識する一方で、オリジンは「これは1つのリクエストの一部だ」と解釈し、本来キャッシュされるべきでない「ユーザー固有のレスポンス（認証情報など）」をキャッシュサーバーに吐き出させることができる。
3. 防御のアーキテクチャ：キャッシュキーの厳格化とガードレイル
この脆弱性を根本から断つには、キャッシュキーの決定論的な制御が不可欠だ。NGINXやVarnish、あるいはCloudflareのWorker層で、以下の戦略を適用することを推奨する。
A. ヘッダーの正規化とホワイトリスト化
キャッシュサーバーに到達する前に、未知のヘッダーをすべてサニタイズせよ。
# NGINX設定例: 不要なホストヘッダーの棄却
if ($http_x_forwarded_host != "") {
return 403; # セキュリティの観点から、プロキシ由来のホスト指定は厳禁
}
# キャッシュキーから特定のヘッダーを除外する設定
proxy_cache_key "$scheme$request_method$host$request_uri";
# ここにX-Forwarded-Hostを含めてはならないB. 応答の「汚染」を防ぐVaryヘッダーの活用
アプリケーション側で、キャッシュのバリエーションを明示的に定義する。
// PHPでのレスポンス制御
// 異なるホストヘッダーがレスポンスに影響を与えることをサーバーに明示する
header("Vary: Host, X-Forwarded-Host");4. 未来への視座：AIと耐量子時代のキャッシュ戦略
今後は、生成AIが生成したプロンプトをキャッシュする際、プロンプトインジェクションそのものが「キャッシュを汚染する媒介」となり得る。ユーザー固有のコンテキストがキャッシュキーに適切に含まれていない場合、他人の機密情報がプロンプトとして返ってくる事態は容易に想像できる。
耐量子暗号（PQC）への移行期においては、TLS接続の再交渉やハンドシェイクのオーバーヘッドが増大する。この隙を突いたセッションのなりすましや、暗号化の不備を突くキャッシュポイズニングが、次の大きなトレンドになるだろう。
結論として、キャッシュサーバーを「単なる高速化ツール」と見なす時代は終わった。それはWebアプリケーションの「アイデンティティ」を司る重要なゲートウェイであり、HTTPプロトコルの隅々まで理解し、ヘッダーの「曖昧さ」をすべて排除する設計思想こそが、真の防衛を可能にするのだ。
現場のアーキテクト諸君、まずは君たちのキャッシュサーバーが Vary ヘッダーをどう解釈し、どのヘッダーをキーとして保持しているのか、その全ログを精査することから始めてほしい。そこに、システムの脆弱性の核心が眠っている。
コメント