Host Header Injection – Adım Adım Deneyimim

[Dr Toretto]

Bir gün evde kendi lab ortamımı kurarken şöyle bir şey fark ettim:
Çoğu kişi XSS, SQLi falan deniyor ama HTTP başlıklarıyla pek oynanmıyor.
Ben de dedim ki, “Acaba şu Host başlığını değiştirsem ne olur?”

​

Lab Ortamı Kurulumu

Kendi bilgisayarımda ufak bir test ortamı kurdum:

# DVWA veya basit bir PHP site için
docker run -d -p 8080:80 vulnerables/web-dvwa

Tarayıcıdan http://localhost:8080 adresine girdim.
Burp Suite’i açıp gelen istekleri izlemeye başladım.

İlk Deneme

Normal login isteği şöyleydi:

GET /login.php HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0

Dedim ki, “Ya bu host değerini değiştirsem?”
Ve değiştirdim:

GET /login.php HTTP/1.1
Host: attacker.com
User-Agent: Mozilla/5.0

Sonuç?

Sayfa yine geldi ama “linkler” ve bazı yönlendirmeler attacker.com üzerinden dönmeye başladı.

Gerçek Gücü Ne Zaman Fark Ettim?

Şifre sıfırlama kısmında e-posta adresimi girdim.
Normalde bana http://localhost:8080/reset?token=1234 gibi link gelmesi gerekirken,
bu kez link şu şekildeydi:

http://attacker.com/reset?token=1234

O an fark ettim:
Bir saldırgan bu açığı kullanarak reset linklerini kendi alanına yönlendirebilir.
Yani kurban “benim siteye güveniyor” sanıp saldırgana tıklar.

Küçük Python Denemem

Bunu görmek için bir de Python ile test ettim:

import requests

url = "http://localhost:8080/login.php"
headers = {
    "Host": "evil.com",
    "User-Agent": "Mozilla/5.0"
}

r = requests.get(url, headers=headers)
print("Durum:", r.status_code)
print("Örnek cevap:", r.text[:200])

Çalıştırınca sayfayı evil.com başlığı altında döndürdü.
Demek ki sistem “host” değerini hiç kontrol etmiyor.

Korunma Yöntemleri

Bu deneyimden sonra araştırdım ve çözüm yollarını buldum:

1. Whitelist Uygulaması – Sadece izin verilen hostları kabul et (örn. targetsite.com).
2. Framework Ayarları – Django’da ALLOWED_HOSTS, Laravel’de trusted proxies ayarlarını yap.
3. Reverse Proxy Doğrulaması – X-Forwarded-Host gibi başlıkları körü körüne kullanma.
4. Güvenlik Testlerinde Host Manipülasyonu – Burp Suite ile mutlaka test et.
   
   Çıkardığım Ders
   
   O gün şunu öğrendim:
   Bazen SQLi veya RCE gibi “büyük” açıklar ararken, en basit HTTP başlığı seni ters köşeye yatırabilir.
   Benim için basit bir testti ama gerçek bir şirkette denk gelsem, kritik sonuçlar doğururdu.
   
   
   

 

[Yeni Kullanıcıyım Ben]

Bir gün evde kendi lab ortamımı kurarken şöyle bir şey fark ettim:
Çoğu kişi XSS, SQLi falan deniyor ama HTTP başlıklarıyla pek oynanmıyor.
Ben de dedim ki, “Acaba şu Host başlığını değiştirsem ne olur?”

​

Lab Ortamı Kurulumu

Kendi bilgisayarımda ufak bir test ortamı kurdum:

# DVWA veya basit bir PHP site için
docker run -d -p 8080:80 vulnerables/web-dvwa

Tarayıcıdan http://localhost:8080 adresine girdim.
Burp Suite’i açıp gelen istekleri izlemeye başladım.

İlk Deneme

Normal login isteği şöyleydi:

GET /login.php HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0

Dedim ki, “Ya bu host değerini değiştirsem?”
Ve değiştirdim:

GET /login.php HTTP/1.1
Host: attacker.com
User-Agent: Mozilla/5.0

Sonuç?

Sayfa yine geldi ama “linkler” ve bazı yönlendirmeler attacker.com üzerinden dönmeye başladı.

Gerçek Gücü Ne Zaman Fark Ettim?

Şifre sıfırlama kısmında e-posta adresimi girdim.
Normalde bana http://localhost:8080/reset?token=1234 gibi link gelmesi gerekirken,
bu kez link şu şekildeydi:

http://attacker.com/reset?token=1234

O an fark ettim:
Bir saldırgan bu açığı kullanarak reset linklerini kendi alanına yönlendirebilir.
Yani kurban “benim siteye güveniyor” sanıp saldırgana tıklar.

Küçük Python Denemem

Bunu görmek için bir de Python ile test ettim:

import requests

url = "http://localhost:8080/login.php"
headers = {
    "Host": "evil.com",
    "User-Agent": "Mozilla/5.0"
}

r = requests.get(url, headers=headers)
print("Durum:", r.status_code)
print("Örnek cevap:", r.text[:200])

Çalıştırınca sayfayı evil.com başlığı altında döndürdü.
Demek ki sistem “host” değerini hiç kontrol etmiyor.

Korunma Yöntemleri

Bu deneyimden sonra araştırdım ve çözüm yollarını buldum:

1. Whitelist Uygulaması – Sadece izin verilen hostları kabul et (örn. targetsite.com).
2. Framework Ayarları – Django’da ALLOWED_HOSTS, Laravel’de trusted proxies ayarlarını yap.
3. Reverse Proxy Doğrulaması – X-Forwarded-Host gibi başlıkları körü körüne kullanma.
4. Güvenlik Testlerinde Host Manipülasyonu – Burp Suite ile mutlaka test et.
   
   Çıkardığım Ders
   
   O gün şunu öğrendim:
   Bazen SQLi veya RCE gibi “büyük” açıklar ararken, en basit HTTP başlığı seni ters köşeye yatırabilir.
   Benim için basit bir testti ama gerçek bir şirkette denk gelsem, kritik sonuçlar doğururdu.
   
   

Çok mantıklı, zamanında benimde aklıam bu tür şeyler gelmişti ama uğraşmaya değmez demiştim, gerçekten güzel bir çalışma olmuş güzel bir açık bulmuşsunuz , bu arada yönlendirme dediğimiz şey sadece sizi etkilemezmi yani sonuçta xss gibi kalıcı değil sadece biz kendimizi yönlendirmiyormuyuz?, ve bu isteği kendi sitemize yönlendirsek bile elimize ne geçecek, bunu sormak istedim.
İyi günler..

 

[ATK]

Bir gün evde kendi lab ortamımı kurarken şöyle bir şey fark ettim:
Çoğu kişi XSS, SQLi falan deniyor ama HTTP başlıklarıyla pek oynanmıyor.
Ben de dedim ki, “Acaba şu Host başlığını değiştirsem ne olur?”

​

Lab Ortamı Kurulumu

Kendi bilgisayarımda ufak bir test ortamı kurdum:

# DVWA veya basit bir PHP site için
docker run -d -p 8080:80 vulnerables/web-dvwa

Tarayıcıdan http://localhost:8080 adresine girdim.
Burp Suite’i açıp gelen istekleri izlemeye başladım.

İlk Deneme

Normal login isteği şöyleydi:

GET /login.php HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0

Dedim ki, “Ya bu host değerini değiştirsem?”
Ve değiştirdim:

GET /login.php HTTP/1.1
Host: attacker.com
User-Agent: Mozilla/5.0

Sonuç?

Sayfa yine geldi ama “linkler” ve bazı yönlendirmeler attacker.com üzerinden dönmeye başladı.

Gerçek Gücü Ne Zaman Fark Ettim?

Şifre sıfırlama kısmında e-posta adresimi girdim.
Normalde bana http://localhost:8080/reset?token=1234 gibi link gelmesi gerekirken,
bu kez link şu şekildeydi:

http://attacker.com/reset?token=1234

O an fark ettim:
Bir saldırgan bu açığı kullanarak reset linklerini kendi alanına yönlendirebilir.
Yani kurban “benim siteye güveniyor” sanıp saldırgana tıklar.

Küçük Python Denemem

Bunu görmek için bir de Python ile test ettim:

import requests

url = "http://localhost:8080/login.php"
headers = {
    "Host": "evil.com",
    "User-Agent": "Mozilla/5.0"
}

r = requests.get(url, headers=headers)
print("Durum:", r.status_code)
print("Örnek cevap:", r.text[:200])

Çalıştırınca sayfayı evil.com başlığı altında döndürdü.
Demek ki sistem “host” değerini hiç kontrol etmiyor.

Korunma Yöntemleri

Bu deneyimden sonra araştırdım ve çözüm yollarını buldum:

1. Whitelist Uygulaması – Sadece izin verilen hostları kabul et (örn. targetsite.com).
2. Framework Ayarları – Django’da ALLOWED_HOSTS, Laravel’de trusted proxies ayarlarını yap.
3. Reverse Proxy Doğrulaması – X-Forwarded-Host gibi başlıkları körü körüne kullanma.
4. Güvenlik Testlerinde Host Manipülasyonu – Burp Suite ile mutlaka test et.
   
   Çıkardığım Ders
   
   O gün şunu öğrendim:
   Bazen SQLi veya RCE gibi “büyük” açıklar ararken, en basit HTTP başlığı seni ters köşeye yatırabilir.
   Benim için basit bir testti ama gerçek bir şirkette denk gelsem, kritik sonuçlar doğururdu.
   
   

Ellerinize Sağlık Yararlı Bir Konu Olmuş

 

[xNewt]

Elinize sağlık, güzel olmuş.

 

[sametghack]

Eline saglik

 

[fazeL]

Merhaba,

Aslında HTTP Host Header Injection veya kısaca Host Header Manipülasyonu denen açığı keşfetmişsin. Bu çok kritik bir bulgu ve anlatımını da adım adım çok güzel açıklamışsın. Ben sana hem teknik olarak nelerin düzeltilmesi gerektiğini hem de bu tür yazıyı daha güçlü hale getirmek için neler ekleyebileceğini söyleyeyim:

Lab ortamını Docker + DVWA ile kurmuşsun bu herkesin tekrar edebileceği bir yöntem. İlk gözlem (login isteğinde Host değişimi) gayet anlaşılır. Şifre sıfırlama örneği kritik bir senaryo, gerçek dünyada en çok kullanılan vektörlerden biri. Python testini eklemen pratikliği artırmış. Çözüm önerilerini sıralaman yazıyı sadece “saldırı” değil, “savunma” odaklı hale getirmiş. Eksik/düzeltilebilir alanlar:

Kod formatı: Bazı yerlerde “Kod:” yazıp bırakmışsın. Onları düzgün code block (```http, ```python) formatında yazarsan okunabilirlik artar. Teknik açıklama (root cause): Sen gözlemini anlatmışsın ama ekleyebilirsin: Host header, HTTP/1.1 standardına göre zorunlu bir başlık. Çoğu framework, redirect, link üretimi veya cache key belirlemede Host’u doğrudan kullanır. Doğrulanmazsa bu tür yönlendirme açıklarına sebep olur. Açığın ne seviyede olduğu (ör. OWASP Top 10 - A5 Security Misconfiguration veya A1 Injection altında değerlendirilebilir) ve gerçek senaryolarda ne sonuç doğuracağı kısmını ekleyebilirsin. Ek olarak;

Cache Poisoning: Eğer reverse proxy/CDN varsa, saldırgan “Host” başlığını değiştirip cache’i zehirleyebilir.
Password Reset Poisoning: Senin yaşadığın senaryo, en kritik etki.
Virtual Host Confusion: Aynı sunucuda birden fazla domain barındırılıyorsa, Host değişimiyle yanlış siteye erişim sağlanabilir.

Çalışma ve konu için teşekkürler iyi forumlar.

 

[Dr Toretto]

Çok mantıklı, zamanında benimde aklıam bu tür şeyler gelmişti ama uğraşmaya değmez demiştim, gerçekten güzel bir çalışma olmuş güzel bir açık bulmuşsunuz , bu arada yönlendirme dediğimiz şey sadece sizi etkilemezmi yani sonuçta xss gibi kalıcı değil sadece biz kendimizi yönlendirmiyormuyuz?, ve bu isteği kendi sitemize yönlendirsek bile elimize ne geçecek, bunu sormak istedim.
İyi günler..

teşekkür ederim yorumun için yönlendirme olayı tek başına xss gibi kalıcı bir etki bırakmıyor evet ama senaryoya göre ciddi sonuçlar doğurabiliyor örneğin kullanıcıyı sahte bir oturum açma sayfasına yönlendirmek veya farklı bir saldırı zincirinin parçası yapmak mümkün burada amaç sadece açığı göstermek değil aynı zamanda olasılıkları da düşünmek bu yüzden uğraşmaya değer

 

[Dr Toretto]

Ellerinize Sağlık Yararlı Bir Konu Olmuş

Teşekkür ederim

Elinize sağlık, güzel olmuş.

Teşekkür ederim sağolun..

Eline saglik

Teşekkür ederim modum.

Merhaba,

Aslında HTTP Host Header Injection veya kısaca Host Header Manipülasyonu denen açığı keşfetmişsin. Bu çok kritik bir bulgu ve anlatımını da adım adım çok güzel açıklamışsın. Ben sana hem teknik olarak nelerin düzeltilmesi gerektiğini hem de bu tür yazıyı daha güçlü hale getirmek için neler ekleyebileceğini söyleyeyim:

Lab ortamını Docker + DVWA ile kurmuşsun bu herkesin tekrar edebileceği bir yöntem. İlk gözlem (login isteğinde Host değişimi) gayet anlaşılır. Şifre sıfırlama örneği kritik bir senaryo, gerçek dünyada en çok kullanılan vektörlerden biri. Python testini eklemen pratikliği artırmış. Çözüm önerilerini sıralaman yazıyı sadece “saldırı” değil, “savunma” odaklı hale getirmiş. Eksik/düzeltilebilir alanlar:

Kod formatı: Bazı yerlerde “Kod:” yazıp bırakmışsın. Onları düzgün code block (```http, ```python) formatında yazarsan okunabilirlik artar. Teknik açıklama (root cause): Sen gözlemini anlatmışsın ama ekleyebilirsin: Host header, HTTP/1.1 standardına göre zorunlu bir başlık. Çoğu framework, redirect, link üretimi veya cache key belirlemede Host’u doğrudan kullanır. Doğrulanmazsa bu tür yönlendirme açıklarına sebep olur. Açığın ne seviyede olduğu (ör. OWASP Top 10 - A5 Security Misconfiguration veya A1 Injection altında değerlendirilebilir) ve gerçek senaryolarda ne sonuç doğuracağı kısmını ekleyebilirsin. Ek olarak;

Cache Poisoning: Eğer reverse proxy/CDN varsa, saldırgan “Host” başlığını değiştirip cache’i zehirleyebilir.
Password Reset Poisoning: Senin yaşadığın senaryo, en kritik etki.
Virtual Host Confusion: Aynı sunucuda birden fazla domain barındırılıyorsa, Host değişimiyle yanlış siteye erişim sağlanabilir.

Çalışma ve konu için teşekkürler iyi forumlar.

merhaba değerli katkın için teşekkürler söylediklerin oldukça yerinde özellikle host header’ın HTTP/1.1 standardındaki zorunluluğu ve birçok framework’ün bunu doğrulamadan kullanmasından kaynaklanan riskleri net şekilde özetlemişsin cache poisoning, virtual host confusion ve password reset poisoning gibi senaryoların da bu bağlamda değerlendirilmesi gerektiğini vurgulaman çok faydalı olmuş ayrıca owasp top 10 (A05: Security Misconfiguration) referansı ile bu açığın kritikliği de daha iyi anlaşılabilir iyi forumlar