- Konu sahibi
- #1
Kötüye kullanım senaryoları, normal kullanıcı akışının saldırgan tarafından hangi amaçla, hangi önkoşullarla ve hangi güvenlik açığı kullanılarak kötüye çevrilebileceğini sistematik biçimde yazmaktır. Uygulanabilir bir model için önce kritik varlıkları ve aktörleri belirleyin; ardından veri akışındaki güven sınırlarını işaretleyip her önemli işlem için saldırganın hedefini, eylemlerini, beklenen etkisini ve karşılanacak güvenlik kontrolünü kaydedin. Sonuç, soyut bir tehdit listesi değil, geliştiricinin test edebileceği senaryo ve doğrulanabilir kontrol olmalıdır.
Bir senaryoyu yazmadan önce uygulamayı küçük ve anlaşılır parçalara ayırın:
Her senaryoyu şu kalıpla yazmak yeterlidir:
Varsayalım ki uygulama, e-posta ile gönderilen bir sıfırlama belirteciyle yeni parola belirletiyor. Varlık hesap erişimidir; giriş noktaları sıfırlama isteği, belirteç doğrulama ve yeni parola API'leridir. Kötüye kullanım senaryosu şöyledir: saldırgan hedef hesaba ait reset tokenını elde edip hedefin parolasını değiştirir. Ayrı bir bağlama kusurunda ise saldırgan kendi hesabı için aldığı tokenın yanına farklı account_id göndererek hedef hesabı değiştirmeyi dener; bunlar farklı önkoşullara sahip iki senaryodur.
Modelde kontrol olarak belirtecin sunucuda rastgele üretilmesi, kısa süre geçerli olması, tek kullanımdan sonra iptal edilmesi, yalnız ilgili hesapla eşleştirilmesi ve parola değişiminden sonra mevcut oturumların gözden geçirilmesi yazılabilir. Yalnız yetkili test hesaplarıyla; tüketilmiş tokenın ikinci kullanımı, kendi tokenıyla başka account_id gönderilmesi ve eşzamanlı iki tüketim sınanır. Gerçek hedefin geçerli tokenı çalınmışsa yalnız hesap eşleştirme kontrolü saldırıyı engellemez; token sızıntısını önleme ve olay sonrası oturum kontrolleri de gerekir. Beklenen sonuç, her iki isteğin de reddedilmesi ve hassas ayrıntıların istemciye açıklanmamasıdır. Test geçiyorsa senaryo için temel kontrol doğrulanmıştır; geçmiyorsa önce ilgili akış düzeltilmeli, sonra aynı senaryo yeniden çalıştırılmalıdır.
Bir senaryonun önceliğini belirlerken aşağıdaki ayrım pratik olur:
Tablo yalnız sıralama içindir; “düşük etki” bir senaryonun önemsiz olduğu anlamına gelmez. Tekrarlanabilir küçük bir işlem, toplu kullanıldığında farklı bir etki oluşturabilir.
En yaygın hata, yalnızca güvenlik açığının adını yazıp saldırganın hedefini ve sonucu belirtmemektir. “SQL injection olabilir” bir senaryo değildir; hangi uç noktada hangi verinin okunabileceği ve hangi kontrolün bunu engelleyeceği ayrıca yazılmalıdır. İkinci hata, istemci tarafı doğrulamayı güvenlik kontrolü saymaktır; saldırgan isteği tarayıcıyı kullanmadan gönderebilir. Üçüncü hata, yalnız başarılı saldırıyı düşünmektir. Başarısız denemelerin günlüklenmesi, alarm üretmesi ve hassas hata ayrıntısı sızdırmaması da modelin parçasıdır.
Ayrıca saldırganı her zaman anonim kabul etmek doğru değildir. Kayıtlı kullanıcının başka kullanıcı verisine erişmesi, düşük yetkili hesabın yönetici işlevine ulaşması ve ele geçirilmiş oturumun kötüye kullanılması ayrı senaryolardır. Modeli tamamladıktan sonra her kontrolün bir test adımı, bir sorumlusu ve yeniden değerlendirme koşulu olduğundan emin olun; uygulama akışı veya yetki modeli değiştiğinde senaryoları tekrar gözden geçirin.
Güvenlik açığı bir teknik kusurdur; kötüye kullanım senaryosu ise saldırganın amacını, izlediği yolu, önkoşulları ve oluşacak etkiyi anlatır. Bir senaryo, henüz açık bulunmasa bile hangi kontrolün doğrulanması gerektiğini gösterebilir.
Kimlik doğrulama, yetkilendirme, kritik veri akışı, üçüncü taraf entegrasyonu veya iş kuralı değiştiğinde ilgili akış yeniden modellenmelidir. Küçük arayüz değişiklikleri tek başına yeterli olmayabilir; sunucu tarafındaki davranış değişikliği belirleyicidir.
Saldırganın hedefi, önkoşulu, istek yolu, etkisi, karşı kontrolü ve beklenen test sonucu açıkça yazılmışsa senaryo uygulanabilir durumdadır. Test sonucu kontrolün çalıştığını ve başarısız denemelerin uygun şekilde ele alındığını göstermelidir.
Modelin temel parçaları
Bir senaryoyu yazmadan önce uygulamayı küçük ve anlaşılır parçalara ayırın:
- Varlık: Korunacak şeydir. Örneğin hesap oturumu, kişisel bilgiler, yönetici işlemleri, sipariş tutarı veya parola sıfırlama belirteci.
- Aktör: Yetkisiz ziyaretçi, kayıtlı kullanıcı, başka bir kullanıcının hesabını ele geçirmiş kişi, kötü niyetli satıcı ya da ayrıcalıklı çalışan olabilir.
- Giriş noktası: Form, API uç noktası, dosya yükleme alanı, webhook, yönetim paneli veya üçüncü taraf entegrasyonudur.
- Güven sınırı: Tarayıcı ile sunucu, kullanıcı ile yönetici API'si veya uygulama ile ödeme sağlayıcısı arasındaki güven farkıdır.
- Etki: Yetkisiz veri okuma, hesap ele geçirme, veri değiştirme, para veya stok manipülasyonu, hizmet kesintisi ya da iz kayıtlarının bozulmasıdır.
Her senaryoyu şu kalıpla yazmak yeterlidir:
Aktör, önkoşul sağlandığında, giriş noktası üzerinden şu eylemi yapar; amaçlanan etki oluşur. Kontrol, bunu engeller veya görünür kılar; test ise kontrolün çalıştığını kanıtlar.Uygulanabilir modelleme adımları
- Kapsamı seçin. Tek bir kritik akış belirleyin; örneğin parola sıfırlama, kupon kullanımı veya yönetici raporu indirme. Tüm uygulamayı aynı anda modellemek ayrıntıyı artırır, sonucu değil.
- Normal akışı çıkarın. İsteğin nereden geldiğini, hangi servislere gittiğini, hangi verinin okunduğunu veya değiştirildiğini ve yanıtın kime döndüğünü yazın.
- Güven sınırlarını işaretleyin. Kullanıcıdan gelen her değer, istemci tarafındaki gizli alanlar ve üçüncü taraf yanıtları sunucu açısından doğrulanması gereken girdilerdir.
- Kötüye kullanım hedefini yazın. “Sistem saldırıya uğrar” yerine “başka kullanıcının sıfırlama işlemini tamamlar” veya “aynı kuponu birden fazla siparişte kullanır” gibi ölçülebilir bir sonuç belirtin.
- Önkoşul ve saldırı yolunu ekleyin. Saldırganın oturum açmış olması, bir belirteç elde etmesi veya belirli bir kaydın kimliğini bilmesi gibi koşulları ayırın. Ardından gerekli istek dizisini normal kullanıcı akışına göre tanımlayın.
- Kontrol ve kanıtı belirleyin. Sunucu tarafı yetkilendirme, tek kullanımlık belirteç, işlem bütünlüğü, oran sınırlama, günlükleme veya alarm gibi kontrolleri ilgili adıma bağlayın. Testte beklenen sonucu da yazın: örneğin işlem reddedilir, kayıt değişmez ve olay günlüğe alınır.
- Önceliklendirin. Etki, gerçekleşme olasılığı, gerekli ayrıcalık ve tespit edilebilirliği birlikte değerlendirin. Yüksek etkili ve düşük önkoşullu senaryoları önce düzeltin.
Somut örnek: parola sıfırlama
Varsayalım ki uygulama, e-posta ile gönderilen bir sıfırlama belirteciyle yeni parola belirletiyor. Varlık hesap erişimidir; giriş noktaları sıfırlama isteği, belirteç doğrulama ve yeni parola API'leridir. Kötüye kullanım senaryosu şöyledir: saldırgan hedef hesaba ait reset tokenını elde edip hedefin parolasını değiştirir. Ayrı bir bağlama kusurunda ise saldırgan kendi hesabı için aldığı tokenın yanına farklı account_id göndererek hedef hesabı değiştirmeyi dener; bunlar farklı önkoşullara sahip iki senaryodur.
Modelde kontrol olarak belirtecin sunucuda rastgele üretilmesi, kısa süre geçerli olması, tek kullanımdan sonra iptal edilmesi, yalnız ilgili hesapla eşleştirilmesi ve parola değişiminden sonra mevcut oturumların gözden geçirilmesi yazılabilir. Yalnız yetkili test hesaplarıyla; tüketilmiş tokenın ikinci kullanımı, kendi tokenıyla başka account_id gönderilmesi ve eşzamanlı iki tüketim sınanır. Gerçek hedefin geçerli tokenı çalınmışsa yalnız hesap eşleştirme kontrolü saldırıyı engellemez; token sızıntısını önleme ve olay sonrası oturum kontrolleri de gerekir. Beklenen sonuç, her iki isteğin de reddedilmesi ve hassas ayrıntıların istemciye açıklanmamasıdır. Test geçiyorsa senaryo için temel kontrol doğrulanmıştır; geçmiyorsa önce ilgili akış düzeltilmeli, sonra aynı senaryo yeniden çalıştırılmalıdır.
Bir senaryonun önceliğini belirlerken aşağıdaki ayrım pratik olur:
| Senaryo özelliği | Örnek | Öncelik yorumu |
|---|---|---|
| Yüksek etki, düşük önkoşul | Kimlik doğrulamasız yetki açığı | İlk incelenecek grup |
| Yüksek etki, yüksek önkoşul | Ele geçirilmiş yönetici oturumuyla veri dışa aktarma | Ayrıcalık ve tespit kontrolleri birlikte incelenir |
| Düşük etki, kolay tekrar | Aynı bildirimin çok kez oluşturulması | Kötüye kullanım maliyeti ve hacmi ölçülür |
Tablo yalnız sıralama içindir; “düşük etki” bir senaryonun önemsiz olduğu anlamına gelmez. Tekrarlanabilir küçük bir işlem, toplu kullanıldığında farklı bir etki oluşturabilir.
Sık yapılan hatalar
En yaygın hata, yalnızca güvenlik açığının adını yazıp saldırganın hedefini ve sonucu belirtmemektir. “SQL injection olabilir” bir senaryo değildir; hangi uç noktada hangi verinin okunabileceği ve hangi kontrolün bunu engelleyeceği ayrıca yazılmalıdır. İkinci hata, istemci tarafı doğrulamayı güvenlik kontrolü saymaktır; saldırgan isteği tarayıcıyı kullanmadan gönderebilir. Üçüncü hata, yalnız başarılı saldırıyı düşünmektir. Başarısız denemelerin günlüklenmesi, alarm üretmesi ve hassas hata ayrıntısı sızdırmaması da modelin parçasıdır.
Ayrıca saldırganı her zaman anonim kabul etmek doğru değildir. Kayıtlı kullanıcının başka kullanıcı verisine erişmesi, düşük yetkili hesabın yönetici işlevine ulaşması ve ele geçirilmiş oturumun kötüye kullanılması ayrı senaryolardır. Modeli tamamladıktan sonra her kontrolün bir test adımı, bir sorumlusu ve yeniden değerlendirme koşulu olduğundan emin olun; uygulama akışı veya yetki modeli değiştiğinde senaryoları tekrar gözden geçirin.
Kaynaklar
Sık sorulan sorular
Kötüye kullanım senaryosu ile güvenlik açığı arasındaki fark nedir?
Güvenlik açığı bir teknik kusurdur; kötüye kullanım senaryosu ise saldırganın amacını, izlediği yolu, önkoşulları ve oluşacak etkiyi anlatır. Bir senaryo, henüz açık bulunmasa bile hangi kontrolün doğrulanması gerektiğini gösterebilir.
Senaryolar ne zaman yeniden modellenmelidir?
Kimlik doğrulama, yetkilendirme, kritik veri akışı, üçüncü taraf entegrasyonu veya iş kuralı değiştiğinde ilgili akış yeniden modellenmelidir. Küçük arayüz değişiklikleri tek başına yeterli olmayabilir; sunucu tarafındaki davranış değişikliği belirleyicidir.
Bir senaryonun tamamlandığı nasıl anlaşılır?
Saldırganın hedefi, önkoşulu, istek yolu, etkisi, karşı kontrolü ve beklenen test sonucu açıkça yazılmışsa senaryo uygulanabilir durumdadır. Test sonucu kontrolün çalıştığını ve başarısız denemelerin uygun şekilde ele alındığını göstermelidir.
