Web cache deception

Điều phải nắm: cache deception khai thác một sự bất đồng về hậu tố URL. Cache thường quyết định "cache hay không" theo phần mở rộng — .css, .js, .jpg là tĩnh, cache được. Nhưng nhiều server bỏ qua phần thừa của URL và vẫn phục vụ trang động. Ghép hai điều đó lại:

• Kẻ tấn công lừa nạn nhân mở https://app.example/account/profile.css.
• Server bỏ qua /profile.css, phục vụ trang /account/profile của nạn nhân (kèm dữ liệu cá nhân).
• Cache thấy đuôi .css, nghĩ đây là tĩnh, và LƯU response — kèm dữ liệu riêng của nạn nhân.
• Kẻ tấn công mở cùng URL .../profile.css, cache phục vụ bản đã lưu → đọc được dữ liệu nạn nhân.

Điểm khác biệt với cache poisoning: poisoning ghi một bản độc vào cache công khai; deception đọc một bản riêng tư ra khỏi cache. Cả hai là cùng gốc — cache và server bất đồng — nhưng hướng ngược nhau.

Và giống hai topic cache/smuggling khác: bản vá ở cấu hình cache, không ở code. Nó là một lỗi của việc cache quyết định "cache gì" theo một quy tắc (phần mở rộng) khác với quy tắc server dùng để quyết định "phục vụ gì".

Cơ chế là bất đồng về hậu tố URL giữa cache (quyết định theo phần mở rộng) và server (bỏ qua phần thừa).

sequenceDiagram    autonumber    actor A as Kẻ tấn công    actor V as Nạn nhân (đã đăng nhập)    participant C as Cache (cache theo .css)    participant S as Server (bỏ qua /profile.css)    A->>V: Lừa mở link /account/profile.css    V->>C: GET /account/profile.css<br/>Cookie: session=<của nạn nhân>    C->>S: chuyển tiếp (chưa có trong cache)    S-->>C: 200, trang profile của NẠN NHÂN<br/>(server bỏ qua .css)    Note over C: Cache thấy đuôi .css → nghĩ TĨNH → LƯU response<br/>(kèm dữ liệu riêng của nạn nhân).    A->>C: GET /account/profile.css (KHÔNG cookie)    C-->>A: bản đã lưu — dữ liệu của NẠN NHÂN

Điểm cốt lõi: cache lưu một trang cần đăng nhập vì nó tưởng đó là tĩnh. Kẻ tấn công không cần phiên nạn nhân để đọc — cache phục vụ bản đã lưu cho bất kỳ ai hỏi cùng URL, kể cả không cookie.

Bảng điều kiện — cả hai phải đúng thì mới khai thác được:

Các biến thể ở phần "server bỏ qua phần thừa": không chỉ .css. /account/profile/xyz (path thừa), /account/profile;.css (path parameter), /account/profile%00.css (null byte), /account/profile.css?x=1 — mỗi cách là một sự bất đồng khác giữa cách server parse URL và cách cache quyết định. Đây là lý do blocklist phần mở rộng không đủ (giống các topic injection).

Một trang tài khoản GET /account/profile cần đăng nhập, sau một CDN cache theo phần mở rộng.

# Kẻ tấn công lừa nạn nhân mở URL này (qua email, link chat). Nạn nhân đã đăng nhập.GET /account/profile.css HTTP/1.1Host: app.exampleCookie: session=<phiên của nạn nhân>

# Server BỎ QUA ".css" và phục vụ trang profile động của nạn nhân:HTTP/1.1 200 OKContent-Type: text/htmlCache-Control: private, no-store       ← trang NÓI đừng cache <h1>Alice Nguyen</h1><p>Email: alice@acme.com · Thẻ: **** 4242</p>

# Nhưng CACHE quyết định theo ĐUÔI .css và BỎ QUA Cache-Control: private của trang.# Nó lưu response — kèm dữ liệu của Alice — dưới key /account/profile.css.

# Kẻ tấn công mở cùng URL, KHÔNG cần cookie của Alice:GET /account/profile.css HTTP/1.1Host: app.example(không cookie) HTTP/1.1 200 OK  (từ cache)<h1>Alice Nguyen</h1><p>Email: alice@acme.com · Thẻ: **** 4242</p>   ← dữ liệu của Alice

# Phát hiện: mở một trang riêng tư với đuôi tĩnh giả, rồi mở lại KHÔNG cookie.curl -s https://app.example/account/profile.css -b "session=$MY_SESSION" > /dev/nullcurl -s https://app.example/account/profile.css | grep -q "alice@acme.com" \  && echo "CACHE DECEPTION: dữ liệu riêng đọc được không cần cookie"

# Sau khi vá: cache tôn trọng Cache-Control: private, VÀ server từ chối /profile.css# (không bỏ qua phần thừa), VÀ cache chỉ lưu theo Content-Type thật, không theo đuôi.

Omer Gil — "Web Cache Deception Attack" (Black Hat 2017). Bài trình bày định nghĩa lớp lỗ hổng này và cho thấy nó hoạt động trên các dịch vụ lớn (bao gồm một demo nổi tiếng trên PayPal thời điểm đó): mở một URL trang tài khoản với đuôi .css, và cache lưu trang có dữ liệu cá nhân. Đây là nguồn của bảng điều kiện ở khối 3.

Các sự cố CDN theo mặc định cache-by-extension (nhiều báo cáo). Nhiều CDN mặc định cache mọi thứ có đuôi tĩnh, và mặc định đó ghi đè Cache-Control: private của app. Nên một app đúng (đặt no-store cho trang tài khoản) vẫn bị deception nếu CDN cấu hình cache-by-extension. Minh hoạ luận điểm khối 2: bản vá ở cấu hình cache, không ở code app.

Nghiên cứu mở rộng của Kettle/Gil về các biến thể URL (2020). Cho thấy .css chỉ là một cách; path thừa, path parameter (;), null byte, và các cách parse URL khác giữa cache và server đều mở ra deception. Đây là lý do khối 6 nói bản vá phải là "cache và server ĐỒNG Ý về URL này là gì", không phải "chặn đuôi .css".

1. Kỹ thuật canary — phép kiểm cốt lõi, và nó là hai bước (giống cache poisoning nhưng đọc, không ghi):

B=https://staging.example.com# Bước 1: đăng nhập bằng tài khoản test, mở trang riêng tư với đuôi tĩnh giả.curl -s "$B/account/profile.css" -b "session=$TEST_SESSION" | grep -q "$TEST_EMAIL" \  && echo "server bỏ qua .css và phục vụ trang riêng"# Bước 2: mở CÙNG URL không cookie — dữ liệu test KHÔNG được xuất hiện.sleep 1curl -s "$B/account/profile.css" | grep -q "$TEST_EMAIL" \  && { echo "CACHE DECEPTION: dữ liệu riêng đọc được không cần đăng nhập"; exit 1; }exit 0

2. Thử nhiều biến thể URL — bảng ở khối 3: không chỉ .css:

for u in /account/profile.css /account/profile.js /account/profile/x \         "/account/profile;.css" "/account/profile%00.css"; do  curl -s "$B$u" -b "session=$TEST_SESSION" > /dev/null  curl -s "$B$u" | grep -q "$TEST_EMAIL" && echo "DECEPTION qua $u"done

3. Kiểm server TỪ CHỐI đường dẫn có đuôi thừa (nửa phía server ở lớp 1b):

# /account/profile.css phải là 404, không phục vụ /account/profile.curl -s -o /dev/null -w '%{http_code}\n' "$B/account/profile.css" -b "session=$TEST_SESSION"# Mong đợi 404. Nếu 200 → server bỏ qua phần thừa, điều kiện 1 của khối 3 đúng.

4. Kiểm cache tôn trọng Cache-Control: private — đây là kiểm cấu hình CDN:

# Response của trang riêng phải có Cache-Control private/no-store...curl -sI "$B/account/profile" -b "session=$TEST_SESSION" | grep -i cache-control# ...VÀ CDN phải tôn trọng nó (không cache-by-extension). Kiểm cấu hình CDN trực tiếp.

5. Kiểm allowlist cache (lớp 2) — xác nhận cấu hình CDN chỉ cache các prefix tĩnh đã biết (/_next/static, /assets), mọi thứ khác mặc định không cache. Đâ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-Control: private ở app là đủ. Nhiều CDN cache theo phần mở rộng và ghi đè header đó — nên bản vá phải ở cấu hình cache: tôn trọng Cache-Control, cache theo Content-Type, và allowlist prefix tĩnh.

Sai lầm về vị trí: tìm bản vá trong code. Như request-smuggling và web-cache-poisoning, đây là một lỗi của sự BẤT ĐỒNG giữa hai thành phần hạ tầng (cache và server) về "URL này là gì", nên bản vá sống ở nơi giải quyết bất đồng đó — cấu hình cache và định tuyến server, không phải một handler.