Metodoloji

Tarayıcı Çıktısını Triyaj Etmek: Bulgu ≠ Zafiyet

Otomatik bir tarayıcı size zafiyet vermez; hipotez verir. Aradaki mesafeyi kapatan şey triyajdır: doğrulama, bağlam, sömürülebilirlik ve etki. Bu yazı, bir tarama raporunun önüne oturduğumda izlediğim sırayı ve en sık düştüğüm tuzakları anlatıyor.

8 dakika Metodoloji

Kapsam notu

Bu yazıdaki tüm örnekler genelleştirilmiştir. Kendi altyapıma ait hiçbir yapılandırma, sürüm, adres veya topoloji bilgisi paylaşılmamaktadır; amaç metodolojiyi aktarmak, herhangi bir hedefe yol göstermek değil.

Bulgu ile zafiyet arasındaki fark

Tarayıcının ürettiği satır bir gözlemdir: bir imza eşleşti, bir başlık yoktu, bir yanıt beklenenden farklıydı. Zafiyet ise bundan çok daha dar bir şey — belirli bir tehdit aktörünün, belirli bir bağlamda, ölçülebilir bir etki üretecek şekilde kullanabildiği bir durum.

Aradaki boşluk üç sorudan oluşuyor: doğru mu (gözlem gerçek mi), ulaşılabilir mi (saldırgan oraya varabiliyor mu), işe yarıyor mu (vardığında bir şey kazanıyor mu). Üçüne birden "evet" diyemiyorsanız elinizdeki şey bir zafiyet değil, bir not.

Tarayıcı hızlı ve kapsamlıdır, ama bağlamsızdır. Bağlamı ekleyen insandır; triyajın tamamı budur.

Triyaj hattı: altı adım

  1. Yeniden üret. Bulguyu tarayıcı olmadan, elle tekrarla. Ham istek/yanıt çiftini kendi gözünle gör. Tekrar üretilemeyen bulgu tartışılmaz; ilk eleme burada olur.
  2. Bağlamı koy. Etkilenen varlık ne? Üzerinde hangi veri var? Kimin erişimine açık? Kimlik doğrulaması gerekiyor mu? Aynı teknik bulgu, bir statik broşür sitesinde ve bir ödeme panelinde tamamen farklı şeyler ifade eder.
  3. Sömürülebilirliği test et. Yetkili olduğun kapsamda, minimum düzeyde bir kavram kanıtı üret. Amaç zarar vermek değil, "bu gerçekten çalışıyor" cümlesini kanıta bağlamak.
  4. Etkiyi yaz. Gizlilik, bütünlük, erişilebilirlik başlıklarından hangisi ne kadar etkileniyor? Somut yaz: "kimlik doğrulaması olmadan şu veri okunabiliyor" gibi. "Güvenlik riski oluşturur" bir etki cümlesi değildir.
  5. Şiddet ver. CVSS temel skoru ortak bir dil sağlar, ama çevresel/zamansal ölçütler olmadan yarım kalır. Ayrıca şiddet ile öncelik aynı şey değil: düşük şiddetli ama beş dakikada kapatılabilen bir bulgu, üç aylık bir yeniden mimariden önce gelir.
  6. Düzeltmeyi öner ve doğrula. Somut, uygulanabilir bir düzeltme yaz; uygulandıktan sonra aynı adımlarla yeniden test et. Kapanış doğrulaması olmayan triyaj tamamlanmamıştır.

Yanlış pozitifin bir numaralı kaynağı: sürüm eşleşmesi

Tarama raporlarındaki gürültünün büyük kısmı tek bir kalıptan geliyor: tarayıcı bir servisin ilan ettiği sürüm numarasını okuyor, o sürüme ait CVE listesini getiriyor ve hepsini bulgu olarak sıralıyor. Bu, kanıt değil tahmindir.

En yaygın kırılma noktası backport. Kurumsal dağıtımlar paketin sürüm numarasını sabit tutup güvenlik yamasını geriye taşır. Servis hâlâ eski bir sürüm numarası ilan eder, ama açık kapatılmıştır. Tarayıcının gördüğü sürüm ile çalışan kodun gerçeği aynı değildir.

Sürüm bazlı bir bulguyu kapatmadan önce sırayla baktığım şeyler:

  • Dağıtımın güvenlik takibinde ilgili paket için yama var mı, hangi paket sürümünde?
  • Açık, gerçekten kullanılan bir modül/derleme seçeneği içinde mi?
  • Zafiyetli kod yolu bu yapılandırmada erişilebilir mi?
  • Ön koşullar sağlanıyor mu (kimlik doğrulama, belirli bir özellik açık mı)?

Aynı mantık bağımlılık tarayıcıları için de geçerli: bir paketin bağımlılık ağacında yer alması, zafiyetli fonksiyonun çağrıldığı anlamına gelmez. "Erişilebilirlik analizi" yapmayan bir uyarı, düzeltme kuyruğunda yer kaplamaktan başka iş görmez.

Sık görülen bulgu sınıfları

Aşağıdaki tablo, tarama raporlarında en çok karşıma çıkan başlıkları ve triyajda sorduğum belirleyici soruyu özetliyor.

Bulgu Belirleyici soru Tipik sonuç
Sürüm banner'ından türetilen CVE listesi Yama backport edilmiş mi, zafiyetli kod yolu kullanılıyor mu? Çoğunlukla yanlış pozitif
Eksik güvenlik başlığı Sayfada oturum, kimlik veya kullanıcı girdisi var mı; başlık hangi somut saldırıyı engelleyecekti? Genelde bilgi amaçlı
Zayıf TLS yapılandırması Zayıf parametre gerçekten pazarlık edilebiliyor mu, yoksa yalnızca listede mi? Düşük / bilgi
Dizin listeleme açık Listelenen içerikte erişime kapalı olması gereken bir şey var mı? Bağlama göre gerçek
Yansıyan parametre / olası XSS Yansıma hangi bağlamda, çıktı kodlaması ne, gerçekten yürütülüyor mu? Doğrulama şart
Açıkta kalan yönetim veya yedek dosyası İçeriği hassas mı, kimlik doğrulaması var mı? Genelde gerçek

Dikkat edilmesi gereken bir nokta: "bilgi amaçlı" demek "önemsiz" demek değil. Tek başına etkisi olmayan üç bulgu, birbirine zincirlendiğinde gerçek bir saldırı yolu üretebilir. Triyajda bulguları tek tek değil, birlikte okumak gerekiyor.

Tarayıcının göremedikleri

Yanlış pozitif can sıkıcıdır; yanlış negatif tehlikelidir. Otomatik araçların yapısal olarak zayıf olduğu alanlar oldukça öngörülebilir:

  • Yetkilendirme mantığı. Bir nesneye başka bir kullanıcının kimliğiyle erişilip erişilemediğini anlamak için "doğru" cevabın ne olması gerektiğini bilmek gerekir. Tarayıcı bunu bilmez.
  • İş mantığı. Adım atlama, negatif miktar, yarış durumu, fiyat/indirim manipülasyonu — hepsi uygulamanın kurallarını anlamayı gerektirir.
  • Çok adımlı akışlar. Durum taşıyan işlemler, tek istek bazlı taramanın dışında kalır.
  • Zincirleme. Düşük şiddetli bulguların birleşiminden doğan yollar, tanım gereği tek bir imzaya karşılık gelmez.

Pratik sonuç: taramayı bir envanter ve kapsam çıkarma aracı olarak kullanmak, asıl mesaiyi yetkilendirme ve iş mantığına ayırmak.

Gürültüyü baştan azaltmak

  • Temel çizgi (baseline) tut. Her taramanın tamamını değil, önceki taramaya göre farkı incele. Yeni çıkan bulgu, tekrar eden bin satırdan daha bilgilendiricidir.
  • Kapsamı yaz. Hangi varlıklar dahil, hangileri değil. Kapsam dışı bir bulgu, ne kadar doğru olursa olsun, o çalışmanın çıktısı değildir.
  • Kimlikli tarama yap. Kimlik doğrulaması olmadan yapılan tarama uygulamanın yalnızca dış kabuğunu görür.
  • Kararı gerekçesiyle kaydet. Kapatılan her bulgunun yanına neden kapatıldığını yaz. Aksi hâlde aynı bulgu her taramada yeniden tartışılır.

Raporu yazmak: etkisi olmayan bulgu rapor değildir

Bir bug bounty programına ya da bir ekibe gönderilen raporun kabul edilip edilmemesini büyük ölçüde şu belirliyor: karşı taraf, raporu okuyarak sorunu kendi başına yeniden üretebiliyor mu ve etkiyi görebiliyor mu.

  • Tek cümlelik özet: ne, nerede, sonucunda ne oluyor.
  • Numaralı, eksiksiz yeniden üretim adımları; ham istek/yanıt.
  • Etki bölümü: hangi veri, hangi yetkiyle, kim tarafından erişilebiliyor.
  • Ön koşullar ve gerekli kullanıcı etkileşimi, dürüstçe.
  • Önerilen düzeltme.
  • Kapsam ve yetki beyanı; test edilen zaman aralığı.

Reddedilen raporların çoğu yanlış olduğu için değil, etkisi yazılmadığı için reddediliyor. "Eksik başlık" bulgusunu rapor etmek yerine, o eksik başlığın hangi somut saldırıyı mümkün kıldığını gösteren bir kavram kanıtı üretmek, aynı gözlemi rapor edilebilir bir bulguya çevirir.

Özet

Tarayıcı, arama alanını daraltan bir araçtır; karar verici değildir. Bulgu listesini zafiyet listesine çeviren şey, her satırın önüne oturup "doğru mu, ulaşılabilir mi, işe yarıyor mu" sorularını sormaktır.

Bu disiplinin en büyük getirisi, güvenlik ekibinin zamanının nereye gittiğidir: yüz satırlık gürültüyü yönetmek yerine, gerçekten sömürülebilir olan üç satırı kapatmak. Rapor kalitesi de aynı yerden geliyor — kanıt ve etki, iddiadan önce gelir.