Web cache poisoning

Điều làm cache poisoning nguy hiểm: nó biến một lỗi phản chiếu chỉ hại chính kẻ tấn công thành một lỗi hại MỌI NGƯỜI. Một header phản chiếu (như X-Forwarded-Host ở topic host-header) tự nó chỉ ảnh hưởng request của kẻ tấn công; nhưng nếu response đó được cache, nó phục vụ cho mọi người dùng sau — nên một XSS "self-only" trở thành một XSS lưu trữ ở quy mô CDN.

Hai khái niệm phải nắm, và chúng là toàn bộ topic:

• Cache key là tập input mà cache dùng để quyết định "hai request này có giống nhau không". Mặc định thường chỉ là method + đường dẫn + vài header. Mọi input NGOÀI cache key mà response phụ thuộc vào là một lỗ hổng: kẻ tấn công đổi nó, response đổi theo, nhưng cache coi hai request là một.
• Unkeyed input: header như X-Forwarded-Host, X-Forwarded-Scheme, User-Agent, hay một tham số query mà cache bỏ qua nhưng ứng dụng lại dùng. Đây là bề mặt tấn công.

Và một điều về vị trí: bản vá gần như luôn ở cấu hình cache, không ở code ứng dụng — giống topic request-smuggling. Nó là một lỗi của sự bất đồng giữa cache và app về "request này là gì".

Cơ chế là sự chênh lệch giữa cache key (thứ cache dùng để so request) và thứ response thực sự phụ thuộc vào.

sequenceDiagram    autonumber    actor A as Kẻ tấn công    participant C as Cache (key = method + path)    participant S as Server    A->>C: GET / <br/>X-Forwarded-Host: evil.example    Note over C: Cache key KHÔNG gồm X-Forwarded-Host → coi như GET / bình thường.    C->>S: chuyển tiếp    S-->>C: 200, HTML có <script src=//evil.example/x.js><br/>(server dùng X-Forwarded-Host)    Note over C: Cache LƯU response độc hại dưới key "GET /".    actor V as Nạn nhân    V->>C: GET / (bình thường)    C-->>V: response ĐÃ ĐẦU ĐỘC từ cache    Note over V: Nạn nhân nhận script của kẻ tấn công. XSS quy mô CDN.

Điểm cốt lõi: response độc hại được LƯU dưới một cache key bình thường, nên nạn nhân gửi một request hoàn toàn bình thường lại nhận response đã bị đầu độc. Đây là lý do nó hại mọi người, không chỉ kẻ tấn công.

Bảng các dạng, theo nguyên nhân:

Hàng cuối đáng biết: cache poisoning không chỉ là XSS — đầu độc một trang lỗi vào cache là DoS. Một request làm server trả 400, 400 đó bị cache, và mọi người sau nhận 400 cho một trang bình thường.

Một trang chủ được CDN cache, và server dùng X-Forwarded-Host để dựng canonical URL.

# Request đầu độc. X-Forwarded-Host KHÔNG nằm trong cache key, nhưng server dùng nó.GET / HTTP/1.1Host: app.exampleX-Forwarded-Host: evil.example

HTTP/1.1 200 OKCache-Control: public, max-age=300 <script src="//evil.example/analytics.js"></script>   ← server phản chiếu X-Forwarded-Host

Cache lưu response này dưới key GET / (nó bỏ qua X-Forwarded-Host). Trong 300 giây tiếp theo, mọi người dùng gửi GET / bình thường nhận trang có script của kẻ tấn công.

# Phát hiện: gửi một header unkeyed với một marker và xem nó có được cache không.curl -s https://app.example/ -H 'X-Forwarded-Host: canary123.evil' | grep -q canary123 \  && echo "X-Forwarded-Host phản chiếu"# Rồi gửi request BÌNH THƯỜNG và xem marker còn không → nếu còn, nó đã bị cache.curl -s https://app.example/ | grep -q canary123 && echo "ĐÃ ĐẦU ĐỘC CACHE"

# Biến thể DoS: header dị dạng làm server trả 400, và 400 bị cache.GET / HTTP/1.1X-Forwarded-Host: evil\r\n(header dị dạng làm server lỗi)# 400 bị cache dưới key GET / → mọi người sau nhận 400 cho trang chủ.

# Sau khi vá: X-Forwarded-Host không phản chiếu (dùng domain cấu hình, topic host-header),# hoặc đưa nó vào cache key, và không cache trang lỗi.

Nghiên cứu của James Kettle — "Practical Web Cache Poisoning" (2018) và "Web Cache Entanglement" (2020). Định nghĩa lớp lỗ hổng này và cho thấy nó tồn tại trên nhiều site lớn qua các header unkeyed như X-Forwarded-Host, X-Forwarded-Scheme. Đây là nguồn của bảng dạng ở khối 3, và của kỹ thuật phát hiện bằng canary marker ở khối 4.

Các sự cố CDN thực tế (nhiều báo cáo). Nhiều báo cáo bug bounty mô tả cùng mẫu: một header phản chiếu cộng một CDN cache theo mặc định, cho phép một request đầu độc trang chủ hoặc một tài nguyên JS dùng chung cho mọi người dùng. Đáng nhớ vì hậu quả nhân theo quy mô của cache: một request, hàng triệu nạn nhân.

Cache poisoning DoS (CPDoS, nghiên cứu 2019). Một họ tấn công dùng header dị dạng để làm server trả lỗi rồi làm cache lưu lỗi đó — biến cache thành một công cụ từ chối dịch vụ. Minh hoạ hàng cuối bảng khối 3: cache poisoning không chỉ là XSS, nó là bất cứ response xấu nào bạn ép được vào cache.

1. Kỹ thuật canary — phép kiểm cốt lõi, và nó là hai bước:

B=https://staging.example.comM="canary$RANDOM"# Bước 1: gửi header unkeyed với marker, xem nó có phản chiếu vào response không.curl -s "$B/" -H "X-Forwarded-Host: $M.evil" | grep -q "$M" \  && echo "phản chiếu — nguy hiểm nếu bị cache" || { echo "không phản chiếu, ok"; exit 0; }# Bước 2: gửi request BÌNH THƯỜNG (không header) và xem marker còn không.sleep 1curl -s "$B/" | grep -q "$M" && { echo "CACHE ĐÃ BỊ ĐẦU ĐỘC"; exit 1; }exit 0

2. Thử qua nhiều header unkeyed — bảng ở khối 3 là danh sách bắt đầu:

for h in X-Forwarded-Host X-Forwarded-Scheme X-Host X-Forwarded-Server X-Original-URL; do  M="c$RANDOM"  curl -s "$B/" -H "$h: $M" > /dev/null  curl -s "$B/" | grep -q "$M" && echo "ĐẦU ĐỘC được qua $h"done

3. Grep app dùng header phản chiếu vào response — cùng phép kiểm topic host-header:

grep -rnE 'X-Forwarded-Host|X-Forwarded-Scheme|Request\.Host' --include='*.cs' src/ \  | grep -viE 'ForwardedHeaders|HostFiltering' \  && echo "CẢNH BÁO: có thể phản chiếu header vào response"

4. Kiểm response lỗi KHÔNG được cache (CPDoS):

# Ép một 400 rồi kiểm nó không có Cache-Control public.curl -sI "$B/" -H 'X-Forwarded-Host: a\r\nb' | grep -iE 'cache-control|^HTTP'# 4xx/5xx phải là no-store/private, không public.

5. Kiểm cấu hình cache key ở CDN — đây là nơi bản vá thật sống. Xác nhận header nào app dùng để dựng response đều nằm trong cache key của CDN, hoặc app không dùng chúng. Đây là kiểm cấu hình, không phải test code.

Sai lầm về mô hình, và nó là sai lầm chính: nghĩ cache key mặc định (method + path) là đủ. Cache poisoning là một sự BẤT ĐỒNG giữa "cache nghĩ request này là gì" và "app dựng response từ gì". Mọi input mà app dùng nhưng cache bỏ qua là một lỗ hổng.

Sai lầm về vị trí: tìm bản vá trong code ứng dụng. Như topic request-smuggling, bản vá gần như luôn ở cấu hình cache/CDN — cache key gồm gì, cache gì, TTL bao lâu. Code chỉ liên quan ở chỗ nó có phản chiếu input hay không (lớp 1).