Altay
Siber Vatan

OWASP Top 10:2025 - Red Team Perspektifi ​

Ahmet Faruk Sarıömeroğlu · @afs-0

Emrah Tusun · @EmrahTusun

Barış Gürkan Polat · @barpoll

OWASP Top 10:2025

OWASP Top 10, web uygulamalarında en sık karşılaşılan güvenlik zafiyetlerini sıralayan, düzenli aralıklarla güncellenen bir referans liste. 2025 güncellemesiyle hem sıralama hem de bazı kategorilerin isimleri değişti. Bu yazımızda listedeki 10 kategoriyi Red Team gözüyle ele alıyoruz. Her zafiyetin ne olduğunu, nasıl oluştuğunu ve bir saldırganın bunu nasıl tespit edip istismar edebileceğini anlatıyoruz.

Test Ortamı ve Metodoloji

A01–A04 zafiyetlerini WebVulnLab üzerinde, A05–A09 zafiyetlerini ise Kali Linux üzerindeki DVWA (Damn Vulnerable Web Application) ortamında test ettik. A05, A07, A08 ve A09 için Security seviyesini Medium, A06 için Low olarak ayarladık.

A01:2025 – Broken Access Control ​

Günümüzde en çok karşımıza çıkan zafiyet olan Broken Access Control, mantıksal bir yetkilendirme zafiyetidir. Bir web sitesinde var olan farklı yetkilendirme seviyeleri için API uç noktalarında yetki kontrolü kodlanmadığı zaman bu zafiyet ortaya çıkar. Mesela admin olarak web sitesindeki gönderilerin silinmesi için belli bir uç nokta kullanıldığını düşünelim. Burada eğer yetkilendirme için kod eklenmediyse, sayfada herhangi düşük yetkilere sahip bir kullanıcı, bu uç noktanın yalnızca ismini bilerek verileri düzgün doldurduğunda istediği gönderiyi silebilir hale gelir. Ayrıca uç nokta isimlerinin ve isteklerde giden verilerin tahmin edilebilir olması, zafiyetin kritikliğini de artırır.

Nasıl Test Ettik / Örnek Senaryo:

Broken Access Control — cookie manipülasyonuyla yetkisiz silme isteği

Ekran görüntüsünde sağ üstte aktif kullanıcı olarak "user" görülüyor. Sayfadaki gönderilerin silinmesi için yetkimiz olmadığı gösterilmiş. Ancak alt taraftaki istek düzenleme ekranındaki cookie değerine DemoUser=admin; DemoRole=Admin yazıldığını görüyoruz. Bu isteği gönderdiğimizde dönen yanıtta gönderinin başarıyla silindiğini görüyoruz. Sayfa yenilendiğinde yalnızca 1 ve 2 ID'lerine sahip gönderiler karşımıza çıkıyor. Burada bir yetki yükseltme senaryosunu örneklemiş olduk.

A02:2025 – Security Misconfiguration ​

Bir servis kurulduktan sonra yapılması gereken konfigürasyonlar vardır. Gereksiz şekilde açık bırakılan ve güvenliği hiçe sayan ayarlar, dış dünyaya açık halde unutulan bulut sunucuları, fazla ayrıntı veren hata mesajları veya sadece varsayılan olarak gelen kullanıcı adı ve parolanın değiştirilmemesi büyük güvenlik riskleri barındırır. Kötü niyetli bir saldırganın sistemlerinizde port taraması yaptığını düşünün. Web portunun açık olduğunu görürse ilk deneyeceği işlem, sistemin varsayılan parolasını internetten bulmak ve burada denemek olacaktır. Küçük bir ihmal, internetteki tanımadığınız kişilerin sistemlerinize yetkisiz yönetici erişimi elde etmesine imkan tanıyabilir.

Nasıl Test Ettik / Örnek Senaryo:

Security Misconfiguration — varsayılan admin:admin girişi

Bir giriş ekranında bize bilgi sorulduğunu görüyoruz. Sistemi ilk defa gören bir saldırgan içgüdüsüyle admin:admin bilgilerini deniyoruz ve giriş başarılı oluyor. Karşımızda tam yetkiye sahip olduğumuz bir arayüz var.

Security Misconfiguration — yetkili yönetim arayüzü

A03:2025 – Software Supply Chain Failures ​

Özellikle 2026 yılında sürekli gündem olan tedarik zinciri saldırılarının riski, dikkatli davranılırsa önemli ölçüde azaltılabilir. Ancak yazılımlar ne kadar karmaşıklaşırsa, bu saldırının bir sistemi etkilemesi de o kadar mümkün hale gelir. Arka planda kullanılan kütüphane bağımlılıklarının herhangi birinde tedarik zinciri saldırısı olursa ve bu durum fark edilmeden önce sistemde tamamen masum görünen bir toplu güncelleme yapılırsa, uzak saldırganların sistemlere erişim elde etmesi veya zararlı yazılım bulaştırması mümkün hale gelir.

Nasıl Test Ettik / Örnek Senaryo:

Software Supply Chain Failures — kötü amaçlı paket güncellemesi

Simülasyonda IT ekibi bir bağımlılığı güncelliyor; ancak bu paketin yeni sürümü daha önce saldırganlar tarafından ele geçirilmiş. Güncellemeden sonra siteyi ziyaret eden her kullanıcının tarayıcısı, saldırganın Command and Control (C2) sunucusuna bağlantı kuruyor.

Software Supply Chain Failures — Command and Control bağlantısı

A04:2025 – Cryptographic Failures ​

Bir sistemdeki şifrelemenin gücü, saldırganın her şeyi apaçık görmesi ile gördüğü hiçbir veriyi anlamlandıramaması arasındaki en büyük etkenlerden biridir. Web sitelerinde belirli aralıklarla yenilenmesi gereken SSL/TLS sertifikaları, TLS versiyonlarının düşük olması veya web sitesinde kritik veriler olmasına rağmen şifresiz HTTP protokolü kullanılması, bu zafiyetin en çok karşımıza çıkan örneklerindendir. Şifreleme olmayan bir web sitesinde, kötü niyetli bir aktörün man-in-the-middle saldırısı ile tüm verilerin ele geçirilmesi oldukça kolaylaşır. Ayrıca düşük versiyon şifreleme algoritmaları da yeterince motivasyona sahip olan bir saldırganın şifreleri çözerek verileri ele geçirmesine yol açabilir.

Nasıl Test Ettik / Örnek Senaryo:

Cryptographic Failures — şifreleme seçenekleri ve trafik izleme

Ekran görüntüsünde bir mesajlaşma arayüzü var. Mesajların hangi şifreleme ile gönderileceğini seçebiliyoruz. Buradaki seçenekler; düz metin, Base64 kodlama ve AES şifreleme olarak verilmiş. Base64 aslında bir şifreleme değil, bir kodlama (encoding) yöntemi; dolayısıyla ilk iki seçenek de şifresiz bir HTTP kanalı üzerinden gönderildiği için tamamen güvensiz. Wireshark kullanan bir saldırgan, aradaki trafiği dinleyebilecek konumda ise tüm yazışmaları izleyebilir. Ancak AES şifreleme seçildiğinde saldırgan bu mesajı çözemez ve tek gördüğü şey anlamsız bir veri olur. Bu da yalnızca anahtarın güvenli biçimde yönetildiği durumda geçerlidir; asıl çözüm iletişimi baştan TLS (HTTPS) ile korumaktır.

A05:2025 – Injection ​

Injection, bir web uygulamasının kullanıcıdan aldığı güvenilmeyen veriyi doğrulamadan veya ayrıştırmadan doğrudan bir komuta veya sorguya katmasıyla ortaya çıkan bir zafiyet türü. Normalde bir form alanına yazdığımız şey sadece "veri" olarak işlenmesi gerekirken, uygulama bunu ayırt etmeden arka planda çalışan bir komutun parçası haline getiriyor. Bu da kullanıcının, aslında hiç yetkisi olmayan bir şekilde sistemin davranışını değiştirebilmesine yol açıyor. Web güvenliğinde en eski ve en çok bilinen zafiyet türlerinden biri olmasına rağmen hâlâ güncelliğini koruyor, çünkü her yeni teknoloji (yeni bir veritabanı türü, yeni bir template motoru, yeni bir API yapısı) beraberinde kendi injection riskini de getiriyor.

En bilinen türü SQL Injection. Bir giriş formuna ya da arama kutusuna yazılan veri, filtrelenmeden veritabanı sorgusuna eklenirse saldırgan bu sorgunun mantığını değiştirebilir, normalde görmemesi gereken verileri çekebilir ya da veritabanını değiştirebilir.

Komut Enjeksiyonu (Command Injection) ise uygulamanın, kullanıcıdan aldığı bir veriyi işletim sistemi seviyesinde bir komuta eklediği durumlarda ortaya çıkıyor. Mesela bir ağ aracı, kullanıcıdan aldığı bir IP adresini doğrudan bir ping komutuna ekliyorsa, kullanıcı IP yerine ek bir komut yazarak sunucuda istediği komutu çalıştırabilir.

LDAP Injection, kurumsal sistemlerde kullanıcı doğrulaması için kullanılan dizin servislerine (Active Directory gibi) gönderilen sorguların manipüle edilmesiyle oluşuyor.

Template Injection ise daha modern bir tür; web uygulamaları sayfaları dinamik oluşturmak için şablon motorları kullanıyor, eğer kullanıcı girdisi bu şablonun içine doğrudan işleniyorsa saldırgan şablon motorunun kendi komutlarını çalıştırabiliyor.

Hepsinin ortak noktası aynı: uygulama, "bu veri" ile "bu komut" arasındaki sınırı net çizmemiş.

Bir saldırgan bir uygulamaya baktığında önce veri girilen her noktayı (form alanları, URL'deki parametreler, arama kutuları, giriş ekranları, hatta bazen HTTP header'ları) potansiyel bir giriş noktası olarak görür. İlk yapılan şey genelde basit: alana tek bir özel karakter (', ", ; gibi) yazıp ne olduğuna bakmak. Eğer uygulama hata verirse, bu genelde girdinin filtrelenmeden bir yere (çoğunlukla veritabanı sorgusuna) iletildiğinin işareti.

Hata mesajının içeriği de çok şey söylüyor. Bazı uygulamalar hatada kullandığı veritabanı türünü, hatta sorgunun bir kısmını olduğu gibi ekrana basıyor. Bu, saldırgana sorgunun yapısını anlama konusunda büyük avantaj sağlıyor.

Eğer hata görünmüyorsa, saldırgan sayfanın davranışına bakar: normalde dönmeyecek bir sonuç dönüyor mu, sayfa yükleme süresi değişiyor mu, farklı girdilerle farklı davranışlar oluyor mu. Bu tür "görünmeyen" sinyaller üzerinden de zafiyet tespit edilebiliyor.

Nasıl Test Ettik / Örnek Senaryo:

Security seviyesini Medium'a aldık, böylece basit bir tırnak (') ile filtrelenen girdiyi aşmamız gerekti. SQL Injection sayfasında Burp Suite ile isteği yakalayıp id parametresini 1 OR 1=1 olarak değiştirdik. Normalde tek kullanıcı dönmesi gereken sorgu, bu haliyle tablodaki tüm kullanıcıları döndürdü; bu da WHERE koşulunun tamamen anlamsızlaştığını gösteriyor.

SQL Injection — OR 1=1 bypassBurp'te değiştirilen istek (id=1 OR 1=1) ve DVWA'nın döndürdüğü tüm kullanıcı listesi.

Bu basit bypass bile gösteriyor ki filtreleme eksikse, uygulamanın en temel sorgu mantığı bile dışarıdan manipüle edilebiliyor.

A06:2025 – Insecure Design ​

Insecure Design, 2025 listesinde 4. sıradan 6. sıraya geriledi ama bu, sektörün tehdit modellemesine daha çok önem vermesinden kaynaklanıyor, zafiyetin önemsizleştiğinden değil. Diğer OWASP kategorilerinin çoğu "kod yanlış yazılmış" diyor, bu kategori ise daha köklü bir şeyi anlatıyor: kodun kendisi doğru yazılmış olsa bile, tasarımın baştan yanlış kurulmuş olması. Yani geliştirici hatasız kod yazmış olabilir ama o kodun arkasındaki mantık zaten savunmasız kurgulanmış.

En klasik örneği, iş mantığı (business logic) zafiyetleri. Mesela bir e-ticaret sitesinde sepete negatif sayıda ürün eklenebiliyorsa ve sistem bunu hesaplarken "tutar - X" işlemi yapıyorsa, kullanıcı fiyatı eksiye düşürebilir. Kod hatasız çalışıyor, çünkü matematiksel olarak doğru işlem yapılıyor ama tasarım "kullanıcı negatif değer girebilir mi" sorusunu hiç sormamış.

Bir başka örnek, şifre sıfırlama akışlarında rate-limit olmaması. Teknik olarak her şey çalışıyor ama tasarım, bir saldırganın aynı işlemi binlerce kez deneyebileceğini öngörmemiş.

Yetki seviyeleri arasındaki geçişlerin net tanımlanmaması da bu kategoriye giriyor: "misafir kullanıcı ne yapabilir, üye ne yapabilir" ayrımı net çizilmemişse, sistem teknik olarak sağlam görünse bile mantıksal boşluklar bırakıyor.

Bu zafiyet türü diğerlerinden farklı, çünkü tek bir payload yazıp "işte açık" demek mümkün değil. Saldırgan burada uygulamanın akışını baştan sona adım adım takip eder ve her adımda kendine şunu sorar: "Burada olmaması gereken bir girdi ya da sıra denersem ne olur?" Form alanlarına normalde beklenmeyen değerler (negatif sayı, aşırı büyük sayı, boş değer), işlem sırasını değiştirmek (ödeme onayından önce teslimat adımını atlamak gibi), ya da bir işlemi normalden fazla tekrarlamak (brute force, aynı kuponu art arda kullanmaya çalışmak) bu tür zafiyetleri ortaya çıkarmanın tipik yolları.

DVWA'daki Insecure CAPTCHA modülü buna iyi bir örnek, çünkü sunucu tarafı CAPTCHA doğrulamasını düzgün kontrol etmiyor.

Nasıl Test Ettik / Örnek Senaryo:

Parola değiştirme formunu doldurup CAPTCHA'yı bir kez çözdük. Burp Repeater ile isteği tekrar gönderdiğimizde, sunucunun aynı CAPTCHA yanıtını (g-recaptcha-response) tekrar tekrar kabul ettiğini gördük; yani CAPTCHA token'ı sunucu tarafında gerçek zamanlı doğrulanmıyor, sadece alanın dolu olup olmadığına bakılıyor. Bu yüzden aynı isteği tekrar göndererek parolayı tekrar değiştirebildik.

Insecure CAPTCHA — normal akışInsecure CAPTCHA — token tekrar kullanımıBurp Repeater'da tekrar gönderilen istek ve "Password Changed." başarı mesajı.

Burada kırılan şey bir filtre değil, akışın tasarımı: CAPTCHA'nın "her işlemde yeniden doğrulanması" gerektiği hiç düşünülmemiş.

A07:2025 – Authentication Failures ​

Authentication Failures, 2025 listesinde 7. sırada; pozisyonu 2021'den beri değişmedi, sadece ismi "Identification and Authentication Failures"tan sadeleşti. Bu kategori, bir uygulamanın "sen gerçekten kimsin" sorusunu doğru şekilde cevaplayamaması durumunu kapsıyor. Yani saldırganın, gerçek bir kullanıcının kimliğine bürünmesini kolaylaştıran her türlü zayıflık burada değerlendiriliyor.

En yaygın hali, zayıf parola politikaları. Sistem kullanıcıya "123456" gibi bir parola girmesine izin veriyorsa, parola ne kadar gizli tutulursa tutulsun pratik bir koruma sağlamıyor.

Oturum yönetimi hataları da büyük bir alt başlık: kullanıcı çıkış yaptıktan sonra session token'ının geçersiz kılınmaması, ya da aynı token'ın tarayıcı kapatılsa bile sürekli geçerli kalması gibi durumlar, saldırganın ele geçirdiği bir token'ı uzun süre kullanabilmesine yol açıyor.

Giriş denemelerinde limit olmaması da (brute force koruması eksikliği) bu kategoriye giriyor: saldırgan otomatik araçlarla binlerce parola denemesi yapabiliyorsa, zayıf bir parola er ya da geç bulunuyor.

Burada ilk bakılan şey, giriş formunun davranışı. Yanlış kullanıcı adı girildiğinde mi, yanlış parola girildiğinde mi farklı hata mesajı dönüyor? Eğer öyleyse, saldırgan bu farktan hangi kullanıcı adlarının sistemde gerçekten var olduğunu anlayabiliyor (user enumeration).

İkinci adım genelde aynı hesaba art arda birçok yanlış parola denemektir; eğer sistem belirli bir sayıdan sonra hesabı kilitlemiyor ya da gecikme uygulamıyorsa, bu otomatik denemeye açık demektir.

Oturum tarafında ise, giriş yaptıktan sonra alınan token'ın tarayıcı geçmişinde, URL'de ya da kolay tahmin edilebilir bir yapıda olup olmadığına bakılır; token tahmin edilebilirse ya da başka bir kullanıcıyla paylaşılan bir değer taşıyorsa, kimliğe bürünme mümkün hale geliyor.

Nasıl Test Ettik / Örnek Senaryo:

DVWA'nın Brute Force sayfasında kullanıcı adını admin olarak sabit tutup, Burp Intruder ile bir parola listesini tek tek denettik. Sonuç listesinde diğer tüm denemeler aynı yanıt uzunluğunu verirken, password payload'ı farklı bir uzunlukta (4683 bayt, diğerleri 4645) yanıt döndürdü; bu fark, doğru parolanın bulunduğunun işareti. O parolayla normal girişi de doğruladık.

Brute Force — Intruder sonucuIntruder'da farklı yanıt uzunluğuyla ayırt edilen doğru parola ve başarılı giriş ekranı.

Sistemin başarısız denemelere karşı herhangi bir gecikme ya da kilitleme uygulamaması, otomatik denemeyi pratikte sınırsız hale getiriyor.

A08:2025 – Software or Data Integrity Failures ​

Bu kategori 2025'te de 8. sırada, pozisyonu değişmedi. Konusu, bir uygulamanın kullandığı kodun, güncellemenin ya da verinin gerçekten beklenen kaynaktan geldiğini ve değiştirilmediğini doğrulayıp doğrulamadığı. Yani "bu dosya/güncelleme/veri güvenilir mi" sorusunun hiç sorulmadığı ya da yanlış cevaplandığı durumlar burada toplanıyor.

En bilinen örneği tedarik zinciri saldırılarıyla iç içe geçiyor: bir uygulama güncellemelerini imzasını doğrulamadan indirip çalıştırıyorsa, araya giren bir saldırgan sahte bir güncelleme paketi verebilir ve uygulama bunu meşru sanıp çalıştırır.

İkinci yaygın örnek güvensiz deserialization. Bazı uygulamalar, kullanıcı bilgisi gibi bir nesneyi metne çevirip (serileştirme) örneğin bir cookie içinde tarayıcıya gönderiyor; kullanıcı sonraki isteklerde bu cookie'yi geri yolluyor ve uygulama onu tekrar nesneye çeviriyor (deserialization). Sorun şu ki cookie kullanıcının kontrolündedir ve istenildiği gibi değiştirilebilir. Uygulama bu veriyi doğrulamadan geri açarsa, saldırgan içindeki değerleri (örneğin rolünü admin olarak) değiştirebilir; PHP, Java veya Python pickle gibi ortamlarda ise geri açma sırasında sunucuda kod çalıştıracak bir nesne yerleştirebilir.

CI/CD hattındaki zayıflıklar da buraya giriyor: derleme sürecine kimin erişimi olduğu kontrol edilmiyorsa, kötü niyetli biri kod derlenmeden önce araya zararlı bir adım ekleyebilir.

Saldırgan burada genelde "bu veri nereden geliyor ve doğrulanıyor mu" sorusuna odaklanır. Bir cookie ya da gizli form alanı içinde şifrelenmemiş, encode edilmiş bir veri (base64 gibi) görürse, bunu decode edip içeriğini inceler; çünkü bu genelde serileştirilmiş bir nesne olabilir ve doğrudan değiştirilip tekrar gönderilebilir.

Güncelleme mekanizmaları varsa, güncelleme dosyasının indirileceği adresin HTTP mi HTTPS mi olduğuna, imza kontrolü yapılıp yapılmadığına bakılır. İmza doğrulaması yoksa, aradaki trafiği değiştirerek sahte bir dosya verilebilir mi diye test edilir.

DVWA'nın File Upload modülünde gördüğümüz zafiyet dar anlamda bir girdi doğrulama sorunu gibi görünse de, aynı kökten geliyor: sunucu, yüklenen dosyanın gerçek içeriğinin bütünlüğünü ya da imzasını hiç doğrulamadan, yalnızca istemcinin beyan ettiği Content-Type üst verisine (metadata) güveniyor. Yani dosyanın "iddia ettiği şey" ile "gerçekte ne olduğu" arasındaki bütünlük hiç kontrol edilmiyor — bu da temelde A08'in anlattığı güven sorununun küçük ölçekli bir örneği.

Nasıl Test Ettik / Örnek Senaryo:

İçeriği <?php echo "test"; ?> olan bir test.php dosyası hazırladık. Yükleme isteğini Burp'te yakalayıp Content-Type alanını image/jpeg olarak değiştirdik (dosya adı test.php olarak kaldı). Sunucu, sadece bu başlığa bakarak dosyayı resim sandı ve kabul etti; test.php dosyası /hackable/uploads/ klasörüne yüklendi.

File Upload — Content-Type bypassBurp'te değiştirilen Content-Type: image/jpeg başlığı ve "succesfully uploaded!" mesajı.

Dosya türünü sadece tarayıcının beyan ettiği bir başlığa göre belirlemek, saldırganın bu başlığı istediği gibi değiştirebilmesi yüzünden gerçek bir kontrol sağlamıyor.

A09:2025 – Security Logging and Alerting Failures ​

Bu kategori de 2025'te 9. sırada sabit kaldı, ama ismi değişti: eskiden "Monitoring" (izleme) derken artık "Alerting" (uyarı) deniyor. Bunun sebebi basit: bir sistemin her şeyi loglaması tek başına bir işe yaramıyor, eğer o loglardaki anormal bir durum birine bildirilmiyorsa. Yani konu sadece "kayıt tutuyor muyuz" değil, "tutulan kayıt bir insana zamanında ulaşıyor mu" sorusu.

En yaygın hali, giriş denemelerinin loglanmaması. Bir saldırgan bir hesaba yüzlerce kez yanlış parola deniyorsa ve bu hiçbir yerde kayıt altına alınmıyorsa, saldırı tamamen görünmez kalıyor.

İkinci tür, loglanıyor ama alarm üretilmiyor durumu. Sistem her girişi kaydediyor olabilir ama "aynı IP'den 1 dakikada 50 başarısız giriş" gibi bir durumda kimseye bildirim gitmiyorsa, log dosyası sadece bir arşiv olarak kalıyor, saldırı anında fark edilmiyor.

Üçüncü tür, kritik olayların (yetki değişikliği, veri silme, admin girişi gibi) ayrı bir önem seviyesiyle işaretlenmemesi: her şey aynı seviyede loglandığında önemli bir olay, binlerce sıradan kayıt arasında kayboluyor.

Bir saldırgan açısından bu zafiyet doğrudan test edilen bir şey değil, daha çok "fark edildim mi" sorusunun cevabı. Saldırgan bilinçli olarak gürültülü bir davranış sergiler: aynı anda birçok farklı payload dener, aynı hesaba art arda başarısız giriş yapar ve sistemin buna herhangi bir şekilde tepki verip vermediğini gözlemler (hesap kilitleniyor mu, IP engelleniyor mu, bir uyarı sayfası çıkıyor mu). Eğer hiçbir tepki gelmiyorsa, bu ortamda loglama ya da alarm mekanizmasının zayıf olduğu anlaşılıyor ve saldırgan daha agresif denemeler yapmaktan çekinmiyor.

Nasıl Test Ettik / Örnek Senaryo:

A05'teki SQLi saldırısını tekrarladıktan sonra sudo tail -n 20 /var/log/dvwa/access.log komutuyla log kaydına baktık. access.log dosyası zaten doğası gereği tüm HTTP isteklerini ham haliyle kaydediyor, içine herhangi bir uyarı etiketi basmıyor; asıl eksiklik burada değil. Gerçek zafiyet, bu kaydın bir SIEM/IDS mekanizması tarafından izlenip SQLi desenini yakalayarak gerçek zamanlı bir alarm üretmemesi. Yani log tutuluyor ama bu log hiçbir zaman bir uyarıya dönüşmüyor.

Logging — uyarısız log kaydı

Saldırının log'a düşmesi tek başına yeterli değil; o logu izleyen ve anlamlandıran bir mekanizma yoksa saldırı fark edilmeden kalır.

A10:2025 – Mishandling of Exceptional Conditions ​

Bu kategori, bir uygulamanın beklenmeyen hata ve istisna (exception) anlarında güvenli bir duruma geçememesiyle ilgili: sistemin hata karşısında varsayılan olarak izin veren bir duruma düşmesi (fail-open), yarım kalan işlemlerin geri alınmaması (rollback eksikliği), kullanılan kaynakların serbest bırakılmaması ve yakalanmayan hataların (unhandled exceptions) kullanıcıya iç sistem bilgisini (stack trace) ifşa etmesi bu kategori altında inceleniyor. Kod yazılırken kullanıcının tetikleyebileceği tüm istisnai durumların düşünülerek hata yönetiminin buna göre kurgulanması, bu tür zafiyetlerin önüne geçecek en önemli unsur.

Örnek Senaryo:

Unhandled exception örneğiKaynak: Microsoft Learn – Processing Unhandled Exceptions

Microsoft'un resmi ASP.NET dokümantasyonundan alınan bu ekran görüntüsü, yakalanmayan istisnaların (unhandled exceptions) kullanıcıya aşırı detaylı hata çıktısı (stack trace) döndürmesine doğrudan bir örnek (CWE-209).

Bu on zafiyeti kırmızı takım gözüyle incelediğimizde ortak bir örüntü görüyoruz: güvenlik açığı çoğu zaman karmaşık bir teknikten değil, uygulamanın bir varsayımı hiç sorgulamamasından doğuyor; örneğin gelen verinin güvenilir olduğu, bir adımın atlanamayacağı ya da bir hatanın kimseye görünmeyeceği varsayımı gibi. Mavi takım tarafının aynı listeyi savunma perspektifinden ele aldığı çalışmayla birlikte okunduğunda, bu açıkların hem nasıl bulunduğunu hem de nasıl kapatılabileceğini bütünsel olarak görmek mümkün.

Kaynakça ​

OWASP Top 10:2025 Red Team İçin Kaynakça