Önbelleğin Sessiz İhaneti: Unkeyed Header'lar ile Web Cache Poisoning

GET /static/common.js HTTP/1.1\nHost: testCompany.com\nX-Forwarded-Host: attacker-controlled-domain.com\n\nİsteğini gönderdiğinde ve sunucudan 200 OK cevabı aldığında, eğer o 'attacker-controlled-domain.com' adresi JavaScript dosyasının içindeki bir URL'e enjekte edilmişse ve bu yanıt CDN veya Varnish tarafından önbelleğe alınmışsa, geçmiş olsun; artık tüm kullanıcıların senin kontrolündeki bir script'i yüklüyor.\n\nWeb Cache Poisoning (Web Önbellek Zehirlenmesi), modern web mimarilerinin performans can simidi olan cache mekanizmalarını, kullanıcıları hedef alan bir silaha dönüştürme sanatıdır. Çoğu zaman gözden kaçar çünkü biz Red Team tarafında 'input validation' denilince hep form alanlarına, URL parametrelerine odaklanırız. Oysa HTTP header'larının karanlık dehlizlerinde, 'unkeyed' yani önbellek anahtarına dahil edilmeyen ama uygulama tarafından işlenen parametreler yatar.\n\n### Cache Key Nedir, Neden Canımızı Yakar?\n\nBir önbellek mekanizması (Cloudflare, Akamai, Varnish veya Nginx), gelen bir isteği daha önce kaydedip kaydetmediğini anlamak için bir 'Cache Key' (Önbellek Anahtarı) oluşturur. Genellikle bu anahtar şunlardan oluşur:\n- Request Method (GET, POST)\n- Path (/index.php)\n- Query Strings (?id=5)\n- Host Header (testCompany.com)\n\nBuradaki kritik sorun şudur: Uygulama, isteğin içindeki diğer header'ları (Örn: X-Forwarded-Host, X-Forwarded-Proto, User-Agent) kullanıp bir sayfa üretiyorsa ama bu header'lar 'Cache Key' içinde yer almıyorsa, zehirlenme için ilk kapı aralanmış demektir. \n\nSen bir saldırgan olarak (veya sızma testi yapan bir dostun olarak), önbelleği manipüle eden bir header gönderirsin. Cache mekanizması bakar: "Metot GET, path aynı, host aynı... Tamam, bu isteği işleyip cevabını kaydedeyim ve herkese aynısını vereyim" der. Ama o cevabın içinde senin gönderdiğin zehirli X-Forwarded-Host içeriği vardır.\n\n### Senaryo: JavaScript Enjeksiyonu\n\nŞimdi gel, testCompany ortamında bir senaryo kurgulayalım. Uygulamanın statik dosyaları bir CDN üzerinden dağıttığını varsayalım. Uygulama kodunda da şöyle bir hata var; gelen X-Forwarded-Host header'ını alıp, sayfadaki bir asset'in base URL'i olarak kullanıyor.\n\nZararsızlaştırılmış (defanged) örnek saldırı isteği:\n\nhttp\nGET /common-lib.js HTTP/1.1\nHost: testCompany.com\nX-Forwarded-Host: 127.0.0.1/js-poison?data=\n\n// Sunucunun döndüğü ve cache'lenen yanıt:\nHTTP/1.1 200 OK\nCache-Control: public, max-age=3600\n...\nvar apiUrl = "http://127.0.0.1/js-poison?data=/api/v1";\n\n\nBurada saldırgan 127.0.0.1 yerine kendi kontrolündeki attacker-cdn.com gibi bir adres yazarsa, o andan itibaren o JS dosyasını isteyen her kullanıcı, API çağrılarını saldırganın sunucusuna yapar. Bu tam anlamıyla bir felaket senaryosu. Üstelik bu durum logs'larda 'normal bir GET isteği' olarak görünür, hiçbir WAF kuralına takılmaz çünkü header içinde XSS payload'u bile olmayabilir, sadece bir domain değişikliği yeterlidir.\n\n### Peki, Avcıyken Avlanmamak İçin Ne Yapacağız? (Defensive Taktikler)\n\nRed Team olarak bu açıkları bulmak zevkli olsa da, asıl amacımız sistemi kale gibi korumak. Web Cache Poisoning'i engellemek için üç ana kuralımız var:\n\n1. Header Stripping (Header Temizliği): Eğer uygulaman X-Forwarded-Host veya X-Original-URL gibi header'lara gerçekten ihtiyaç duymuyorsa, bu header'ları daha yük dengeleyici (Load Balancer) seviyesinde içeri almadan çöpe at. 'İhtiyacım olmayan header'ın başı ağrımaz' mantığı hayat kurtarır.\n\n2. Vary Header Kullanımı: HTTP Vary header'ı, önbellek anahtarına ek header'lar dahil edilmesini sağlar. Örneğin; Vary: X-Forwarded-Host dersen, cache mekanizması bu header her değiştiğinde yeni bir cache kaydı oluşturur. Bu, zehirlenmeyi zorlaştırır ama cache hit oranını düşürebilir. Mühendislikte her şey bir 'trade-off' (dengeleme) meselesidir.\n\n3. Parametreleri Keyed Hale Getirmek: CDN konfigürasyonunda, hangi header'ların cache key'e dahil edileceğini manuel olarak belirle. Eğer bir header sayfa içeriğini değiştiriyorsa, o header mutlaka cache key'in bir parçası olmalı.\n\n### Pratik Bir Kontrol Listesi\n\nSistemi test ederken veya geliştirirken kendine şunları sor:\n- Uygulamam hangi 'unkeyed' header'ları kullanıyor? (Burp Suite Param Miner eklentisi bu konuda can dostudur).\n- Bu header'ların içeriği doğrudan HTML çıktısına veya JS koduna yansıyor mu?\n- Cache mekanizması (Cloudflare vb.) hangi header'ları görmezden geliyor?\n\nÖzellikle X-Rewrite-URL, X-Host, X-Forwarded-Scheme gibi header'lar her zaman şüpheli listesinde en üstte olmalı. Bir geliştirici olarak, kullanıcıdan gelen hiçbir veriye (header dahil) güvenmemen gerektiğini zaten biliyorsun ama cache katmanı bu güveni bir kat daha kırılgan hale getiriyor.\n\n### Son Bir Geek Tavsiyesi\n\nEğer bir gün loglarda garip bir şekilde statik dosyaların domain adreslerinin değiştiğini görürsen veya kullanıcılar 'login olamıyorum, yönlendirme hatası alıyorum' diye bağırıyorsa, veritabanına bakmadan önce CDN/Varnish temizliğini (Purge) bir dene. Bazen bir saldırgan, bazen de yanlış konfigüre edilmiş bir proxy sunucusu önbelleği çoktan zehirlemiş olabilir. \n\nUnutma, web güvenliği sadece kod yazmak değil, paketin geçtiği her duraktaki mantık hatalarını görebilmektir. Cache katmanı ise bu durakların en sinsi olanıdır. Tetikte kal.