Web Önbellek Zehirlenmesi (Cache Poisoning) Nedir ve Nasıl Korunulur?
Bir saldırganın önbelleğin görmezden geldiği bir istek başlığına zararlı değer koyarak kirli bir yanıtı önbelleğe kaydetmesine cache poisoning denir. Nasıl çalıştığı, gerçek zehirlenme ile zararsız SPA davranışının nasıl ayırt edileceği ve nasıl önlenir.
Hızlı cevap: Web önbellek zehirlenmesi (cache poisoning), bir saldırganın özel olarak hazırlanmış bir isteği bir web sunucusuna ya da CDN'e (içerik dağıtım ağına) göndererek, sunucunun normalde önbelleğe almaması gereken zararlı ya da kişiselleştirilmiş bir yanıtı önbelleğe kaydetmesini sağlaması ve bu zehirli yanıtın ardından o adrese gelen tüm masum ziyaretçilere servis edilmesidir. Sorunun kökü genelde önbelleğin, yanıtı hangi isteklere ait sayacağına karar verirken bazı istek başlıklarını ya da parametrelerini görmezden gelmesidir; saldırgan görmezden gelinen bu kısma zararlı bir değer koyar, sunucu farklı bir yanıt üretir ama önbellek bunu görmezden geldiği için "aynı istek" sayıp kaydeder. Bu, tek bir istekle binlerce kullanıcıyı aynı anda etkileyebilen, bu yüzden klasik bir kişisel saldırıdan çok daha geniş kapsamlı bir zafiyet sınıfıdır.
Bir web sitesi her ziyaretçi için sayfayı sıfırdan üretmek yerine, sık istenen bir sayfanın yanıtını bir kez üretip bir süre saklar ve sonraki aynı istekleri bu saklanan kopyadan (önbellekten) hızlıca karşılar. Bu, performans için gereklidir ama önbelleğin "hangi istekler gerçekten aynı sayılır" kararını yanlış vermesi, bir saldırganın kendi zararlı isteğini masum bir adresin önbelleğine sızdırmasına kapı açar.
Zehirlenme nasıl gerçekleşir
Bir önbellek, gelen bir isteğin daha önce önbelleğe alınmış bir yanıtla eşleşip eşleşmediğine karar verirken genelde sadece URL yolunu dikkate alır; X-Forwarded-Host, X-Forwarded-Scheme gibi bazı özel başlıkları ya da bazı sorgu parametrelerini bu karara dahil etmez. Ancak arkadaki uygulama sunucusu bu görmezden gelinen başlığı okuyup yanıtın içine (örneğin bir yönlendirme bağlantısına ya da bir script etiketine) yerleştirebilir. Saldırgan, X-Forwarded-Host başlığına kendi kontrolündeki bir alan adını yazıp isteği gönderdiğinde, uygulama bu değeri sayfaya gömer, önbellek ise başlığı görmediği için bu kirli yanıtı "normal" bir yanıt olarak saklar. O andan itibaren aynı URL'ye gelen her ziyaretçi, saldırganın alan adına yönlendiren ya da onun script'ini çalıştıran zehirli sayfayı görür.
| Adım | Ne olur |
|---|---|
| Keşif | Önbelleğin hangi başlıkları görmezden geldiği tespit edilir |
| Enjeksiyon | Görmezden gelinen alana zararlı bir değer yazılan istek gönderilir |
| Kaydetme | Sunucunun ürettiği kirli yanıt önbellekte saklanır |
| Yayılma | Aynı adrese gelen tüm sonraki ziyaretçiler kirli yanıtı görür |
Neden özellikle tehlikeli
Klasik bir siteler arası betik çalıştırma (XSS) açığı genelde tek bir isteği ya da tek bir kullanıcıyı etkiler; bir önbellek zehirlenmesi ise bir kez başarılı olduğunda, önbellek süresi dolana ya da manuel olarak temizlenene kadar o adrese gelen herkesi etkiler. Bu, saldırganın tek bir istekle potansiyel olarak binlerce kullanıcıya aynı anda kötü amaçlı içerik, sahte yönlendirme ya da kimlik hırsızlığı sayfası sunabileceği anlamına gelir; kavramsal olarak HTTP istek kaçakçılığına (request smuggling) benzer, çünkü ikisi de önbellek ya da ara katman bileşenlerinin isteği yorumlama şeklindeki bir uyuşmazlıktan kaynaklanır.
Gerçek dünyada nasıl karşımıza çıkar
Bir önbellek zehirlenmesi bulgusu ilk bakışta zararsız görünebilir; örneğin statik bir dosya uzantısına (bir yazı tipi dosyası, bir resim) sahip bir yolun aslında dinamik bir uygulama tarafından üretildiği ve tamamen farklı bir içerik döndürdüğü fark edilebilir. Ancak bu durum tek başına bir zehirlenme kanıtı değildir; birçok modern tek sayfa uygulaması (SPA), var olmayan her yola aynı HTML kabuğunu döndürecek şekilde tasarlanmıştır ve bu, "önbellek zehirlenmesi" ile karıştırılabilecek zararsız bir davranıştır. Gerçek bir zehirlenmeyi kanıtlamanın tek yolu, önbelleğin görmezden geldiği alana benzersiz bir işaret (canary) koyup, farklı bir istemciden aynı adrese tekrar istek göndererek bu işaretin gerçekten önbellekten servis edildiğini doğrulamaktır.
Nasıl önlenir
Savunmanın temeli, önbelleğin bir yanıtı önbelleğe alırken kullandığı anahtarın (cache key), uygulamanın yanıtı üretirken kullandığı tüm girdileri kapsamasıdır; eğer uygulama bir başlığı okuyorsa, önbellek de o başlığı anahtara dahil etmelidir, ya da daha güvenli bir yaklaşımla uygulama güvenilmeyen başlıkları hiç okumamalıdır. Bunun yanında CDN ve ters proxy yapılandırmaları düzenli olarak gözden geçirilmeli ve hangi başlıkların önbellek kararına dahil edildiği açıkça belgelenmelidir; bu, genel WAF ve web uygulama güvenlik duvarı yapılandırmasının bir parçası olarak ele alınmalıdır.
KAOS ve DSET yaklaşımı
DSET, bir önbellek zehirlenmesi hipotezini asla tek bir gözleme dayanarak kesin bulgu saymaz; canary tabanlı bir doğrulama ile, işaretlenen içeriğin gerçekten önbellekten ve farklı bir istemciye servis edildiğini kanıtlar. Yerel yapay zekâ motorumuz KAOS, şüpheli bir önbellek davranışını otomatik olarak tespit ettiğinde bunu doğrudan "yüksek" olarak raporlamaz; önce görmezden gelinen başlıkları test eder, ardından canary enjeksiyonu ile gerçek bir zehirlenme mi yoksa normal bir uygulama davranışı (örneğin bir SPA'nın yol yakalama mekanizması) mı olduğunu ayırt eder. Bu disiplin, yanlış pozitif bir "yüksek önemli" bulgu ile gerçek bir riski birbirinden ayırmanın tek güvenilir yoludur.
Sık sorulan sorular
Her CDN kullanan site önbellek zehirlenmesine açık mıdır? Hayır. Risk, CDN kullanmaktan değil, önbelleğin hangi girdileri göz önünde bulundurduğu ile uygulamanın hangi girdileri kullandığı arasındaki uyuşmazlıktan kaynaklanır. İyi yapılandırılmış bir önbellek, uygulamanın okuduğu her başlığı ve parametreyi kendi anahtarına dahil ederek bu riski ortadan kaldırır.
Bir site .woff ya da .css gibi statik bir yola her istekte aynı HTML'i döndürüyorsa bu her zaman bir zafiyet midir? Hayır, bu tek başına bir kanıt değildir. Pek çok modern tek sayfa uygulaması, var olmayan her yola aynı kabuk HTML'i döndürür; bu normal bir davranıştır. Bunun gerçek bir önbellek zehirlenmesi olup olmadığı, ancak görmezden gelinen bir girdiye zararlı bir değer enjekte edip bunun önbellekten farklı bir istemciye servis edildiğinin doğrulanmasıyla anlaşılabilir.
Önbellek zehirlenmesi ile önbellek atlatma (cache deception) aynı şey midir? Hayır, ilişkili ama farklıdır. Önbellek zehirlenmesinde saldırgan sunucunun ürettiği yanıtı manipüle eder ve bu kirli yanıt herkese servis edilir; önbellek atlatmada ise saldırgan başka bir kullanıcıya özel, kişiselleştirilmiş bir yanıtın yanlışlıkla önbelleğe alınmasını sağlayarak o kişiye ait bilgiyi kendisine servis ettirir.
Kaynaklar
- OWASP Web Cache Poisoning: https://owasp.org
- PortSwigger Web Cache Poisoning Academy: https://portswigger.net
- DSET Siber Güvenlik ve Web Uygulama Sızma Testi Hizmetleri: https://dset.com.tr/hizmetler
Web siteniz ya da CDN yapılandırmanızın önbellek zehirlenmesine açık olup olmadığını kanıta dayalı biçimde test etmek için DSET ile iletişime geçin. Ankara Hacettepe Teknokent laboratuvarımızdan web güvenliği danışmanlığı sağlıyoruz.
Kimliğinizi doğrulayın
Yetkilendirilmiş erişim alanı. Tüm giriş denemeleri kayıt altına alınır.