Kötüye kullanım senaryosu

Kullanım senaryosu bir kullanıcının sistemle normal şekilde nasıl etkileşeceğini anlatır: müşteri iade formunu doldurur, gönderir, onay bekler. Kötüye kullanım senaryosu aynı akışı ters çevirir ve sorar: aynı formu kötü niyetli biri nasıl kullanır? STRIDE teknik sınırları tarar, kötüye kullanım senaryosu iş mantığını tarar. İkisi birbirini tamamlar.

Biri buradan içeri girer misin diye sorar, öteki bu özelliği amacı dışında nasıl işletirsin diye. AltayKargo iade servisinde normal senaryo şudur: müşteri hasarlı paketin takip numarasını girer, açıklama yazar, fotoğraf yükler, sistem iadeyi onaya gönderir. Bu derste aynı akışın kötüye kullanılabilecek yönlerini çıkaracaksın. Her senaryoya bir önlem, bir test ve bir izleme kuralı bağlayacaksın.

Konuyu netleştiren üç terim vardır. Kullanım senaryosu (use case) beklenen akıştır. Hatalı kullanım (misuse) dikkatsiz ama kötü niyetsiz davranıştır: müşteri aynı formu yanlışlıkla iki kez gönderir. Kötüye kullanım (abuse) ise bilerek yapılır.

OWASP'ın kötüye kullanım rehberi onu, bir özelliği geliştiricinin beklemediği biçimde kullanıp sonucunu etkilemek diye tanımlar. İki durumun önlemi farklıdır. Hatalı kullanıma karşı arayüzü düzeltir, uyarı gösterirsin. Kötüye kullanıma karşı sunucuda kural, eşik ve izleme koyarsın.

Kötüye kullanım çoğu zaman bir iş mantığı açığıdır. Bu açıkta kodda sözdizimi hatası yoktur; her satır yazıldığı gibi çalışır. Sorun, iş kuralının zorlanmamasıdır. CWE-841 bu ailenin tipik örneğidir: beklenen adım sırası zorlanmaz.

Senaryoyu yazarken beş sabit alan doldurulur: aktör, amaç, yöntem, sonuç, önlem. Örneğe bak. Aktör sahte bir müşteridir. Amacı hasarsız bir paket için iade parası almaktır.

Yöntemi gerçek bir takip numarasıyla uydurma açıklama ve internetten indirilmiş bir fotoğraf yüklemektir. Sonuç, otomatik onay verilirse parasal kayıptır. Önlem, yüksek tutarlı iadelerin insan onayına düşmesi ve aynı fotoğrafın daha önce başka bir işlemde kullanılıp kullanılmadığının kontrol edilmesidir.

KÖTÜYE KULLANIM ŞABLONU
------------------------
Aktör  : sahte müşteri
Amaç   : hasarsız paket için iade parası almak
Yöntem : gerçek takip no + uydurma açıklama + internetten indirilmiş fotoğraf
Sonuç  : otomatik onay parasal kayıp yaratır
Önlem  : tutar eşiği üstü insan onayı, fotoğraf tekrar kontrolü

Her kötüye kullanım senaryosu para kaybıyla bitmez. Bazısı gizlilikle, bazısı sistemin sürekli çalışır kalmasıyla ilgilidir. Bir senaryo bazen tek bir kullanıcıyı değil, tüm müşteri tabanını etkileyebilir; bu yüzden şablonu doldururken etkinin kapsamını da düşünmek gerekir.

Kapsamı geniş bir senaryoyu önce yazıp sonra daraltmak, hiç yazmamaktan daha güvenlidir. Önlem alanına genel bir çekince değil, bir veriye ve bir eşiğe bakan somut bir kontrol yazılır. Şimdi aynı şablonu yeni bir senaryo için dolduracaksın.

Yazdığın cevap bir şeyi gösterir: davranışı tarif etmek yetmez, onu yakalayacak bir kontrol de gerekir. Kontrolü bulmak için açığın tipini tanımak işe yarar. Adım atlamada müşteri fotoğraf adımını atlayıp doğrudan onay isteği gönderir. Negatif ya da aşırı değerde tutar alanına eksi bir sayı ya da sipariş tutarının üstünde bir değer girilir.

Tekrar kullanımda aynı fotoğraf, kupon ya da onay bağlantısı birden çok kez kullanılır. Kota aşımında tek hesap bir günde yüz iade açar ya da bir betik indirim kodlarını sırayla dener.

OWASP bu otomasyona OAT-002 Token Cracking der. Rol karışmasında destek temsilcisi, yalnız yöneticiye ait onayı gizli bir düğmeyle verir. ASVS 5.0'ın V2 bölümü adım sırası, iş kuralı sınırı ve insan hızında işlem için doğrudan gereksinim yazar.

Bu tiplerin ortak önlemi, kuralı sunucuda zorlamaktır. Adım sırası sunucuda bir durum makinesiyle tutulur: iade taslak, fotoğraf yüklendi, incelemede, onaylandı ve ödendi durumlarından yalnız izinli geçişlerle ilerler. Tutar istemciden alınmaz; sipariş kaydından hesaplanır, sıfırdan büyük olduğu ve sipariş tutarını aşmadığı denetlenir.

Kota hesap başına ve gün başına tutulur. Rol denetimi arayüzdeki düğmeye değil, uç noktaya konur. Tarayıcıda gizlenen bir düğme güvenlik denetimi değildir, çünkü saldırgan isteği elle yazabilir.

Tekrar kullanımın sinsi bir türü yarış durumudur (race condition, CWE-362). Müşteri aynı iade onayını iki sekmeden aynı anda gönderir. İki istek de durumu okur ve ikisi de onaylandı ama ödenmedi görür. Sonra ikisi de ödeme başlatır ve çift ödeme olur.

Açığın kökü, denetim ile işlemin arasında bir boşluk kalmasıdır. Tasarımdaki önlem, denetimi ve yazmayı tek bir atomik adımda yapmaktır. Aşağıdaki ilk sorgu çifti bu boşluğu bırakır.

İkinci sorgu durumu yalnız beklenen durumdan değiştirir ve kaç satırı güncellediğini söyler. İkinci istek geldiğinde durum çoktan değişmiştir, sorgu 0 satır günceller ve ödeme başlamaz.

-- Yanlış: önce oku, sonra yaz. İki istek arada birbirini görmez.
SELECT durum FROM iadeler WHERE id = 42;
UPDATE iadeler SET durum = 'odendi' WHERE id = 42;

-- Doğru: denetim ve yazma tek sorguda
UPDATE iadeler SET durum = 'odendi'
 WHERE id = 42 AND durum = 'onaylandi';

-- İlk istek:   UPDATE 1  -> ödeme başlar
-- İkinci istek: UPDATE 0  -> istek reddedilir

Şablonu dolduran kişi tek başına güvenlik ekibi olmamalıdır. OWASP'ın kötüye kullanım rehberi bir çalıştay önerir ve beş rolü masaya çağırır. İş analisti özelliği iş gözüyle anlatır.

Risk analisti önerilen saldırının iş etkisini tartar. Sızma testi uzmanı saldırı önerir; mümkünse farklı geçmişten iki uzman katılır. Teknik lider önlemin uygulanabilir olup olmadığını söyler.

Kalite güvence uzmanı da olumlu ve olumsuz test durumlarını düşünür. İş kuralını en iyi ürün sahibi bilir, geliştirici kodu bilir, güvenlik ekibi teknik açığı bilir. Bu bakış açıları bir araya gelmeden yazılan senaryo ya çok teknik ya çok iyimser kalır.

Çalıştay sabit bir sırayla ilerler. Önce iş tarafı özelliği anlatır. Sonra sızma testi uzmanları saldırı önerir.

Her saldırı için uygulama güvenliği ekibi bir önlem ve önlemin uygulanacağı yeri önerir. Teknik ekip önlemin yapılabilirliğini değerlendirir. Sızma testi uzmanı saldırıya bir risk puanı hesaplar, risk sorumlusu puanı kabul eder ya da değiştirir.

Son adımda ekip hangi saldırıların ele alınacağına karar verir. Saldırı fikri için boş sayfaya bakmazsın. OWASP Otomatik Tehditler listesi (OAT-008 Credential Stuffing gibi), MITRE CAPEC saldırı kalıpları ve ekibin biriktirdiği saldırı sözlüğü iyi başlangıç noktalarıdır. Her kararın sonucu aşağıdaki gibi bir kayda yazılır.

Kimlik            : ABUSE_CASE_001
Etkilenen özellik : FEATURE_IADE_FOTO (hasar fotoğrafı yükleme)
Saldırı           : Onaylanmış bir iadenin fotoğrafı başka takip
                    numarasıyla yeniden yüklenir, sahte iade açılır
CVSS vektörü      : CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
CVSS puanı        : 5.3 (Orta)
Sınıf             : İş
Önlem             : DEFENSE_007, fotoğraf özeti son 90 günün kayıtlarıyla
                    karşılaştırılır, eşleşen iade incelemeye düşer
Karar             : Ele alınacak
Gerekçe           : Otomatik onay sınırının altındaki iadeler insan
                    görmeden ödeniyor

Kaydın alanlarına tek tek bak. Kimlik ve özellik alanı senaryoyu backlog'daki işe bağlar. Saldırı cümlesi tek bir davranışı anlatır; iki davranış iki kayıt demektir.

OWASP rehberi puan alanını CVSS 3 ile örnekler, bu kayıt ise 2023'te yayımlanan CVSS 4.0'ı kullanır. AV:N saldırının ağ üstünden yapıldığını, PR:L sıradan bir müşteri hesabının yettiğini söyler. VI:L bütünlüğün sınırlı ölçüde bozulduğunu anlatır ve puan 5.3 ile orta çıkar.

Burada dikkat et: CVSS parasal kaybı ölçmez. Sınıf alanındaki İş etiketi bu yüzden önemlidir; iş sınıfındaki bir senaryonun asıl ağırlığını risk analisti belirler. Karar ve gerekçe alanı hiçbir kayıtta boş kalmaz.

Çalıştayın sırası rastgele değildir. Önlem, saldırı bilinmeden önerilemez. Puan da önlemin yapılabilirliği bilinmeden anlam taşımaz, çünkü uygulanamayacak bir önlem riski düşürmez. Karar en sona kalır.

Ekip ancak bütün saldırıları, önlemleri ve maliyetleri gördükten sonra neyi ele alacağını seçebilir. Rehber süreyi özellik listesinin büyüklüğüne bağlar ve başlangıç için dört saati uygun bulur. OWASP bu rehberi 2025'te tarihsel (historical) olarak işaretledi.

Gerekçesi, çerçevenin pratikte seyrek kullanılması ve ağır bulunmasıdır. Bu yüzden adımları ekibinin ölçeğine göre küçültürsün. Küçük bir değişiklikte yirmi dakikalık bir toplantı bile, tek kişinin masasında yazılan bir sayfadan daha fazla senaryo çıkarır. Şimdi bu sırayı kendin kur.

Senaryo bir belgede kalırsa kod ona hiç dokunmaz. OWASP rehberi çevik ekiplerde senaryonun sprint planlamasından sonra yazılmasını ve özelliğin kabul kriterine dönüşmesini önerir. Kabul kriteri için Gherkin adlı yarı yapısal dil yaygındır. Gherkin'in Türkçe anahtar kelimeleri de vardır: Diyelim ki (Given), Eğer (When), O zaman (Then).

Aşağıda ABUSE_CASE_001 önce kabul kriteri, sonra otomatik test olarak yazıldı. Kriteri ürün sahibi okuyup onaylayabilir. Test ise her derlemede çalışır ve önlem kaldırılırsa kırılır.

# language: tr
Özellik: Hasar fotoğrafı yükleme

  Senaryo: Aynı fotoğraf başka takip numarasıyla yükleniyor (ABUSE_CASE_001)
    Diyelim ki son 90 günde AK-1001 takip numarasıyla bir fotoğraf yüklendi
    Eğer aynı fotoğraf AK-2002 takip numaralı yeni iadeye yüklenirse
    O zaman iade "manuel_inceleme" durumuna düşer
    Ve otomatik onay çalışmaz


# ABUSE_CASE_001: aynı fotoğraf özeti başka takip numarasıyla onaylanmaz
def test_ayni_foto_ikinci_iadede_incelemeye_duser(istemci, foto_bayt):
    ilk = istemci.post("/iadeler/AK-1001/foto", files={"foto": foto_bayt})
    assert ilk.status_code == 201

    ikinci = istemci.post("/iadeler/AK-2002/foto", files={"foto": foto_bayt})
    assert ikinci.status_code == 202
    assert ikinci.json()["durum"] == "manuel_inceleme"

Testi satır satır oku. Yorum satırı kaydın kimliğini taşır; OWASP rehberi de kodda senaryo kimliğine atıf önerir. Böylece bir denetimin hangi senaryo için yazıldığını arayıp bulursun. İlk istek meşru yüklemedir ve 201 döner.

İkinci istek aynı baytları başka takip numarasına gönderir. Sunucu isteği reddetmez; 202 ile kabul eder ama iadeyi manuel incelemeye düşürür. Bu bir tasarım kararıdır. Aynı fotoğrafı iki paket için yükleyen dürüst bir müşteri de olabilir; sert ret yerine insan onayı bu yüzden seçildi.

Her kötüye kullanım önlenemez, bazısı ancak izlenir. Senaryoyu izleme kuralına çevirmek için önce davranışı ele veren sinyali yazarsın. Fotoğraf tekrarı için üç sinyal vardır: aynı görsel özeti, aynı cihaz ya da IP adresi ve kısa sürede çok iade.

Kural bu sinyalleri okumak için belirli günlük alanlarına ihtiyaç duyar: zaman, hesap, takip numarası, fotoğrafın SHA-256 özeti, istemci adresi ve işlemin sonucu. Örneğin kural, aynı özet 90 gün içinde farklı bir hesapta ikinci kez görülünce uyarı üretir ve iadeyi otomatik onaydan çıkarır. Bu alanlar tasarımda kararlaştırılmazsa kural yazılacağı gün günlükte yoktur. Kişisel veri kuralı da unutulmaz: günlüğe fotoğrafın kendisi değil, yalnız özeti yazılır.

Kötüye kullanım senaryosu kargoya özgü değildir. Bilet satışı, kupon kampanyası, puan programı ya da randevu sistemi aynı kalıbı taşır: normal bir davranış aşırı hızda ya da amacı dışında tekrarlanır. OWASP kıt ürünü haksız yoldan kapmaya OAT-005 Scalping, satın almadan stok kilitlemeye OAT-021 Denial of Inventory der.

Senaryoyu yazarken hep aynı soruyu sorarsın: bu davranışı bir insan mı yapıyor, yoksa bir betik mi? Güvenli yazılım sertifikası CSSLP de gereksinim alanında hatalı ve kötüye kullanım senaryosu yazmayı ayrı bir madde olarak sayar. Bir sonraki derste bu senaryolara karşı sistemin başlangıç ayarlarını ve yetkilerini sıkılaştıracaksın.