Selamlar ben Mysorfilox bu gün ki konumuz HTTP Host Header Injection.
HTTP/1.1 ile birlikte Host başlığı zorunlu hale gelmiştir ve sunucuya hangi alan adına (domain) istek yapıldığını bildirir. Ancak bazı uygulamalar bu başlığın kullanıcı tarafından tamamen kontrol edilebilir olduğunu göz ardı eder.
Sonuç olarak saldırgan, Host başlığını manipüle ederek uygulamanın:
kendi kontrol ettiği bir alan adına yönlendirebilir.
Temel sebepler şunlardır:
Örnek mantık:
Bu yaklaşım, saldırganın isteği kendi belirlediği bir Host ile göndermesine kapı açar.
Eğer bu URL’ler Host üzerinden oluşturuluyorsa, saldırganın verdiği Host değeri doğrudan bu linklerin içine girer.
gibi zincirleme problemlere yol açar.
Savunma katmanı olmadığında Host başlığı uygulamaya ham haliyle ulaşır.
Uygulama, bu değeri alır ve örneğin:
Uygulama bunu fark etmezse:
linkler saldırgan alan adına yazılır
Örnek:
Bu link oluşturulurken bazı uygulamalar:
Sonra bir kullanıcı adı veya e-postasını yazalım ve yenileme isteği gönderelim
Sonra Burp’te POST isteği yakalanacak bu isteği görelim
Sonra bu yakaladığımız istek içeriğini değiştirelim host bilgisi kısmını değiştirip exploit sunucumuzun adresini girelim
Sonra bu düzelttiğimiz isteği gönderelim
Sonra exploit sunucumuzun loglaranı görüntülüyoruz ve görüyoruz ki şifre sıfırlama tokeni loglara düşmüş bu tokeni kopyalıyoruz
Sonra bu kopyaladığımız tokeni web sitenin linki ile giriyoruz
Ve tebrikler şifre sıfırlama ekranına geldik
Artık şifreyi değiştiriyoruz ve giriş yapıyoruz.
Umarım konumu beğenmişsinizdir elimden geldikçe uğraştım eksikler için şimdiden kusuruma bakmasın arkadaşlar.
HTTP Host Header Injection Nedir?
HTTP Host Header Injection, bir web uygulamasının istemciden gelen Host başlığına güvenmesi ve bu değeri doğrulamadan uygulama içinde kullanması sonucu ortaya çıkan bir sunucu tarafı zafiyettir.HTTP/1.1 ile birlikte Host başlığı zorunlu hale gelmiştir ve sunucuya hangi alan adına (domain) istek yapıldığını bildirir. Ancak bazı uygulamalar bu başlığın kullanıcı tarafından tamamen kontrol edilebilir olduğunu göz ardı eder.
Sonuç olarak saldırgan, Host başlığını manipüle ederek uygulamanın:
- bağlantı üretme mantığını
- yönlendirme mekanizmalarını
- cache davranışını
- parola sıfırlama linklerini
kendi kontrol ettiği bir alan adına yönlendirebilir.
Bu Zafiyet Neden Ortaya Çıkar?
Bu açık, genellikle uygulama geliştiricilerinin Host başlığını güvenilir kabul etmesinden kaynaklanır.Temel sebepler şunlardır:
1. Host Başlığının Doğrulanmaması
Uygulama, gelen istekteki Host değerini:- whitelist ile kontrol etmez
- sabit bir konfigürasyondan almaz
- framework varsayılanına bırakır
Örnek mantık:
- “İstek hangi domainden geldiyse linkleri ona göre üret”
Bu yaklaşım, saldırganın isteği kendi belirlediği bir Host ile göndermesine kapı açar.
2. Dinamik URL Üretimi
Birçok uygulama şu işlemleri yaparken Host başlığını kullanır:- Parola sıfırlama linki oluşturma
- Email doğrulama linki üretme
- Absolute URL (https://site.com/path) üretme
- Redirect URL belirleme
Eğer bu URL’ler Host üzerinden oluşturuluyorsa, saldırganın verdiği Host değeri doğrudan bu linklerin içine girer.
3. Reverse Proxy / Cache Katmanları ile Uyumsuzluk
Cache sunucuları, load balancer’lar veya reverse proxy’ler:- isteği farklı yorumlayabilir
- bazı header’ları göz ardı edebilir
- backend ile farklı davranış sergileyebilir
- cache poisoning
- auth bypass
- yanlış kullanıcıya içerik gösterimi
gibi zincirleme problemlere yol açar.
4. Güvenlik Katmanlarının Olmaması veya Yanlış Konfigürasyon
Bu zafiyet en sık şu ortamlarda görülür:- WAF olmayan sistemler
- Cloudflare / benzeri servislerin kapalı olduğu sunucular
- Development veya test ortamları
- Eski framework ve CMS sürümleri
Savunma katmanı olmadığında Host başlığı uygulamaya ham haliyle ulaşır.
Teknik Olarak Ne Olur?
HTTP isteği şu şekilde gelir:
Kod:
GET / HTTP/1.1
Host: ornek-site.comUygulama, bu değeri alır ve örneğin:
- Email içeriğinde link üretir
- Redirect URL oluşturur
- Cache key belirler
Kod:
Host: saldirgan-site.comlinkler saldırgan alan adına yazılır
- cache zehirlenir
- kullanıcı yanlış yere yönlendirilir
Password Reset Poisoning
Bu bölümde, parola sıfırlama zehirlenmesi (Password Reset Poisoning) zafiyetinin nasıl çalıştığını anlamak ve Burp Suite kullanarak nasıl tespit edilebildiğini ele alıyoruz.Senaryo Tanımı
Birçok web uygulamasında parola sıfırlama süreci şu şekilde işler:- Kullanıcı “Şifremi unuttum” sayfasına gider
- Kullanıcı adı veya e-posta girilir
- Sunucu, kullanıcıya bir şifre sıfırlama linki içeren e-posta gönderir
- Bu link genellikle tam (absolute) URL olarak oluşturulur
Örnek:
Kod:
https://site.com/reset?token=XYZ- domain bilgisini konfigürasyondan almak yerine
- HTTP Host header üzerinden üretir İşte zafiyet tam bu noktada ortaya çıkar.
Sonra bir kullanıcı adı veya e-postasını yazalım ve yenileme isteği gönderelim
Sonra Burp’te POST isteği yakalanacak bu isteği görelim
Sonra bu yakaladığımız istek içeriğini değiştirelim host bilgisi kısmını değiştirip exploit sunucumuzun adresini girelim
Sonra bu düzelttiğimiz isteği gönderelim
Sonra exploit sunucumuzun loglaranı görüntülüyoruz ve görüyoruz ki şifre sıfırlama tokeni loglara düşmüş bu tokeni kopyalıyoruz
Sonra bu kopyaladığımız tokeni web sitenin linki ile giriyoruz
Ve tebrikler şifre sıfırlama ekranına geldik
Artık şifreyi değiştiriyoruz ve giriş yapıyoruz.
Umarım konumu beğenmişsinizdir elimden geldikçe uğraştım eksikler için şimdiden kusuruma bakmasın arkadaşlar.
Son düzenleme:
