Prioritizing Attack Hypotheses

1. Hipotezden Test Senaryosuna: Keskin Formülasyon

Önceki derste ürettiğimiz hipotezler, örneğin "Sunucu tarafında fiyat doğrulaması eksik olabilir," bir başlangıç noktasıdır. Ancak etkin bir test planı için daha fazlasına ihtiyacımız var. İyi formüle edilmiş bir saldırı hipotezi, bir bilimsel hipotez gibi, spesifik, test edilebilir ve yanlışlanabilir olmalıdır.

İyi bir hipotez şu bileşenleri içermelidir:

• Ne? (The What): Elde etmeyi beklediğiniz sonuç. (Örn: "Başka bir kullanıcının finansal notlarını değiştirmek.")
• Nerede? (The Where): Saldırının hedefi olan spesifik bileşen, endpoint veya parametre. (Örn: "POST /api/notes/edit endpoint'indeki noteId parametresi.")
• Neden? (The Why): Zafiyetin var olmasının altında yatan potansiyel temel neden veya zayıflık. (Örn: "Sunucu tarafı yetkilendirme kontrolünün eksik olması.")

Örneğin:

"Ben, POST /api/notes/edit endpoint'indeki (Nerede) noteId parametresini değiştirerek başka bir kullanıcıya ait bir finansal notu düzenleyebileceğimi (Ne) varsayıyorum, çünkü sunucu tarafı sahiplik kontrolünün bu özel API çağrısı için tutarlı bir şekilde uygulanmadığını (Neden) düşünüyorum."

Bu yapı, size sadece neyi test edeceğinizi değil, aynı zamanda hangi güvenlik kontrolünün başarısız olmasını beklediğinizi de söyler.

2. Önceliklendirme Çerçevesi: Etki, İstismar Edilebilirlik ve DREAD

Elimizde iyi formüle edilmiş bir dizi hipotez olduğunda, hangisine önce odaklanacağımıza karar vermeliyiz. Bu karar verme süreci genellikle iki ana eksen etrafında döner: Etki (Impact) ve İstismar Edilebilirlik (Exploitability). Bu, siber güvenlikteki klasik Risk = Etki x Olasılık formülünün hata avcılığına uyarlanmış halidir.

Bu süreci daha yapısal hale getirmek için kullanılan formal metodolojilerden biri DREAD'dir. DREAD, her tehdidi beş kategoriye göre (genellikle 1-10 arası) puanlayan bir modeldir:

• Damage Potential (Hasar Potansiyeli): Bu zafiyet istismar edilirse ne kadar kötü olur?
• Reproducibility (Tekrarlanabilirlik): Bu saldırıyı her denemede güvenilir bir şekilde tekrarlamak ne kadar kolay?
• Exploitability (İstismar Edilebilirlik): Bu zafiyeti istismar etmek için ne kadar yetenek ve kaynak gerekir?
• Affected Users (Etkilenen Kullanıcılar): Kaç kullanıcı bu durumdan etkilenir?
• Discoverability (Keşfedilebilirlik): Bu zafiyeti bulmak ne kadar kolay?

DREAD, sübjektif olabilse de, hipotezleri karşılaştırmak ve bir öncelik sıralaması oluşturmak için mükemmel bir zihinsel çerçeve sunar.

Şimdi Etki ve İstismar Edilebilirlik kavramlarını daha derinlemesine inceleyelim.

3. Etkiyi (Impact) Değerlendirme

Etki, bir zafiyetin iş ve kullanıcılar üzerindeki potansiyel sonucudur. Bunu değerlendirirken kendinize sormanız gereken sorular şunlardır:

• Veri Hassasiyeti ve Niteliği: Erişilen veya değiştirilen veri ne kadar değerli? Kişisel Tanımlayıcı Bilgiler (PII), finansal veriler, sağlık kayıtları veya ticari sırlar mı? Jason Haddix'in de belirttiği gibi, her uygulamanın kendine özgü bir tehdit modeli ve değerli verisi vardır. Örneğin Twitch için bu, bir stream key olabilir.
• İşlevsellik Kapsamı: Saldırı, uygulamanın hangi işlevini etkiliyor? Anahtar bir iş akışını (örn. ödeme) mı kırıyor, yoksa daha az kullanılan bir özelliği mi?
• Etki Alanı: Zafiyet kaç kişiyi etkiliyor? Sadece tek bir kullanıcıyı mı (self-XSS gibi), bir şirketin tüm kullanıcılarını mı (tenant-level IDOR), yoksa platformdaki tüm kullanıcıları mı (cross-tenant IDOR)? rs0n_live videosundaki Finnote örneğinde, şirket içi bir IDOR ile şirketler arası bir IDOR arasındaki etki farkı çok büyüktür.
• Ayrıcalık Yükseltme Potansiyeli: Bu zafiyet, düşük ayrıcalıklı bir kullanıcıyı yönetici (admin) seviyesine taşıyabilir mi?
• Zincirleme Potansiyeli: Kendi başına düşük etkili görünen bu zafiyet (örn. bir açık yönlendirme - open redirect), başka bir zafiyetle birleştirilerek kritik bir sonuca yol açabilir mi?

4. İstismar Edilebilirliği (Exploitability) Değerlendirme

İstismar edilebilirlik, bir hipotezi başarılı bir PoC'ye (Proof of Concept) dönüştürmenin ne kadar pratik ve gerçekçi olduğudur.

• Teknik Zorluk: Saldırı, basit bir parametre değişikliği mi, yoksa milisaniye hassasiyetinde zamanlama gerektiren karmaşık bir race condition mı?
• Ön Koşullar: Saldırının başarılı olması için başka bir şeye ihtiyaç var mı? Örneğin, bir kullanıcının tuzağa düşürülmesi (XSS, CSRF), başka bir zafiyetten sızdırılmış bir bilgi veya sistemin belirli bir durumda olması gerekiyor mu?
• Karşı Tedbirler: Atlatılması gereken güvenlik önlemleri var mı? Web Application Firewall (WAF), Content Security Policy (CSP), rate limiting, CSRF token'ları gibi. rs0n_live videosunda, zincirleme saldırı hipotezini formüle ederken CORS ve CSRF token mekanizmalarının nasıl birer engel teşkil edebileceğini analiz eder.
• Keşfedilebilirlik ve Yüzey Alanı: Zafiyetli endpoint veya parametre ne kadar belirgin? Jason Haddix'in "heat mapping" ve "parameter analysis" kavramları burada devreye girer.

5. Sentez ve Eylem Planı: "Av" Listesini Oluşturma

Artık etki ve istismar edilebilirlik analizini kullanarak hipotezlerinizi sıralayabilirsiniz. Zihninizde basit bir dörtlü matris canlandırabilirsiniz:

1. Yüksek Etki, Yüksek İstismar Edilebilirlik: Önce Test Et! Bunlar, programların en çok değer verdiği "kritik" zafiyetlerdir. rs0n_live videosundaki IDOR hipotezi bu kategoriye girer.
2. Yüksek Etki, Düşük İstismar Edilebilirlik: Zaman Ayır ve Derinleş. Bunlar, bulunması zor ama bulunduğunda büyük ödül getirebilecek zafiyetlerdir (örn. karmaşık bir race condition, sandbox escape). Bu hipotezleri boş zamanlarınızda veya diğerleri sonuç vermediğinde ele alabilirsiniz.
3. Düşük Etki, Yüksek İstismar Edilebilirlik: Hızlı Kazanımlar ve Zincirleme Malzemesi. Bunlar genellikle P4/P5 seviyesinde, raporlaması kolay ama tek başına değeri düşük zafiyetlerdir (örn. bilgi sızıntısı, açık yönlendirme). Bunları hızlıca test edip, daha sonra daha büyük bir saldırı zincirinin parçası olarak kullanıp kullanamayacağınızı değerlendirin.
4. Düşük Etki, Düşük İstismar Edilebilirlik: Şimdilik Göz Ardı Et. Zamanınız kısıtlıysa, bu kategoriye giren hipotezleri listenizin en sonuna bırakın.

GraphQL üzerine yapılan bir çalışmanın sonuçlarını inceleyerek bu sıralama mantığını pekiştirelim.

Sonuç ve Sonraki Adımlar

Bu dersle birlikte, STRIDE tehdit modellemesi modülümüzün sonuna geldik. Artık bir uygulamanın mimarisini analiz etmekten, odaklanmış bir tehdit modeli oluşturmaya ve bu modelden türetilen saldırı hipotezlerini stratejik bir şekilde sıralayarak bir test planı oluşturmaya kadar tüm sürece hakimsiniz. Bu sistematik yaklaşım, sezgisel avlanmanın ötesine geçerek, çabalarınızı en yüksek potansiyelli hedeflere yönlendirmenizi sağlar.

Temel Çıkarımlar:

• Formülasyon Anahtardır: Bir saldırı hipotezini "Ne, Nerede, Neden" formatında formüle etmek, test sürecinizi netleştirir ve hedefe yönelik hale getirir.
• Stratejik Sıralama: Hipotezleri Etki ve İstismar Edilebilirlik eksenlerinde değerlendirmek, zamanınızı en verimli şekilde kullanmanızı sağlar. DREAD gibi modeller bu süreci yapılandırmanıza yardımcı olur.
• Etki Çok Boyutludur: Etki sadece veri sızıntısı değildir; iş sürekliliği, etki alanı ve zincirleme potansiyeli gibi faktörleri de içerir.
• İstismar Edilebilirlik Gerçekçiliktir: Teknik zorluk, ön koşullar ve karşı tedbirler, bir hipotezin ne kadar gerçekçi olduğunu belirler.

İlk modülü başarıyla tamamladınız. Artık bir hedefi nasıl analiz edip, nereden saldıracağınıza dair metodolojik bir plan oluşturma yeteneğine sahipsiniz.

Bir sonraki modülümüz olan "Advanced Reconnaissance & Asset Discovery" ile, bu planı besleyecek ham maddeyi toplamaya odaklanacağız. İlk dersimizde, çoğu avcının gözden kaçırdığı gizli API endpoint'lerini, yolları ve sırları ortaya çıkarmak için karmaşıklaştırılmış (obfuscated) JavaScript kodlarını ve kaynak haritalarını (source maps) nasıl tersine mühendislikle analiz edeceğimizi öğreneceğiz. Bu, tehdit modelinize ekleyeceğiniz yeni saldırı yüzeyleri keşfetmenizi sağlayacak.