Tehdit Modelleme - STRIDE ile Güvenlik Analizi - PHP

Tehdit modelleme sıfır hata garantisi vermek değildir. Burda amaç tasarım aşamasında nelerin yanlış gideceğini düşünmek ve ona göre yol haritası çizmektir.

Kod yazmaya başlamadan önce “burada ne ters gidebilir?” diye düşünmek.

Tehdit modelleme için ilk günden karmaşık araçlar kullanmanız gerekmiyor. Küçük bir özellik için şu dört soru bile yeterli olabilir:

1. Ne inşa ediyoruz?
2. Ne ters gidebilir?
3. Buna karşı ne yapacağız?
4. Aldığımız önlem gerçekten işe yaradı mı?

Verinin yolculuğunu çizin

Kullanıcıyı, uygulamayı, veritabanını ve dış servisleri kutularla göstermek çoğu zaman yeterli.

Örneğin basit bir profil fotoğrafı yükleme akışı şöyle olabilir:

Kullanıcı
- - ↓ fotoğraf yükler
- PHP Backend
- - - - - ↓ - - - - - ↓
- - Dosya sistemi Veritabanı

Şimdi okların üzerine sorular ekleyebiliriz:

- Kullanıcı gerçekten resim mi yüklüyor?
- Dosyanın adı değiştirilebilir mi?
- Çok büyük bir dosya gönderilirse ne olur?
- Dosya web dizinine kaydedilirse PHP olarak çalışabilir mi?
- Başka bir kullanıcı bu dosyaya erişebilir mi?

Henüz tek satır kod yazmadık ama dosya türü kontrolü, boyut sınırı, erişim kontrolü ve çalıştırma izni gibi ihtiyaçlar ortaya çıktı. Dosya yükleme güvenliği bölümündeki önlemlerin büyük bir kısmı daha tasarım aşamasında kendisini göstermeye başladı.

STRIDE ne işe yarıyor?

“Ne ters gidebilir?” sorusu çok geniş olduğu için bazen insanın aklına hiçbir şey gelmiyor. STRIDE bu soruyu altı küçük parçaya bölüyor.

- Spoofing: Birisi başka bir kullanıcı gibi davranabilir mi?
- Tampering: Gönderilen veri değiştirilebilir mi?
- Repudiation: Kullanıcı yaptığı işlemi sonradan inkâr edebilir mi?
- Information Disclosure: Sistem gereğinden fazla bilgi sızdırabilir mi?
- Denial of Service: Bir istek sistemi yavaşlatabilir veya durdurabilir mi?
- Elevation of Privilege: Normal bir kullanıcı daha yüksek yetki kazanabilir mi?

Mesela bir sipariş sayfasına bakarken “fiyat tarayıcıdan değiştirilebilir mi?”, “başka müşterinin sipariş numarası yazılabilir mi?” ve “aynı ödeme isteği art arda gönderilirse ne olur?” diye sorabilirsiniz.

İkinci soru özellikle önemli. Adres satırındaki bir numarayı değiştirerek başka kullanıcının kaydına ulaşmak IDOR olarak bilinen oldukça yaygın bir erişim kontrolü açığına dönüşebilir.

Kimsenin kullanmadığı eski bir dosya yükleme modülünü güvenli hâle getirmekle uğraşmak yerine direkt silmek, o riski tamamen ortadan kaldırmanın en kısa yoludur.

Kredi kartı verisini kendi sunucunuzda tutmak ve onun güvenliğiyle uğraşmak yerine bu işi uzman bir ödeme sağlayıcısına bırakmak bazen daha mantıklıdır.

Tehdit modelleme bir kez yapılıp rafa kaldırılan belge de olmamalı. Kod tamamlandığında çizdiğiniz sistem ile ortaya çıkan sistemin aynı olup olmadığını kontrol edin. Yeni bir servis, kuyruk veya yönetici paneli eklendiyse modelin de değişmesi gerekir.

Bu yaklaşım güvenli yazılım yaşam döngüsünün önemli parçalarından biri. Güvenliği son testten alıp tasarım, geliştirme ve dağıtımın tamamına yayıyor.

Başlangıç için şu kısa listeyi kullanabilirsiniz:

- Sistemdeki kullanıcıları, servisleri ve veri depolarını çizin.
- Verinin geçtiği güven sınırlarını işaretleyin.
- Her akış için STRIDE sorularını sorun.
- Riskleri ihtimal ve etkisine göre sıralayın.
- Alınan kararları kısa da olsa yazılı tutun.
- Uygulama tamamlandığında modeli gerçekle karşılaştırın.
- Kritik işlemlerin kayda girdiğini kontrol edin; çünkü loglama ve izleme olmadan bazı tehditlerin gerçekleştiğini fark edemezsiniz.

Tehdit modellemenin amacı gelecekte olabilecek her saldırıyı tahmin etmek değil. Böyle bir şey zaten mümkün değil.

Ama kodu yazmadan önce doğru soruları sorarsanız saldırganın kullanabileceği kolay yolların önemli bir kısmını daha kapıyı açmadan görebilirsiniz.

DFD çizimi, STRIDE kategorileri, risk matrisi ve tehditlere verilebilecek yanıtların ayrıntılı anlatımını PHP Güvenliği El Kitabı — Tehdit Modelleme bölümünde okuyabilirsiniz.