Bu yazı serisinin amacı, web uygulamalarında sıkça karşılaşılan güvenlik zafiyetlerini hem saldırgan (Red Team) hem de savunmacı (Blue Team) bakış açısıyla ele almaktır. Her bir zafiyet, teknik detaylardan uzaklaşmadan ama anlaşılır bir dille açıklanacak; ardından örneklerle nasıl istismar edildiği ve nasıl tespit edilip önlenebileceği gösterilecektir.

Bu kapsamda 6. konumuz, Information Disclosure Vulnerabilities (Bilgi Sızıntısı Zafiyetleri) olacaktır.

Bu içerik yalnızca eğitim amaçlıdır. İzinsiz erişim, yetkisiz müdahale veya zararlı kullanım yasal yaptırımlar doğurabilir. İçeriğin kötüye kullanımı sonucu doğabilecek hukuki veya maddi sonuçlardan siz sorumlusunuzdur.

None

İnternette gezinirken farkında olmadan bazı şeyler öğreniyor olabilirsiniz. Mesela bir web sitesinde çıkan detaylı bir hata mesajı, arka planda kullanılan veritabanı sistemini size söyleyebilir. Ya da kaynak kodda bırakılan küçük bir yorum satırı, sitenin gizli bir paneline işaret ediyor olabilir.

İşte bu tür durumlar, Information Disclosure Vulnerabilities (Bilgi Sızıntısı Zafiyetleri) olarak adlandırılır.

Bilgi Sızıntısı Nedir?

Basitçe söylemek gerekirse, bir bilgi sızıntısı zafiyeti, bir uygulamanın veya sistemin, normalde erişilememesi gereken hassas bilgileri (örneğin; hata mesajları, dosya yolları, veritabanı şemaları veya sunucu versiyonları) kötü niyetli kişilere veya hatta sıradan kullanıcılara ifşa etmesi durumudur. Bu zafiyet tek başına bir saldırı aracı olmasa da, bir saldırganın sisteminize sızmak için ihtiyaç duyduğu yol haritasını sunar.

Basit örnek:

Bir web sitesine aşağıdaki gibi bir istek gönderildiğini düşünün:

https://sirket.com/login?user=admin&pass=12345

Ve sistem şöyle cevap veriyor:

Veritabanı bağlantı hatası: Kullanıcı adı 'admin' bulundu ama şifre hatalı. SQLSTATE[28000]

İşte bu mesaj, saldırgana şu bilgileri veriyor:

  • admin adında bir kullanıcı gerçekten var.
  • Sistem SQL veritabanı kullanıyor.
  • Veritabanı bağlantısı açık ve erişilebilir.

Sistem, istemeden ama düşmanına altın gibi bilgiler veriyor.

Gerçek Hayattan 5 Örnek

Örnek 1: robots.txt ile Gizli Dizinlerin Ortaya Çıkması

Bir üniversitenin web sitesinde aşağıdaki gibi bir robots.txt dosyası yer alıyor:

User-agent: *
Disallow: /admin_panel/
Disallow: /ogrenci_bilgileri/
Disallow: /pdf_yedekleri/

Saldırgan siteye doğrudan şu yollarla erişmeyi dener:

Ve ne bulur? ogrenci_bilgileri klasöründe herkesin erişimine açık bir PDF dosyası: notlar.xlsx, içinde öğrenci numaraları, isimleri, ve e-posta adresleri mevcut.

Güvenlikçi Ne Yapmalıydı?

  • robots.txt, yalnızca SEO içindir. Güvenlik mekanizması olarak asla kullanılmamalı.
  • Gerçekten gizli dizinler, yetkilendirme kontrolüyle korunmalıydı.
  • Ayrıca, yedek veya geçici dosyalar asla üretim ortamında yer almamalıydı.

Örnek 2: Kaynak Kodda Bırakılan Yorum Satırı

Bir online alışveriş sitesinde, bir ürün sayfasının HTML kaynağında şu yorum yer alıyor:

<!-- /test_api/payment-debug?admin=true&bypass_auth=true -->

Bu satır, kullanıcı tarafından görünmüyor, ama kaynak kodda duruyor. Saldırgan, sayfayı sağ tıklayıp "Sayfa kaynağını görüntüle" diyor ve bu URL'yi fark ediyor.

Saldırgan Ne Dener?

Güvenlikçi Ne Yapmalıydı?

  • Yorum satırları, üretim koddan otomatik olarak temizlenmeliydi.
  • Debug endpoint'ler yalnızca lokal ya da staging ortamda açık olmalıydı.
  • Bu API erişimleri mutlaka yetkilendirme ve IP sınırlamasıyla korunmalıydı.

Örnek 3: Hata Mesajı ile Sızan Veritabanı Bilgisi

Bir kullanıcı giriş yaparken yanlışlıkla ' OR 1=1 -- gibi bir SQL injection denemesi yapıyor. Sunucu şu hatayı döndürüyor:

SQLSTATE[42000]: Syntax error or access violation: 1064
You have an error in your SQL syntax near '1=1 --'' at line 1
in /var/www/html/app/login.php on line 27

Saldırgan Bu Mesajdan Ne Öğrendi?

  • Sistem SQL veritabanı kullanıyor.
  • Hangi PHP dosyası çalıştı: login.php
  • Hangi satırda hata oluştu: satır 27
  • SQL injection denemesi başarıya oldukça yakın

Güvenlikçi Ne Yapmalıydı?

  • display_errors PHP ayarı kapatılmalıydı.
  • Uygulama genel hata mesajları göstermeliydi: "Bir hata oluştu, lütfen tekrar deneyin."
  • Geliştirici hatayı log'a yazmalı, kullanıcıya değil.

Örnek 4: Ortada Bırakılan .git Klasörü

Bir startup şirketi, bir blog platformu geliştiriyor. Projeyi sunucuya yüklerken .git klasörünü de yanlışlıkla bırakıyor.

Saldırgan https://startup.com/.git/ dizinine girdiğinde içerik listelenmiyor. Ama wget --mirror gibi bir araçla tüm .git klasörünü çekebiliyor.

Saldırgan Ne Yapabilir?

  • git log komutu ile geçmiş commit mesajlarını okur:
fix: admin bypass bug
added test credentials
remove hardcoded tokens
  • .git/config dosyasından Github remote adresini görür (sızan repo linki).
  • git show ile eski kodları analiz eder, debug kodlarını veya şifreleri açığa çıkarabilir.

Güvenlikçi Ne Yapmalıydı?

  • .git klasörü yayına çıkmadan silinmeliydi.
  • .htaccess ile erişim engellenebilirdi:
RedirectMatch 404 /\.git

CI/CD sürecinde yalnızca gerekli dosyaların deploy edildiğinden emin olunmalıydı.

Örnek 5: JavaScript İçinde Unutulan API Anahtarı

Bir geliştirici, Stripe API'siyle ödeme sistemi kurarken test için API anahtarını frontend dosyası olan checkout.js içine yazıyor:

const stripeKey = "sk_test_51HbSAx...";

Dosya sonradan yayına alınırken bu satır unutuluyor.

Saldırgan Ne Yapabilir?

  • Tarayıcının geliştirici araçlarında checkout.js dosyasını bulur.
  • Stripe API anahtarını kendi sitesine entegre eder.
  • Şirketin ödeme limitlerini kullanarak test işlemleri yapar.

Stripe gibi bazı servisler, bu tür anahtar sızıntılarında otomatik uyarı verir. Ama yine de iş işten geçmiş olur.

Güvenlikçi Ne Yapmalıydı?

  • API anahtarları kesinlikle client-side'da bulunmamalı.
  • Sunucu taraflı endpoint kullanılarak bu işlemler yönlendirilmeliydi.
  • Ortam değişkenleri (.env) ile anahtarlar kontrol altında tutulmalıydı.

Okuduğunuz için teşekkür ederim 🙏 Umarım bu yazı, Information Disclosure Vulnerabilities'ı hem saldırı (Red Team) hem de savunma (Blue Team) açısından daha iyi anlamanıza yardımcı olmuştur.

Bu konu teorik olarak anlaşılabilir ama asıl beceri pratik yaparak kazanılır. Özellikle PortSwigger Web Security Academy üzerinde bulunan Information Disclosure Vulnerabilities lablarını çözerek hem temel hem de ileri seviye saldırı tekniklerini güvenli bir ortamda deneyimleyebilirsiniz.