Web Cache Deception via URL Parsing Discrepancy — PII Disclosure & Cache Poisoning

Merhaba, global ölçekte faaliyet gösteren bir kuruluşta tespit etmiş olduğum Web Cache Deception (WCD) zafiyetini teknik açıdan paylaşmak istiyorum.

Zafiyetin temelinde, cache katmanı ile origin uygulamasının aynı URL'yi farklı şekilde parse etmesi ve canonicalize etmesi bulunuyordu.

Hedef endpoint: GET /api/users/profile

Kullandığım primitive, URL'ye cache katmanının statik bir dosya/resource olarak değerlendirebileceği bir suffix eklemekti: /api/users/profile%3f%26deneme.webp

Kritik nokta, aynı request'in farklı katmanlarda farklı yorumlanmasıydı.

Cache layer: URL'yi .webp ile biten cacheable bir resource olarak değerlendirdi.

Origin application: URL'yi normalize ettikten sonra gerçek endpointi: /api/users/profile olarak işledi.

Sonuç: Saldırgan kontrollü URL → Cache statik kaynağı görüyor → Origin authenticated API endpointi görüyor → Kimliği doğrulanmış PII response'u cache'leniyor → Kimlik doğrulaması olmadan erişim

Aynı URL canonicalization / cache-key primitive'i üzerinden cache poisoning etkisi de gözlemlenebildi.

Bu bulgu, modern web uygulamalarında yalnızca application logic'in değil, request'in geçtiği tüm parsing ve normalization katmanlarının incelenmesi gerektiğini gösteriyor: Browser → CDN → Reverse Proxy → WAF → Cache → Load Balancer → Application

Bu katmanlardan herhangi ikisinin URL'yi farklı yorumlaması, güvenlik sınırlarının beklenmedik şekilde aşılmasına neden olabilir. Ayrıca cache poisoning tek başına değerlendirilmemeli. XSS gibi başka bir vulnerability ile zincirlendiğinde etki ciddi şekilde büyüyebilir:

Cache Poisoning → Stored XSS → Unauthorized Action / ATO

Başlangıçta bir URL parsing veya cache davranışı problemi olarak görünen bir bulgu, doğru primitive ve vulnerability chaining ile çok daha yüksek etkili bir saldırı zincirine dönüşebilir.

#WebCacheDeception #CachePoisoning #XSS #WebSecurity #AppSec #WebApplicationSecurity #bugbounty