Web Uygulaması Sızma Testi: OWASP Top 10, Burp Suite ve Elle Test Metodolojisi

Hızlı Cevap: Web uygulaması sızma testi, bir web uygulamasının kimlik doğrulama, yetkilendirme, girdi işleme ve iş mantığı katmanlarını gerçek bir saldırgan gibi sınayarak istismar edilebilir zafiyetleri kanıtlamaktır. Çerçeve OWASP Top 10 2021'dir: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection (SQL injection ve XSS dahil), A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, A07 Identification and Authentication Failures, A08 Software and Data Integrity Failures, A09 Security Logging and Monitoring Failures, A10 Server-Side Request Forgery (SSRF). Metodoloji OWASP Web Security Testing Guide (WSTG), birincil araç Burp Suite'tir. Otomatik tarayıcı yüzeyi tarar; iş mantığı ve yetki zafiyetlerini ancak elle test bulur. Bu yüzden ikisi birlikte gerekir. Verizon'un yıllık veri ihlali raporlarında temel web uygulaması saldırıları, ihlal kalıplarının en üst sıralarındadır.

Web uygulamaları, kurumların internete açılan en geniş ve en sık saldırılan yüzeyidir. Bir kurumun on yıllık emeği, bir mobil uygulamanın arkasındaki API, bir e-ticaret sitesinin ödeme akışı ya da bir kurumsal portalın oturum yönetimi, hepsi bu yüzeyde durur. Verizon'un yıllık veri ihlali raporlarında (DBIR) temel web uygulaması saldırıları, ihlal kalıplarının en üst sıralarında yer alır ve bu saldırıların büyük bölümü çalınmış kimlik bilgileriyle gerçekleşir. Web uygulaması sızma testi, bu yüzeyi bir tarayıcı raporundan ibaret görmeyip, gerçek bir saldırganın yapacağı zincirleri yetkili biçimde kurar, çalıştırılabilir kanıtla gösterir ve düzeltme yol haritası verir.

Bu yazı, API güvenliği sızma testi ve web sitesi güvenlik hizmeti yazılarımızı tamamlar; burada odak, web uygulamasının kendi mantığını derinlemesine sınayan elle testtir. İç ağ tarafı için Active Directory iç ağ sızma testi, hizmet türleri için red team, sızma testi ve purple team farkı yazımıza bakabilirsiniz.

OWASP Top 10 nedir, neden çerçeve

OWASP Top 10, OWASP Foundation'ın yayımladığı, web uygulamalarındaki en kritik on güvenlik riskinin uzlaşıya dayalı listesidir. En güncel kararlı sürüm 2021'dir; 2021'de üç yeni kategori (A04 Insecure Design, A08, A10 SSRF) eklenmiş ve diğerleri yeniden düzenlenmiştir. OWASP, 2025'te daha yeni bir baskı duyurmuştur; ancak kararlı atıf için testlerimizi 2021 listesine dayandırır ve 2025'i yeni baskı olarak anarız. Top 10 bir test kontrol listesi değil, risk haritasıdır. Bir uygulamanın "OWASP Top 10'a karşı test edildi" denmesi tek başına yeterli değildir; asıl metodoloji OWASP Web Security Testing Guide'dır (WSTG), uygulama ve servislerin güvenliğini test etmek için dünyanın fiilen kullandığı açık kaynak rehber.

Top 10'un değeri, mühendislik ekibiyle ortak bir dil kurmasıdır. Bir bulgu "A01 Broken Access Control" olarak etiketlendiğinde, geliştirici riskin sınıfını, neden önemli olduğunu ve nereye bakacağını anında anlar. Bu ortak dil, raporun rafa kalkmadan düzeltmeye dönüşmesini sağlar.

Metodoloji: testin altı fazı

Sağlam bir web uygulaması sızma testi gelişigüzel "deneme yanılma" değil, yapılandırılmış bir süreçtir. WSTG'nin başlıkları altında biz testi altı fazda yürütürüz.

  1. Bilgi toplama ve haritalama. Uygulamanın tüm sayfaları, parametreleri, API uçları, gizli dizinleri ve teknolojileri çıkarılır. Saldırı yüzeyi bilinmeden test eksik kalır.
  2. Kimlik doğrulama ve oturum yönetimi testi. Giriş akışı, parola sıfırlama, oturum belirteçlerinin üretimi ve geçersiz kılınması, çok faktörlü doğrulama ve "beni hatırla" mekanizmaları sınanır.
  3. Yetkilendirme testi. Bir kullanıcının yetkisi olmayan veriye ya da işleve ulaşıp ulaşamadığı; dikey (düşük yetkiden yükseğe) ve yatay (aynı seviyede başka kullanıcının verisine) yetki atlama denenir.
  4. Girdi doğrulama testi. Injection (SQL, komut, şablon), XSS ve diğer girdi temelli zafiyetler aranır.
  5. İş mantığı testi. Uygulamanın iş kurallarının (örneğin bir indirim kodunun tekrar kullanımı, bir siparişin negatif tutarla verilmesi) suistimali sınanır. Bu, otomatik araçların göremediği, en değerli aşamadır.
  6. Raporlama ve yeniden test. Bulgular çalıştırılabilir kanıtla, risk derecesiyle ve net düzeltme adımıyla sunulur; düzeltme sonrası retest ile kapatma doğrulanır.

En sık istismar edilen zafiyetler

A01 Broken Access Control ve IDOR

OWASP Top 10 2021'de birinci sıradaki risk, bozuk erişim kontrolüdür: bir kullanıcının yetkisi olmayan veriye ya da işleve ulaşabilmesidir. En yaygın biçimi IDOR'dur (Insecure Direct Object Reference): bir istekteki nesne kimliğini (örneğin /hesap/1004 yerine /hesap/1005) değiştirerek başkasının verisine erişmek. Tipik bir saldırı akışı şudur: testçi kendi hesabıyla bir faturayı görüntüler, isteğin içindeki fatura numarasını artırır ve başka bir müşterinin faturasını görür. Bu zafiyetler otomatik tarayıcıların en sık kaçırdığıdır, çünkü uygulamanın iş bağlamını ve kimin neye erişmesi gerektiğini bilmek gerekir; ancak elle test bulur. Savunma, her istekte sunucu tarafında "bu kullanıcı bu nesneye erişebilir mi" kontrolünü yapmaktan geçer.

A03 Injection: SQL Injection ve XSS

2021'de Injection kategorisi, ayrı bir kategori olan XSS'i de içine almıştır. SQL injection, kullanıcı girdisinin doğrudan veritabanı sorgusuna katılmasıyla saldırganın sorguyu manipüle edip veri çekmesi ya da değiştirmesidir; uç durumda tüm veritabanını dışa aktarmaya ya da kimlik doğrulamayı atlamaya götürebilir. Cross-Site Scripting (XSS), saldırganın bir web sayfasına çalıştırılabilir betik enjekte edip diğer kullanıcıların tarayıcısında çalıştırmasıdır; oturum çerezi çalma, sahte form gösterme ve hesap devralmaya yol açabilir. İkisi de PortSwigger Web Security Academy'de etkileşimli olarak belgelenmiştir. SQL injection parametreli sorgular (prepared statements) ile, XSS ise bağlama duyarlı çıktı kodlama ve içerik güvenlik politikası (CSP) ile önlenir.

A10 Server-Side Request Forgery (SSRF)

SSRF, saldırganın uygulamayı kandırıp sunucu adına istek yaptırmasıdır. Özellikle bulut ortamlarında tehlikelidir: saldırgan, uygulamayı bulut sağlayıcının iç meta veri uç noktasına istek yaptırarak geçici kimlik bilgilerini sızdırabilir ve oradan tüm bulut hesabına yayılabilir. 2021'de Top 10'a giren bu kategori, bulut mimarilerinin yaygınlaşmasıyla kritikleşmiştir. Savunma, çıkış isteklerini beyaz liste ile sınırlamak ve iç ağ adreslerine erişimi engellemekten geçer; bulut tarafı için bulut güvenlik denetimi yazımıza bakın.

A07 Identification and Authentication Failures

Zayıf parola politikaları, kusurlu oturum yönetimi, kırılabilir şifre sıfırlama akışları ve çok faktörlü doğrulama eksikliği bu kategoridedir. Sızma testinde kimlik doğrulama akışı ayrıntılı sınanır: oturum belirteçleri tahmin edilebilir mi, çıkıştan sonra geçersiz kılınıyor mu, parola sıfırlama tokenı yeniden kullanılabiliyor mu, hesap kilitleme var mı, kaba kuvvet ve kimlik bilgisi doldurma saldırılarına karşı koruma var mı. Bu zafiyetler doğrudan hesap devralmaya götürdüğü için kritiktir.

A05 Security Misconfiguration ve A06 Vulnerable Components

Yanlış yapılandırma (açık yönetim panelleri, varsayılan kimlik bilgileri, ayrıntılı hata mesajları, gereksiz açık servisler) ve güncel olmayan, bilinen zafiyetli bileşenler, çoğu testin en bol bulgu üreten alanlarıdır. Bir kütüphanenin tek bir güncel olmayan sürümü, bilinen bir CVE üzerinden uzaktan kod çalıştırmaya götürebilir. Yazılım tedarik zinciri ve bileşen güvenliği için kaynak kodu güvenlik denetimi (SAST, DAST, SCA) yazımıza bakın.

Metodolojinin temeli: WSTG ve ASVS

OWASP Web Security Testing Guide (WSTG), bilgi toplama, kimlik doğrulama testi, oturum yönetimi testi, yetkilendirme testi, girdi doğrulama testi ve iş mantığı testi gibi başlıklarla yapılandırılmış, sızma testçilerinin dünya çapında kullandığı fiili metodolojidir; en güncel kararlı sürümü 4.2'dir. OWASP ASVS (Application Security Verification Standard) ise teknik güvenlik kontrollerini test etmek ve güvenli geliştirme gereksinimlerini tanımlamak için bir temel sunar; tedarik sözleşmelerinde gereksinim listesi olarak da kullanılır. DSET olarak testlerimizi WSTG başlıkları altında yürütür, bulguları ASVS seviyeleriyle ilişkilendiririz; böylece müşteri yalnızca "şu açık var" değil, "hangi olgunluk seviyesinde eksik var" bilgisini de alır.

Otomatik ve elle test neden birlikte gerekir

Otomatik tarayıcılar (DAST araçları) geniş yüzeyi hızla tarar, bilinen kalıpları yakalar ve regresyon için idealdir. Bilinen XSS ve injection kalıplarını, açık yapılandırma hatalarını ve eski bileşenleri hızla bulurlar. Ancak iş mantığı hataları, yetki atlama zincirleri, çok adımlı hesap devralma ve bağlama bağlı IDOR gibi zafiyetleri kaçırırlar, çünkü uygulamanın ne yapması gerektiğini bilmezler. Bir tarayıcı, "bu kullanıcının bu faturayı görmemesi gerekir" kuralını bilemez; bunu yalnızca uygulamanın iş akışını anlayan bir insan bulur. Elle test, bu boşluğu doldurur: uzman, uygulamanın iş akışını anlayıp insan yaratıcılığıyla zincirler kurar. İkisi birbirinin yerine değil, tamamlayıcısıdır.

Birincil araç: Burp Suite ve KAOS

Burp Suite, PortSwigger'ın web zafiyet tarayıcısı ve araya giren proxy'sidir; web uygulaması sızma testinin endüstri standardı araç setidir. İstekleri yakalar, değiştirir, tekrarlar ve otomatikleştirir; elle testin omurgasıdır. Bir testçi Burp ile bir isteği yakalar, parametreleri tek tek değiştirir, sunucunun tepkisini gözlemler ve zafiyeti adım adım inşa eder. Otonom motorumuz KAOS keşif ve doğrulama tarafında hız katar, geniş yüzeyi tarar ve aday bulguları işaretler; ama her kritik bulguyu insan uzman elle doğrular ve çalıştırılabilir kanıta dönüştürür.

Sık karşılaşılan bulgular

Saha tecrübemizde web uygulamalarında en sık gördüğümüz bulgular şunlardır: yetki kontrolünün yalnızca arayüzde yapılıp sunucuda yapılmaması (gizli bir butonu görmemek, o işlevi çağıramamak anlamına gelmez); parola sıfırlama tokenlarının tahmin edilebilir ya da süresiz olması; oturum belirteçlerinin çıkışta geçersiz kılınmaması; ayrıntılı hata mesajlarının veritabanı yapısını sızdırması; dosya yükleme alanlarının tür ve içerik doğrulaması yapmaması; ve güncel olmayan kütüphaneler. Bu bulguların çoğu tek tek düşük görünse de, zincirlendiğinde hesap devralmaya ya da veri ihlaline götürür.

Bulgular nasıl raporlanır

Her bulgu, çalıştırılabilir bir kanıt (PoC) ve adım adım yeniden üretim ile sunulur; yanlış pozitif elenir. Bu disiplin için doğrulanmış zafiyet ve yanlış pozitifsiz test yazımıza bakın. Rapor, her zafiyet için risk derecesi (örneğin CVSS), iş etkisi ve net düzeltme adımı içerir; ayrıca yöneticiye yönelik sade bir özet ve teknik ekibe yönelik ayrıntılı bir bölüm sunar. Düzeltme sonrası yeniden test (retest) ile kapatma doğrulanır ve kapatma raporu verilir.

Sıkça Sorulan Sorular

Tarayıcı raporu sızma testi midir? Hayır. Otomatik tarama testin bir parçasıdır; iş mantığı ve yetki zafiyetlerini ancak elle test ve insan doğrulaması ortaya çıkarır. Yalnız tarayıcıya güvenmek, en kritik zafiyetleri kaçırmak demektir.

Üretim ortamında mı test edilir? Tercihen kopya (staging) ortamda; üretimde test edilecekse kapsam, zaman penceresi ve veri işleme yazılı olarak belirlenir ve kişisel veriye dokunan testlerde KVKK yükümlülükleri gözetilir. Yasal çerçeve için sızma testi sözleşmesi ve yasal yetkilendirme yazımıza bakın.

Ne sıklıkla yapılmalı? En az yılda bir ve uygulamada önemli değişiklik sonrası; sürekli teslimat yapan ekiplerde her büyük sürümde ya da daha sık.

WAF arkasındaysam yeterince güvende miyim? Hayır. WAF bir koruma katmanıdır ama iş mantığı ve yetki zafiyetlerini durdurmaz; sızma testi WAF'ın arkasındaki gerçek riski ölçer.

Mobil uygulamamın API'si de test edilir mi? Evet, web ve API testleri çoğu zaman birlikte yürür; mobil tarafı için mobil uygulama sızma testi yazımıza bakın.

Kaynaklar

Web uygulamanızın iş mantığını ve yetki katmanını elle sınamak için DSET ile iletişime geçin.