June 2, 2026
Lab: Authentication bypass via information disclosure
Merhaba arkadaşlar. Bu yazıda PortSwigger Web Security Academy’deki “Authentication Bypass via Information Disclosure” labını çözeceğiz. Bu…
Songül Kızılay Özügürler
2 min read
Merhaba arkadaşlar. Bu yazıda PortSwigger Web Security Academy'deki "Authentication Bypass via Information Disclosure" labını çözeceğiz. Bu lab, bilgi sızmasının (information disclosure) bazen tek başına bir zafiyet olmasa bile başka saldırılara nasıl kapı açabileceğini gösteren güzel örneklerden biri.
Labın amacı admin paneline erişmek ve ardından carlos kullanıcısını silmek. Bunun için bize normal bir kullanıcı hesabı verilmiş:
- Kullanıcı Adı: wiener
- Şifre: peter
Öncelikle verilen kullanıcı bilgileriyle giriş yaptıktan sonra uygulamayı incelemeye başladım. Böyle durumlarda admin paneli olup olmadığını kontrol etmek için sık kullanılan endpointlerden biri olan /admin dizinine erişmeyi denedim.
İsteği gönderdiğimde aşağıdaki cevabı aldım:
GET /adminGET /adminSunucu ise şu mesajla karşılık verdi:
Admin interface only available to local usersAdmin interface only available to local usersBu mesaj ilk bakışta yalnızca bir hata gibi görünse de aslında önemli bir bilgi sızmasına işaret ediyor.
Burada uygulama bize admin paneline erişim mantığı hakkında bilgi veriyor. Normalde saldırganın bilmemesi gereken bir detay öğrenmiş oluyoruz:
Admin paneli yalnızca local kullanıcılar tarafından erişilebiliyor.
Bu noktada aklımda şu soru oluştu:
"Peki uygulama bir isteğin local kullanıcıdan gelip gelmediğini nasıl anlıyor?"
Bu sorunun cevabını bulursak erişim kontrolünü atlatabiliriz.
Admin panelinin nasıl korunduğunu anlamak için farklı HTTP metodlarını denemeye karar verdim.
Bu noktada TRACE metodu oldukça faydalı olabiliyor.
TRACE metodunun amacı sunucunun aldığı isteği bize geri döndürmesidir. Böylece istemci ile sunucu arasında hangi header'ların eklendiğini veya değiştirildiğini görebiliriz.
Bu nedenle aşağıdaki isteği gönderdim:
TRACE /adminTRACE /admin
Sunucudan dönen cevap içerisinde dikkatimi çeken bir satır oldu:
X-Custom-IP-Authorization: 94.54.48.90X-Custom-IP-Authorization: 94.54.48.90Burada uygulamanın veya ön taraftaki proxy'nin istemci IP adresini özel bir HTTP header içerisine eklediğini görüyoruz.
Daha önce /admin endpointinde aldığımız mesajı hatırlarsak:
Admin interface only available to local usersAdmin interface only available to local usersArtık iki bilgiyi birleştirebiliyoruz.
- Uygulama local kullanıcıları kontrol ediyor.
- Uygulama IP bilgisini X-Custom-IP-Authorization header'ından alıyor.
Bu durumda uygulamanın muhtemelen şu mantıkla çalıştığını düşünebiliriz:
if X-Custom-IP-Authorization == "127.0.0.1":
allow_access()if X-Custom-IP-Authorization == "127.0.0.1":
allow_access()Eğer gerçekten durum buysa uygulama IP doğrulamasını güvenilmeyen bir HTTP header üzerinden yapıyor demektir.
Ve kullanıcı tarafından gönderilebilen her header manipüle edilebilir.
Bu hipotezi test etmek için Repeater üzerinde isteği yeniden gönderdim ancak bu kez IP adresini localhost olarak değiştirdim:
GET /admin
X-Custom-IP-Authorization: 127.0.0.1GET /admin
X-Custom-IP-Authorization: 127.0.0.1Buradaki amaç uygulamayı isteğin localhost üzerinden geldiğine inandırmaktı.
İsteği gönderdikten sonra beklediğim sonuç gerçekleşti ve admin paneline erişim sağlayabildim.
Bu durum uygulamanın istemci tarafından kontrol edilebilen bir header'a güvenmesinden kaynaklanıyordu.
Carlos Kullanıcısını Silmek
Admin paneline eriştikten sonra yapılması gereken son işlem carlos kullanıcısını silmekti.
Panel içerisinde bulunan silme fonksiyonunu kullanarak ilgili isteği gönderdim ve kullanıcıyı kaldırdım.
Bunun ardından lab başarıyla tamamlandı.
Sonuç
Bu lab bize bilgi sızmasının neden önemli olduğunu gösteriyor.
Başlangıçta elde ettiğimiz:
Admin interface only available to local usersAdmin interface only available to local usersmesajı tek başına kritik görünmeyebilir. Ancak bu bilgi sayesinde hangi güvenlik mekanizmasının kullanıldığını öğrendik.
Daha sonra TRACE metodunu kullanarak uygulamanın IP doğrulaması için kullandığı özel header'ı keşfettik.
Son olarak bu header'ı manipüle ederek uygulamayı isteğin localhost üzerinden geldiğine ikna ettik ve admin paneline eriştik.
Özetle saldırı zinciri şu şekilde ilerledi:
Information Disclosure → TRACE Method → Header Discovery → IP Spoofing → Authentication Bypass → Admin Access
Bu nedenle hata mesajlarında verilen küçük detaylar bile saldırgan açısından oldukça değerli bilgiler sağlayabilir.