Threat Modeling with DFDs and Trust Boundaries

1. Sistemden Özelliğe: Odaklanmanın Gücü

Şimdiye kadar ele aldığımız Veri Akış Diyagramları (Data Flow Diagrams - DFD), genellikle tüm sistemin kuş bakışı bir görünümünü sunar. Bu tür diyagramlar, bir sistemin genel güvenlik duruşunu anlamak için mimarlar ve DevSecOps yöneticileri için paha biçilmezdir.

Ancak bir hata avcısı için bu kadar geniş bir harita, başlangıçta bunaltıcı olabilir. Verimlilik, odağı daraltmaktan geçer. Bir uygulamayı bir şehir olarak düşünürsek, sistem geneli DFD şehrin tüm ana yollarını gösteren bir haritadır. Bizim amacımız ise, şehrin en değerli bölgesi olan "finans merkezi" veya "askeri üs" gibi bir yerin detaylı sokak haritasını çıkarmaktır. Bu, "yeni kullanıcı davet etme", "rapor oluşturma" veya bizim birazdan inceleyeceğimiz gibi "ödeme yapma" gibi tek bir özelliktir.

Bu odaklanmış yaklaşım, zihinsel yükü azaltır ve STRIDE analizini çok daha yönetilebilir ve derinlemesine hale getirir.

2. Vaka Çalışması: Bir Özelliği Parçalarına Ayırmak

Bu dersin geri kalanında, odaklanmış bir tehdit modeli oluşturma sürecini somut bir örnek üzerinden adım adım işleyeceğiz. Önceki dersteki kaynaklarda da bahsedilen, modern uygulamalarda sıkça rastlanan bir senaryoyu ele alalım: bir e-ticaret sitesinin ödeme akışı.

Bu özelliği modellemek için ilk adım, onu temel bileşenlerine ve veri akışlarına ayırmaktır.

Videodaki örnekten ilham alarak, "ödeme akışı" özelliğimizin odaklanmış DFD'sini zihnimizde canlandıralım:

• Dış Varlıklar (External Entities):
  • Kullanıcı / Tarayıcı: Ödeme işlemini başlatan kişi.
• Süreçler (Processes):
  • Front-end (React): Kullanıcının ödeme bilgilerini girdiği arayüz.
  • Back-end (Node.js): İş mantığını yürüten, siparişi oluşturan ve ödemeyi tetikleyen sunucu.
  • Ödeme Ağ Geçidi (Stripe): Kredi kartı işlemini gerçekleştiren harici servis.
• Veri Depoları (Data Stores):
  • Veritabanı (MySQL): Kullanıcı ve sipariş bilgilerini saklayan depo.
• Veri Akışları (Data Flows):
  • Ödeme Bilgisi Gönderimi: Kullanıcıdan Front-end'e, oradan da Back-end'e giden kredi kartı bilgileri ve sipariş detayları.
  • Sipariş Kaydı: Back-end'den Veritabanı'na yazılan sipariş verisi.
  • Ödeme İsteği: Back-end'den Ödeme Ağ Geçidi'ne giden işlem tutarı ve token.
  • Ödeme Yanıtı: Ödeme Ağ Geçidi'nden Back-end'e dönen başarı/hata durumu.

Bu ayrıştırma işlemi tamamlandıktan sonra, en kritik adımlardan biri güven sınırlarını (trust boundaries) çizmektir. Güven sınırları, güven seviyesinin değiştiği mantıksal çizgilerdir ve zafiyetlerin en sık bulunduğu yerlerdir.

Bizim "ödeme akışı" örneğimiz için güven sınırları şunlar olabilir:

1. İnternet Sınırı: Kullanıcının tarayıcısı (güvenilmeyen) ile Front-end/Back-end (kısmen güvenilen) arası.
2. Uygulama Sınırı: Back-end (güvenilen) ile Veritabanı (güvenilen) arası.
3. Harici Servis Sınırı: Back-end (güvenilen) ile Ödeme Ağ Geçidi (harici/kısmen güvenilen) arası.

Bu yapı, artık STRIDE analizi için hazırdır.

3. Tehdit Modelini Sentezleme: STRIDE Uygulaması

Artık elimizde odaklanmış bir DFD ve belirlenmiş güven sınırları olduğuna göre, her bir bileşen ve veri akışı için "What can go wrong?" sorusunu sorabiliriz. Bunu yapmak için sistematik bir şekilde STRIDE'ı kullanacağız.

Aşağıdaki kaynak, bu sürecin bir vaka çalışması üzerinden nasıl dokümante edildiğini mükemmel bir şekilde göstermektedir. Bir tehdit modelinin çıktısının neye benzediğini anlamak için bu kaynağı incelemenizi tavsiye ederim.

Şimdi bu yaklaşımı kendi "ödeme akışı" vaka çalışmamıza uygulayalım. Aşağıda, DFD'mizin bazı kritik noktaları için kısaltılmış bir STRIDE analizi bulunmaktadır:

Analiz: Veri Akışı (Kullanıcı -> Back-end)

• Spoofing:
  • Tehdit: Saldırgan, başka bir kullanıcının oturumunu çalarak onun adına ödeme yapabilir.
  • Soru: Oturum yönetimi ne kadar güvenli? CSRF koruması var mı?
• Tampering:
  • Tehdit: Saldırgan, HTTP isteğini araya girerek (intercept) ürün fiyatını veya miktarını değiştirebilir.
  • Soru: Sunucu tarafında fiyat ve miktar doğrulaması yapılıyor mu, yoksa istemciden gelen değere mi güveniliyor?
• Information Disclosure:
  • Tehdit: Geçersiz bir ödeme denemesi, sunucu tarafında detaylı bir hata mesajı (stack trace) sızdırabilir.
  • Soru: Hata yönetimi nasıl yapılandırılmış? Genel mi, spesifik mi?
• Denial of Service:
  • Tehdit: Saldırgan, ödeme API'sine yüksek sayıda istek göndererek meşru kullanıcıların işlem yapmasını engelleyebilir.
  • Soru: Rate limiting uygulanıyor mu?

Analiz: Süreç (Back-end İş Mantığı)

• Tampering:
  • Tehdit: İki işlem arasında bir race condition (TOCTOU) durumu, kullanıcının bakiyesini iki kez kullanmasına veya bir kuponu birden fazla kez uygulamasına neden olabilir.
  • Soru: Kaynak kontrolleri (bakiye sorgulama) ve kaynak kullanımı (ödeme yapma) atomik bir işlem olarak mı gerçekleştiriliyor?
• Elevation of Privilege:
  • Tehdit: Zayıf yetkilendirme (IDOR), bir kullanıcının başka bir kullanıcının siparişini veya ödeme yöntemini değiştirmesine izin verebilir.
  • Soru: API endpoint'leri, sadece isteği yapan kullanıcının kendi kaynaklarına eriştiğini doğruluyor mu?
• Repudiation:
  • Tehdit: Yetersiz loglama nedeniyle, bir kullanıcı başarılı bir sipariş verdiğini inkar edebilir.
  • Soru: Her bir ödeme adımının (başlatma, onay, tamamlama) değişmez (immutable) bir kaydı tutuluyor mu?

Analiz: Veri Akışı (Back-end -> Ödeme Ağ Geçidi)

• Spoofing:
  • Tehdit: API anahtarlarının sızması, saldırganın şirket adına Ödeme Ağ Geçidi üzerinde işlem yapmasına olanak tanır.
  • Soru: API anahtarları güvenli bir şekilde saklanıyor ve rotate ediliyor mu? IP adresi kısıtlaması gibi ek kontroller var mı?
• Information Disclosure:
  • Tehdit: Ödeme Ağ Geçidi'ne gereğinden fazla kullanıcı verisi (PII) gönderiliyor olabilir.
  • Soru: Veri minimizasyonu ilkesi uygulanıyor mu? Sadece işlem için gerekli olan veriler mi gönderiliyor?

Bu analiz, bir hata avcısının zihinsel sürecini taklit eder. Her bir STRIDE kategorisi, spesifik bir zafiyet sınıfını düşünmek için bir tetikleyici görevi görür.

4. Tehditlerden Saldırı Hipotezlerine

Bir tehdit modeli oluşturmanın son adımı, soyut tehditleri somut, test edilebilir saldırı hipotezlerine dönüştürmektir. Bu, bir hata avcısının raporunda "Proof of Concept" bölümünü yazmadan önceki adımdır.

Yukarıdaki analizimizden bazı hipotezler türetelim:

• Tehdit (Tampering): Sunucu tarafında fiyat doğrulaması eksik olabilir.
  • Hipotez: "Ödeme isteğindeki price parametresini 100.00'dan 1.00'a değiştirerek bir ürünü %99 indirimle satın alabileceğimi varsayıyorum."
• Tehdit (Elevation of Privilege/IDOR): API endpoint'leri yetkilendirmeyi düzgün yapmıyor olabilir.
  • Hipotez: "/api/orders/{order_id} endpoint'ine başka bir kullanıcıya ait bir order_id ile istek atarak o kullanıcının sipariş detaylarını görüntüleyebileceğimi varsayıyorum."
• Tehdit (Race Condition): Kaynak kullanımı atomik olmayabilir.
  • Hipotez: "Aynı anda iki farklı sekmeden 'Hediye Kartı Kullan' isteği göndererek, 50 TL'lik bir hediye kartını iki kez (toplamda 100 TL) kullanabileceğimi varsayıyorum."

Bu hipotezler, artık sizin için test edilecek somut hedeflerdir.

Sonuç

Bu derste, önceki derslerdeki tüm teorik bilgileri birleştirerek, bir uygulamanın tek bir özelliğine odaklanan pratik bir tehdit modeli oluşturma sürecini tamamladık. Bu, bir hata avcısının verimliliğini en üst düzeye çıkaran kritik bir beceridir.

Temel Çıkarımlar:

• Odaklanma Esastır: Tüm sistemi analiz etmek yerine, yüksek değerli veya yeni eklenmiş tek bir özelliğe odaklanmak, daha derin ve yönetilebilir bir analiz sağlar.
• Süreç Adımları: Etkili bir özellik tehdit modeli şu adımları izler:
  1. Özelliği kapsamını belirle ve temel bileşenlerine ayrıştır.
  2. Bileşenler ve veri akışlarını gösteren odaklanmış bir DFD oluştur.
  3. DFD üzerine güven sınırlarını çiz.
  4. Her bir eleman ve akış için sistematik olarak STRIDE uygula ve potansiyel tehditleri listele.
  5. Bulunan tehditleri, test edilebilir saldırı hipotezlerine dönüştür.
• Sentez Gücü: Bu süreç, mimari anlayışı, sistematik analizi (STRIDE) ve yaratıcı saldırgan zihniyetini bir araya getiren bir sentezleme eylemidir.

Bu dersle birlikte, bir hedef üzerindeki potansiyel zafiyetlerin bir listesini nasıl oluşturacağımızı öğrendik. Ancak bir hata avcısının zamanı sınırlıdır ve her hipotezi test etmek mümkün olmayabilir. Bir sonraki ve bu modülün son dersinde, oluşturduğumuz bu saldırı hipotezlerini tahmini etki, istismar edilebilirlik ve program kapsamı gibi faktörlere göre nasıl formüle edip sıralayacağımızı ve en umut verici olanları nasıl seçeceğimizi ele alacağız.