Retestte Endpoint Değil Kök Neden Doğrulamak için Regresyon Matrisi
Retest raporda "kapandı" yazmak için değil, riskin gerçekten kapandığını kanıtlamak içindir. Bir düzeltme çoğu zaman raporlanan tek endpoint'i kapatır; ama aynı kök neden başka bir uçtan, başka bir rolle veya zincirin ikinci adımından hâlâ çalışıyor olabilir. Bu yazıda retesti endpoint bazlı değil kök-neden bazlı yürüten bir regresyon matrisi kuruyoruz.
SECNODEX Güvenlik Ekibi
Ofansif Güvenlik
Bir pentest raporundaki en yanıltıcı satır bazen "Kritik bulgu bulunamadı" değildir. "Düzeltildi — kapandı" satırıdır.
Çünkü çoğu düzeltme, raporda gösterilen tek örneği kapatır. Aynı kök neden ise başka bir endpoint'ten, başka bir rolle veya bir saldırı zincirinin ikinci adımından çalışmaya devam edebilir. Endpoint bazlı retest, bu durumda yanlış bir güven duygusu üretir.
İlke
Retest bir endpoint'i değil, bir kök nedeni doğrular. Doğru soru "bu URL artık güvenli mi?" değil, "bu düzeltme, aynı zayıflığın ortaya çıkabileceği tüm yüzeyleri kapatıyor mu?" sorusudur.
Bu yazıda retesti kök-neden odaklı yürüten bir regresyon matrisi kuruyor ve "fix verified" kanıtının minimum içeriğini tanımlıyoruz.
1. Neden endpoint bazlı retest yetersiz?
Tipik bir örnek: nesne düzeyinde yetki eksikliği (BOLA) tek bir uçta raporlanır. Geliştirici o uca bir sahiplik kontrolü ekler ve retest "kapandı" der. Oysa aynı kök neden — "istemciden gelen nesne kimliğine güvenme" — sistemin onlarca ucunda tekrarlanıyor olabilir.
- Aynı zafiyet farklı endpoint'te (aynı hata deseni, farklı URL).
- Aynı endpoint farklı rol/tenant için (kontrol yalnız bir role uygulanmış).
- Aynı endpoint farklı HTTP method / API sürümü için (yetki regresyonu).
- Zincirin ikinci adımı hâlâ mümkün (ilk halka kapandı, ama saldırı yolu alternatif kenardan devam ediyor).
2. Regresyon matrisi
Matris, kök nedeni yatay eksene, etkilenebilecek tüm yüzeyleri dikey eksene alır. Her hücre, o yüzeyin retest sonucudur.
| Yüzey | Aynı endpoint | Diğer endpoint (aynı desen) | Diğer rol/tenant | Diğer method/sürüm | Zincir 2. adım |
|---|---|---|---|---|---|
| Kök neden: nesne yetkisi istemciye güveniyor | Kapandı | 2 uçta açık | support rolünde açık | v1 API'de açık | Kapandı |
Bu tek satırlık örnek bile gösteriyor: raporlanan uç kapanmış olsa da kök neden üç ayrı yüzeyde yaşamaya devam ediyor. Endpoint bazlı retest bunu "kapandı" diye kaydederdi.
3. Matrisi kurma adımları
- 1Kök nedeni adlandır. "Rate limit yok" değil; "sayaç kullanıcı kimliğine bağlı, oturum yenilemeyle sıfırlanabiliyor" gibi mekanizma düzeyinde.
- 2Aynı deseni tara. Kod ve trafik üzerinden aynı hatalı desenin geçtiği tüm uçları çıkar (grep düzeyinde değil, davranış düzeyinde).
- 3Rol/tenant/method boyutlarını ekle. Her yüzeyi tüm kimlik ve sürüm bağlamlarında dene.
- 4Zinciri yeniden çalıştır. Düzeltme zincirin bir halkasını kapattıysa, alternatif kenarlardan yolun hâlâ tamamlanıp tamamlanmadığını doğrula.
- 5Sonucu hücre hücre kaydet. "Kapandı / Açık / Uygulanamaz" — her biri kanıtla.
4. "Fix verified" kanıtının minimum içeriği
Bir düzeltmenin doğrulandığını söylemek için hücre başına şunlar gerekir:
- Düzeltme öncesi çalışan isteğin birebir tekrarı ve artık başarısız olduğunun kanıtı (durum kodu/yanıt farkı).
- Aynı kök nedenin diğer yüzeylerde denendiğinin kaydı (matris hücreleri).
- Düzeltmenin doğru katmanda olduğunun teyidi — istemci tarafı gizleme değil, sunucu tarafı yetki.
- Regresyon riski: düzeltmenin meşru akışı bozmadığının kısa kontrolü.
İpucu
İyi bir retest, "kapandı" ibaresini değil, kapanışın kanıtını ve hangi yüzeylerin hâlâ açık olduğunu net gösterir. Bu, müşteri güvenlik incelemelerinde en çok işe yarayan bölümdür.
5. Retest kapsamı nasıl fiyatlanır?
Kök-neden odaklı retest, "aynı URL'yi bir kez daha dene"den daha geniştir ama sınırsız değildir. Kapsam, matrisin boyutuyla (etkilenen yüzey sayısı × bağlam) tanımlanır ve teklifte açıkça belirtilir. Bu şeffaflık, "retest dahil" ifadesinin gerçekte neyi kapsadığını netleştirir.
Özet
Retest, endpoint doğrulama değil kök-neden doğrulamadır. Regresyon matrisi; aynı zayıflığın farklı endpoint, rol, tenant, method ve zincir adımlarında tekrar edip etmediğini görünür kılar. Böylece "düzeltildi" ifadesi, ölçülebilir bir güvence hâline gelir.
Düzeltme sonrası doğrulamanın bu derinlikte yürütüldüğü bir çalışma için kapsam görüşmesiyle başlayabiliriz.
Sık sorulan sorular
Retest her zaman gerekli mi?
Kritik ve yüksek bulgular için evet. Düzeltmenin gerçekten çalıştığı ve aynı kök nedenin başka yüzeylerde açık kalmadığı ancak yeniden testle kanıtlanır; aksi hâlde rapor "kapandı" der ama risk sürebilir.
Regresyon matrisi retesti pahalılaştırır mı?
Kapsamı büyütür ama körlemesine değil. Matris, hangi ek yüzeylerin test edileceğini önceden ve şeffaf biçimde tanımladığı için "retest dahil" ifadesinin kapsamı da netleşir.
İç ekip kendi retestini yapabilir mi?
Kısmen. İç ekip düzeltilen ucu doğrulayabilir; ancak aynı kök nedenin diğer yüzeylerde ve zincir adımlarında yeniden ortaya çıkıp çıkmadığını bağımsız bir bakış daha güvenilir doğrular.
Okumaya devam et
Sızma Testi
Retest Ne Zaman Yapılmalı, Ne Zaman Beklemeli?
Retest, geliştirici ticket'ı kapattığında değil, düzeltme test edilebilir ortama eksiksiz taşındığında yapılmalıdır. Doğru zamanlama finding bazlı readiness, risk ve deployment kanıtıyla belirlenir.
Yazıyı okuSızma Testi
Pentest Kapsamını URL Listesinden Attack-Surface Graph'a Dönüştürme
Çoğu sızma testi, açık bir zafiyet yüzünden değil, yanlış kapsam yüzünden değer kaybeder. Verilen URL listesini fiyatlandırmak kolaydır; ama bir saldırganın gerçekte kullandığı yol, roller, kiracılar, entegrasyonlar ve güven sınırlarından geçer. Bu yazıda kapsamı düz bir listeden saldırı-yüzeyi grafına nasıl çevirdiğimizi ve bunun neden daha fazla kritik bulgu ürettiğini anlatıyoruz.
Yazıyı oku