2026.05.01 2026.05.02

【Webキャッシュ汚染編】CDNを毒で塗る攻撃と守り方｜CTF思考フレームワーク #19

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　Web脆弱性編　#19 / 公開中 10記事　→　シリーズ一覧を見る →

Webキャッシュ汚染は、CDNや前段プロキシのキャッシュに「毒入りレスポンス」を保存させて、その後アクセスする全ユーザーに毒を配る攻撃。1人をXSSするのとは威力が桁違い。CDN時代の主要な攻撃面のひとつです🍷

キャッシュは「速度のため」に存在しますが、設定を間違えると「攻撃の拡声器」になります。

難易度：★★★（上級）

CDNを「武器化」する攻撃。1人の悪意が全ユーザに届きます🌐

キャッシュ汚染はCDN/プロキシのキャッシュに悪意あるレスポンスを置く攻撃だよ☠️

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：実際の手口
🛡️ 防御フェーズ：どう守る？
🛡️ 今日からできる対策ツール
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
📚 次に読みたい
🧪 自分で検証してみる
⚖️ 大事なお約束
📖 次に読みたい

👀 観察フェーズ：まず何を見る？

まずCache-Control / Vary / X-Cache系のレスポンスヘッダを観察！何がキャッシュされてるかが見えてくる🔍

キャッシュ汚染の核は「キャッシュキーに含まれない入力（unkeyed input）が応答を変える」こと。これを見つけるのが第一歩。

リクエストにX-Forwarded-Hostのような無視されてそうで反映されるヘッダを加えて、レスポンスに混ざるか確認します👀

キャッシュキー(URLや一部ヘッダ)の想定外でキャッシュが汚染されるんだね😱

🤔 仮説フェーズ：攻撃者は何を考える？

キャッシュ汚染の典型は4パターン。

攻撃者の仮説。

🪞 仮説①：Unkeyed Header反映

キャッシュキーに含まれないX-Forwarded-Host等の値がレスポンス本文に反映されると、攻撃者の値がキャッシュに保存される。

🍪 仮説②：Unkeyed Cookieによる汚染

キャッシュキーから外れたCookieにXSSペイロードを仕込むとレスポンスに混入。

🔁 仮説③：Cache Deception

本来非キャッシュなはずのページに/profile.cssのような静的拡張子を付けてアクセス。CDNが個人情報をキャッシュ→他人に配信。

🚂 仮説④：HTTPスマグリングと連携

#18のスマグリングでキャッシュ汚染を確実に成立させる。最強コンボ。

キャッシュ汚染は「unkeyed input × キャッシュ可能レスポンス」の掛け算。ヘッダ反射＋静的に見えるパスがあれば要注意です。

キャッシュって「便利さ」と「危うさ」が表裏一体だね💧

🔬 検証フェーズ：どうやって確かめる？

Burp拡張Param Minerで「Unkeyed Inputs」を自動検出！レスポンスに反映される未知ヘッダがあぶり出せる🧪

検証ステップ。

X-Cache: HITが返ってきたら汚染が他のユーザーにも届くってことだね😨

⚔️ 攻撃フェーズ：実際の手口

キャッシュ汚染の代表攻撃はこの3つ。

実戦シナリオ。

① 全ユーザへのXSS拡散

キャッシュにXSSペイロードを混入→トップページ訪問者全員でJSが発動。実害が極大。

② リダイレクト汚染

X-Forwarded-Hostを反映するLocationヘッダで攻撃者ドメインにリダイレクトさせてフィッシング。

③ 個人情報の他人配信

Cache Deceptionで/api/user/me を含むパスをキャッシュさせ、他のユーザに別人の個人情報を配信。

CTF{every_input_in_cached_response_is_a_cache_key}

原則：「レスポンスを変える可能性のある入力は、すべてキャッシュキーに含めるか拒否する」。

🛡️ 防御フェーズ：どう守る？

キャッシュ汚染対策の3レイヤー！🛡️

キャッシュ防御の3点。

🗝️ キャッシュキーを正しく設計

リクエストに含まれるすべてのレスポンスに影響する要素(Vary、Cookie、ヘッダ)をキャッシュキーに含める。

🚫 反映されるヘッダを最小化

X-Forwarded-Host等をアプリ内で読まない・反映させない。Hostヘッダの再構築は配慮が必要。

🔒 認証ページは絶対にキャッシュさせない

Set-Cookieが入る・認証情報を返すレスポンスはCache-Control: private, no-storeを明示的に付与。

「キャッシュは設計するもの」。任せっきりは絶対NGだね💪

🛡️ 今日からできる対策ツール

パスワードの使い回しや手動管理はどんなに気をつけても限界があります。🔑 パスワード管理ツール「ワンパス」なら、複雑なパスワードを安全に保管して「1つのマスターパスワード」だけ覚えられるので、今日から始める防御策としてしっくりきます。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

よくあるミス。

X-Forwarded-Host 等の代理ヘッダをアプリで信用してリンク生成。
CDNのキャッシュキーをURL+メソッドだけにし、Varyを軽視。
個人情報ページにCache-Controlを付けず、CDNのデフォルトTTLでキャッシュさせる。
拡張子ベースで「.css は常にキャッシュ」のCDNルール。
Surrogate-Controlとブラウザ向けCache-Controlの差異を意識せず設定。
James Kettleのキャッシュ汚染リサーチをチェックしていない。

🧰 ツール早見表

使う道具。

ツール	用途	ひと言
Param Miner (Burp拡張)	unkeyed input自動探索	キャッシュ汚染検出の主役
Web Cache Vulnerability Scanner (Hackmanit)	CLIスキャナ	網羅的な検出に
Burp Suite	手動検証	基本のリクエスト・レスポンス比較
curl + DevTools	ヘッダ観察	X-Cache、Age、Via等を素早く確認