OWASP WSTG test metodolojisi

Güvenlik testi rastgele tıklamak değildir. Bir önceki derste çıkardığın tehdit tablosu neyi arayacağını söyler; şimdi onu hangi sırayla arayacağını öğreneceksin. OWASP Web Security Testing Guide (WSTG), web uygulaması testini sıralı bir yönteme döker. Bu derste önce WSTG'nin kategorilerini tanıyacaksın.

Sonra kara, beyaz ve gri kutu ayrımını göreceksin. Ardından testin geliştirme döngüsünün neresinde durduğunu inceleyecek, bir bulguyu OWASP Risk Rating ile puanlayıp aynı bulguyu CVSS 4.0 vektörüne çevireceksin. En son bulguyu rapora nasıl yazacağını çıkaracaksın. Bu sıra rastgele değil; her adım bir öncekinin çıktısını kullanır.

WSTG'nin güncel kararlı sürümü 4.2'dir. Test aşamasını on iki kategoriye ayırır. Kategoriler bilgi toplamayla başlar, iş mantığı, istemci taraf testi ve API testiyle biter. Aralarında yapılandırma, kimlik yönetimi, kimlik doğrulama, yetkilendirme, oturum yönetimi, girdi doğrulama, hata yönetimi ve zayıf kriptografi durur.

Sıra rastgele değildir. Her kategori bir öncekinin bulgusunu kullanır. Bilgi toplama olmadan yapılandırma testi hedefsiz kalır.

Kimlik doğrulama sınanmadan oturum testi anlamsızlaşır. Yine de WSTG katı bir kural dizisi değil, bir kılavuzdur. Test eden kişi kategoriler arasında ileri geri gezinebilir. Bir oturum bulgusu seni kimlik doğrulamaya geri döndürebilir.

1  Bilgi toplama            7  Girdi doğrulama
2  Yapılandırma/dağıtım     8  Hata yönetimi
3  Kimlik yönetimi          9  Zayıf kriptografi
4  Kimlik doğrulama        10  İş mantığı
5  Yetkilendirme           11  İstemci taraf testi
6  Oturum yönetimi         12  API testi

Her testin bir kimliği vardır. Temel biçim WSTG-<kategori>-<numara> şeklindedir: kategori dört büyük harfle, numara iki haneyle yazılır. Örneğin WSTG-INFO-02 web sunucusunu parmak izinden tanıma testidir, WSTG-ATHZ-04 nesne düzeyi yetki atlama (IDOR) testidir, WSTG-INPV-05 ise SQL enjeksiyonu testidir.

Kimlikler sürümden sürüme değişebilir. Bu yüzden raporda sürümü de noktasız yazarsın: WSTG-v42-INPV-05. Böylece gelecekte numara değişse bile hangi testi kastettiğin belli kalır.

Bu kimlikler işe yarar, çünkü raporda “giriş formunu denedim” yerine “WSTG-ATHN-03 zayıf hesap kilitleme testini uyguladım” yazarsın. Karşındaki kişi hangi adımı izlediğini tam olarak bilir ve aynı testi kendisi tekrarlayabilir.

Son üç kategori çoğu ekibin atladığı yerdir. İş mantığı testi, tek başına doğru çalışan iki adımın art arda gelince açtığı boşluğu arar. Bir kupon kodu bir kez kullanılmalıdır; art arda gönderilen isteklerle aynı kodun iki kez uygulanması buna örnektir.

İstemci taraf testi tarayıcıda çalışan koda bakar: sayfaya gömülü bir API anahtarı, yalnız arayüzde tutulan bir yetki kontrolü, konsoldan okunabilen bir yorum satırı. API testi ise arayüzün arkasındaki uçları sınar; altıncı modülde bunu ayrıntısıyla göreceksin. Üçü de otomatik tarayıcının kolayca kaçırdığı, elle bakmayı gerektiren kategorilerdir. WSTG'de listenin sonunda dururlar ve öncekilerden çıkan bilgiyi yeniden kullanırlar: bilgi toplamada bulduğun uçlar API testinin, yetkilendirmede çıkardığın roller iş mantığı testinin girdisi olur.

Test üç kutu türünden biriyle yapılır. Kara kutuda test eden kişi kaynak koda bakmaz, yalnız dışarıdan görüneni dener. Gerçek saldırganın gördüğünü görür ama bazı yolları kaçırabilir.

Beyaz kutuda kaynak kod, mimari belgesi ve iç bilgi elindedir. Kapsam geniş olur ama gerçek saldırgan bakış açısı zayıflar. Gri kutu ikisinin ortasıdır: sınırlı bir hesap ya da kısmi belge verilir.

Çoğu profesyonel test gri kutu olarak kurulur, çünkü hem gerçekçi hem verimlidir. Bir kargo portalında gri kutu testi, sana normal bir müşteri hesabı verilmesi demektir. Bu hesapla giriş yaparsın ve asıl soruyu sorarsın: bu hesapla başka bir müşterinin verisine ya da yönetici işlevine ulaşabilir miyim?

Altay Kargo portalı: gri kutu test başlangıç paketi

Hesaplar     [email protected]   müşteri rolü
             [email protected]   müşteri rolü
             [email protected]    çağrı merkezi rolü
Belgeler     API uç listesi (OpenAPI), rol ve yetki tablosu
Ortam        üretimin kişisel verisi maskelenmiş kopyası
Kapsam dışı  ödeme sağlayıcısı, e-posta servisi
Kutu türü    gri kutu, kaynak kod verilmedi

Paketteki en önemli satır hesaplardır. Aynı rolde en az iki hesap istersin, çünkü tek hesapla yatay bir yetki atlamasını kanıtlayamazsın. A müşterisinin oturumuyla B müşterisinin kaydına ulaşmayı denemek için iki ayrı sahip gerekir.

Üst rolde bir hesap da istersin. Müşterinin çağrı merkezi işlevine ulaşıp ulaşamadığını, yani dikey yetki atlamasını, ancak iki rolü karşılaştırarak görürsün. API uç listesi keşif süresini kısaltır ve arayüzde görünmeyen uçları da önüne koyar.

Test ortamında gerçek kişisel veri olmamalıdır; üretim kopyası kullanılıyorsa kişisel alanlar maskelenir. Kutu türünü raporun başına da yazarsın. Okuyan kişi bulguları bu bilgiye göre yorumlar: kara kutu testinde bulunmayan bir açık, kaynak koda bakılsaydı da bulunmazdı demek değildir.

Test tek bir aşamaya sıkışmaz. Gereksinim aşamasında hangi tehdidin önemli olduğu konuşulur. Tasarım aşamasında güven sınırları çizilir ve tehdit modeli çıkarılır. Kod aşamasında gözden geçirme yapılır.

Test aşamasında WSTG kategorileri sırayla uygulanır. Yayın sonrası izleme sürer. WSTG en çok test aşamasında çalışır, ama tasarım aşamasındaki tehdit modelini girdi olarak kullanır. Kurumsal bir sızma testi süreci de benzer bir çerçeveye oturur.

NIST SP 800-115 bunu dört evreye böler: planlama, keşif, saldırı ve raporlama. Planlamada kural ve kapsam belirlenir, keşifte bilgi toplanır ve zayıflık aranır, saldırı evresinde zayıflıklar doğrulanır, raporlama ise baştan sona sürer. WSTG'nin kategorileri bu çerçevenin keşif ve saldırı evrelerini doldurur.

Şemadaki her durak ayrı bir fırsattır. Tasarımda güven sınırı çizilmezse test aşamasında neyin sınanacağı belirsiz kalır. Kod incelemesinde kaçan bir hata test aşamasında yakalanabilir. Test aşamasında kaçan bir hatayı ise yayında saldırgan bulur.

Erken aşamada bulunan hata ucuzdur, geç aşamada bulunan hata pahalıdır. Bir güven sınırı hatasını tasarımda düzeltmek, henüz kod yazılmadan bir çizimi değiştirmek demektir. Aynı hatayı yayından sonra düzeltmek ise kodu değiştirmeyi, yeniden test etmeyi, dağıtmayı ve belki bir olayı yönetmeyi gerektirir. Maliyet aşama ilerledikçe katlanarak artar.

Bulgu, tek başına bir ekran görüntüsüyle bitmez. Her bulguya bir risk düzeyi verirsin ve bu düzey rastgele değildir. OWASP Risk Rating yöntemi riski kısaca Risk = Olasılık × Etki diye tanımlar. Olasılık, sekiz etkeni toplayıp ortalamasını almaktan çıkar.

Dört etken saldırgan tarafını sorar: becerisi, güdüsü, fırsatı ve büyüklüğü. Dört etken de zafiyet tarafını sorar: keşif kolaylığı, sömürü kolaylığı, ne kadar bilindiği ve saldırının fark edilme olasılığı. Etki de teknik ve iş etkisi olarak ikiye ayrılır.

Teknik etki gizlilik, bütünlük, erişilebilirlik ve hesap verebilirlik kaybını sorar. İş etkisi ise mali zarar, itibar kaybı, mevzuata aykırılık ve mahremiyet ihlalini sorar. Her etkene 0 ile 9 arası bir değer verilir. Ortalama 3'ün altındaysa düşük, 3 ile 6 arasıysa orta, 6 ve üstüyse yüksektir.

Bulgu: /api/gonderiler/{no} başka müşterinin kaydını dönüyor (IDOR)

Olasılık etkenleri (0-9)              Etki etkenleri (teknik, 0-9)
- Beceri:     3 (bazı teknik)         - Gizlilik kaybı:     7 (çok müşteri verisi)
- Güdü:       4 (olası kazanç)        - Bütünlük kaybı:     1
- Fırsat:     7 (bir miktar erişim)   - Erişilebilirlik:    1
- Büyüklük:   6 (kimlikli kullanıcı)  - Hesap verebilirlik: 7
- Keşif:      7 (kolay)
- Sömürü:     5 (kolay)               Teknik etki ort. = 4.0 (ORTA)
- Bilinirlik: 9 (herkesçe bilinen)
- Tespit:     8 (loglanır, bakılmaz)  -> olasılık YÜKSEK, etki ORTA
Olasılık ort. = 6.1 (YÜKSEK)          -> Genel risk: YÜKSEK

Çarpımı pratikte bir tablodan okursun. Olasılığın ve etkinin düzeyini bulur, ikisinin kesiştiği hücreye bakarsın. Olasılık yüksek ve teknik etki orta olduğunda tablo genel riski yüksek verir.

İş etkisini biliyorsan teknik etki yerine onu kullanırsın, çünkü düzeltme bütçesini iş tarafı ayırır. Buradaki sayılar kesin bir ölçüm değildir, gerekçeli bir tahmindir. Her etkenin yanına neden o değeri seçtiğini yazarsın: “tespit 8, çünkü istekler günlüğe düşüyor ama kimse bakmıyor” gibi.

Biri itiraz ederse tartışma sayı üzerinden değil, gerekçe üzerinden yürür. Amaç bulguları birbirine göre doğru sıralamaktır. On bulgudan hangisinin bu hafta kapanacağına bu sıra karar verir.

Aynı bulguyu bir de CVSS ile puanlayabilirsin. CVSS (Common Vulnerability Scoring System), FIRST'ün yönettiği ve bir zafiyetin teknik ciddiyetini 0 ile 10 arası bir sayıya çeviren sistemdir. Güncel sürümü 4.0'dır ve 2023'te yayımlandı.

Ölçek şöyledir: 0,1-3,9 düşük, 4,0-6,9 orta, 7,0-8,9 yüksek, 9,0-10,0 kritik. Puan bir vektörden hesaplanır. Vektör, zafiyeti tarif eden kısa metrik kodlarının art arda yazılmasıdır.

Kodlar saldırının nereden yapıldığını, ne kadar zor olduğunu ve hangi yetkiyi gerektirdiğini söyler. Kullanıcı etkileşimi gerekip gerekmediğini ve gizlilik, bütünlük, erişilebilirlik etkisini de yazar. Vektörü elle yazarsın, puanı FIRST'ün hesaplayıcısı verir. Aynı IDOR için vektör şöyle kurulabilir.

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

AV:N  Saldırı vektörü: ağ (internetten erişilebilir)
AC:L  Saldırı karmaşıklığı: düşük
AT:N  Saldırı gereksinimi: yok
PR:L  Gereken yetki: düşük (sıradan bir hesap yeter)
UI:N  Kullanıcı etkileşimi: yok
VC:H  Etkilenen sistemde gizlilik etkisi: yüksek
VI:N / VA:N   bütünlük ve erişilebilirlik etkisi: yok

Taban puan = 7.1  ->  Yüksek

İki yöntem aynı bulguya farklı açıdan bakar. CVSS zafiyetin kendi ciddiyetini ölçer ve senin bağlamını bilmez. FIRST de taban puanın tek başına risk değerlendirmesi olmadığını, kurumun kendi etkenleriyle birlikte okunması gerektiğini yazar. Aynı 7,1 puanlı açık, bir duyuru sitesinde de bir hastane kayıt sisteminde de aynı taban puanı alır.

OWASP Risk Rating ise iş etkisini de sorduğu için bağlamı içeri katar. İki yöntemin sonucu çoğu zaman yakın çıkar ama aynı olması gerekmez. CVSS'de gereken yetki düşükten yoka inerse (PR:L yerine PR:N) aynı açık 8,7'ye tırmanır, çünkü artık hesap bile gerekmez. Pratikte CVSS'i bulgunun teknik ciddiyetini standart bir dille anlatmak için, Risk Rating'i ise düzeltme sırasını kendi bağlamına göre belirlemek için kullanırsın.

Puanı verdikten sonra bulguyu yazarsın. İyi bir bulgu kaydı yeniden üretilebilir olmalıdır; başkası aynı adımları izleyip aynı sonucu görebilmelidir. WSTG'nin raporlama bölümü her bulgu için şu alanları önerir: başvuru kimliği, başlık, olasılık ya da sömürülebilirlik, etki, risk düzeyi, ayrıntılı açıklama, düzeltme adımları ve ek kaynaklar.

Kimlikle bulguya yazışmada ve raporun başka yerlerinde atıf yaparsın. Ayrıntılı açıklama üç soruyu cevaplar: açık nedir, nasıl tetiklenir, hangi zarara yol açar. Bu açıklamayı iki parçaya bölersen okuyan kişinin işi kolaylaşır.

Kök neden belirtiyi değil, asıl sorunu söyler. Tekrar üretme adımları numaralıdır; hangi isteği hangi değerle gönderdiğini ve hangi yanıtı aldığını gösterir. Düzeltme somut olmalıdır, “güvenliği artırın” gibi genel bir öğüt geliştiricinin işine yaramaz. Aşağıda IDOR bulgusunun doldurulmuş şablonu var.

Kimlik:      AK-W-03
Başlık:      Gönderi API'sinde nesne düzeyi yetki atlaması (IDOR)
Olasılık:    Yüksek (sıradan bir müşteri hesabı yeter)
Etki:        Orta teknik etki; müşteri adres kayıtları okunabilir
Risk:        Yüksek (OWASP Risk Rating) / CVSS 4.0 taban 7.1
Kök neden:   Sorgu yalnız gönderi numarasına bakıyor, oturumdaki
             kullanıcının o gönderinin sahibi olup olmadığını sormuyor.
Adımlar:     1. musteri-a ile giriş yap, /api/gonderiler/55087 iste.
             2. Numarayı 55121 yap, oturumu değiştirme, tekrar gönder.
             3. Yanıtın musteri-b'nin kaydını döndürdüğünü gör.
Düzeltme:    Sorguya sahiplik koşulu ekle; kaydın sahibi oturumdaki
             kullanıcı değilse 404 dön.
Ek kaynak:   WSTG-v42-ATHZ-04, CWE-639

Bir sonraki derste bu metodolojinin bir aracı nasıl kullandığını göreceksin. Web vekil aracı, topladığın bilgiyi elle sınamanın yolunu açar. Araç tarayıcı ile sunucu arasına girer; sen de bir isteği durdurur, değiştirir ve tekrar tekrar gönderirsin.

Bugün öğrendiğin kategori sırası, o araçla hangi isteği önce inceleyeceğini de belirler. Bilgi toplamadan çıkan uçları önce ele alırsın, iş mantığını en sona bırakırsın. Az önce doldurduğun rapor şablonu ise vekilin tuttuğu istek geçmişinden beslenir; tekrar üretme adımlarını o geçmişten satır satır çıkarırsın.