【入門編】 Webキャッシュポイズニングの仕組みと防御 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは！セキュリティやインフラの勉強を始めたばかりの新人エンジニアの皆さん、日々の開発やサーバー管理、本当にお疲れ様です。

「Webセキュリティ」と聞くと、なんだかハッカー映画に出てくるような難解な黒い画面を想像して身構えてしまいますよね。でも大丈夫です。一歩ずつ、身近な例えから紐解いていけば、決して越えられない壁ではありません。

今回は、Webサイトの裏側でこっそり行われている「キャッシュ」という仕組みのちょっとした隙をつく、「Webキャッシュポイズニング」という攻撃と、そのスマートな防御方法についてお話ししていきますね。

難しそうな用語が出てきても置いてけぼりにしませんので、リラックスしてコーヒーでも飲みながら読んでいってください！

—

1. 家の「合鍵」と「宅配ボックス」で考えてみるWebキャッシュ

まずは、攻撃の話をする前に、Webサイトが普段どうやって動いているのかを身近な例えで見てみましょう。

皆さんの自宅（Webサーバー）に、世界中から毎日たくさんのお客さん（ユーザー）が荷物（リクエスト）を持ってやってくるとします。毎回あなた自身が玄関に出て対応していたら、忙しくて倒れてしまいますよね。

そこで、マンションの管理人さん（キャッシュサーバー）を雇うことにしました。
管理人さんは、よくある質問への答えや、みんなが欲しがる人気のチラシを手元にコピーして持っています。お客さんが来ると、あなたをわざわざ呼ばずに、管理人さんがその場でサッとチラシを渡してあげます。これが「キャッシュ（情報の一時保存）」の仕組みです。

これによって、あなたの仕事は劇的に減り、お客さんも待たされずに済むという素晴らしい効率化が生まれます。

—

2. キャッシュポイズニングってどんな悪巧み？

さて、この便利な管理人さん（キャッシュサーバー）ですが、ちょっとした「うっかり屋さん」だったりします。

ここに悪い泥棒がやってきました。泥棒は、管理人さんにこう囁きます。
「おーい、さっき配ってたチラシの宛名、あいつのの名前に書き換えておいてよ！」

管理人さんが「え？あ、はい、わかりました」と、手元のコピーの宛名を書き換えてしまったとします。すると、その後にやってきた全く関係のない別のお客さんにも、その書き換えられた「偽のチラシ」が渡されてしまうことになりますよね。

これが、Webキャッシュポイズニング（Webキャッシュ毒入れ攻撃）の正体です。

攻撃者は、サーバーに対して「特別な細工をしたリクエスト」を送り、本来であれば自分だけが見るはずの「おかしなページ」をキャッシュサーバーに覚え込ませます。その結果、後からそのページにアクセスした無実の一般ユーザー全員に、その「おかしなページ」が表示されてしまうという、非常にイヤラシイ攻撃なのです。

—

3. なぜこんなことが起きてしまうの？（技術的な仕組み）

では、もう少しだけエンジニアらしい視点に踏み込んでみましょう。

Webの世界では、私たちがブラウザからアクセスするとき、URLだけでなく、HTTPリクエストヘッダーという「見えない名札」を一緒に送っています。代表的なものに、Host ヘッダーなどがありますよね。

キャッシュサーバーは、基本的にはURL（例: https://example.com/index.php）を見て「このページのキャッシュを持っておこう」と判断します。
しかし、ここに「URLには含まれていないけれど、ヘッダーに含まれる特別な情報」が混ざってきたとき、キャッシュサーバーの計算が狂ってしまうことがあるのです。

例えば、以下のようなPHPのコードがあったとしましょう。このコードは、リクエストに含まれる X-Forwarded-Host というヘッダーの値をそのまま画面上のJavaScriptに埋め込んでしまっています。

<?php
// リクエストのヘッダーから「転送元ホスト名」を取得する
$host = isset($_SERVER['HTTP_X_FORWARDED_HOST']) ? $_SERVER['HTTP_X_FORWARDED_HOST'] : $_SERVER['HTTP_HOST'];
?>
<!DOCTYPE html>
<html>
<head>
    <title>マイページ</title>
</head>
<body>
    <h1>ようこそ！</h1>
    <!-- 取得したホスト名をJavaScriptの読み込み元（src）に埋め込んでいる -->
    <script src="http://<?php echo htmlspecialchars($host, ENT_QUOTES, 'UTF-8'); ?>/analytics.js"></script>
</body>
</html>

もし、攻撃者が X-Forwarded-Host: evil-attacker.com という悪意あるヘッダーをつけてリクエストを送ったらどうなるでしょうか？
運悪くキャッシュサーバーが「URLだけ」を見てキャッシュを保存してしまい、この X-Forwarded-Host の違いを無視してしまった場合、サーバーは次のような危険なHTMLをキャッシュしてしまいます。

<!-- キャッシュサーバーに保存されてしまった危険なHTMLの例 -->
<script src="http://evil-attacker.com/analytics.js"></script>

これによって、このページにアクセスしたすべてのユーザーのブラウザが、攻撃者のサーバーから勝手に怪しいJavaScriptファイルを読み込まされてしまうことになります。これがキャッシュポイズニングによる被害のメカニズムです。

—

4. 対策の切り札！「Varyヘッダー」を正しく使おう

「うわ、怖い！じゃあどうやって防げばいいの？」と思いましたよね。
一歩ずつ、確実に対策を学んでいきましょう！

この問題を防ぐための最も強力で、実務でも必ず使われるアプローチが、Vary（ヴェアリー）ヘッダーの適切な設定です。

先ほどの管理人（キャッシュサーバー）の例えに戻りましょう。
管理人さんがうっかりミスをした原因は、「お客さんがどんな名札（ヘッダー）をつけていたか」を無視して、同じチラシを全員に配ってしまったからです。

そこで、私たちは管理人さんにこう指示を出します。
「おい管理人、お客さんにチラシを渡すときは、名札の『〇〇』という項目が違う人には、別のチラシをそれぞれ覚えておきなさい！」

この「違う項目ごとにキャッシュをちゃんと分けてね」と指示を出すのが、HTTPレスポンスヘッダーの Vary です。

実際のNginxやApache、PHPでの設定・実装例

Webアプリケーションやリバースプロキシ（Nginxなど）の設定で、キャッシュを分離するべきヘッダーを明確に指定します。

PHPのレスポンスヘッダーで制御する場合の例を見てみましょう。

<?php
// 「X-Forwarded-Host」や「User-Agent」などのヘッダーによって
// キャッシュの中身を完全に切り離すようにブラウザやキャッシュサーバーに指示する
header("Vary: X-Forwarded-Host, Accept-Encoding");

// 以降の処理...
?>

また、Nginxをキャッシュサーバーとしてフロントに立てている場合は、設定ファイル（nginx.conf など）で以下のようにキャッシュのキーやVaryの挙動を丁寧にコントロールします。

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_servers;
        
        # バックエンドからの Vary ヘッダーを尊重し、
        # ヘッダーの内容が異なるリクエストごとに別のキャッシュとして保存する
        proxy_ignore_headers "X-Accel-Expires" "Expires" "Cache-Control";
        
        # キャッシュの有効期限を設定
        proxy_cache_valid 200 10m;
        
        # デバッグ用にキャッシュの状態をレスポンスヘッダーに含める
        add_header X-Cache-Status $upstream_cache_status;
    }
}

このように、「どのヘッダーの値を考慮してキャッシュを分けるべきか（キャッシュキーの分離）」を正しく設計・設定することが、キャッシュポイズニングを防ぐための最大の防御策になります。

—

5. まとめ：安全なキャッシュ運用のために

今回は、Webキャッシュポイズニングの仕組みと、Varyヘッダーを使った防御の基本について解説しました。

キャッシュポイズニングとは？

キャッシュサーバーの思い込みや設定の不備を利用して、悪意あるコンテンツを他の一般ユーザーにまで巻き込んで見せてしまう攻撃。

なぜ起きる？

URLだけでなく、リクエストヘッダー（X-Forwarded-Host など）に含まれる動的な値が、キャッシュの判定から漏れてしまうことで発生する。

どう防ぐ？

Vary ヘッダーを適切に設定し、キャッシュサーバーに対して「ヘッダーの値が違う場合は、キャッシュを別々に管理しなさい」と厳しく指示する。

実務の現場では、CDN（CloudflareやAkamaiなど）や社内のリバースプロキシなど、キャッシュを扱うレイヤーが複雑に入り組んでいることがよくあります。「動的な入力値がキャッシュに悪影響を与えていないか」「Varyヘッダーが意図通りに機能しているか」を、開発時だけでなくインフラ構築の際にもぜひ意識してみてください。

一つひとつの仕組みを丁寧に理解していけば、セキュリティは怖くありません。むしろ、仕組みが分かれば分るほど、Webアプリケーションを作るのがもっと楽しくなりますよ！

それでは、次のセキュリティの冒険でお会いしましょう。お疲れ様でした！