Bak dostum, siber güvenlik aslında bir "Zafiyet Yönetimi" oyunudur. Saldırgan, sizin kapınızı 10 dakikada kıramıyorsa, 5 saatte kırmaya çalışır. 5 saatte kıramıyorsa, 5 gün uğraşır. Eğer 5 günde de kıramazsa, başka bir eve gider. Bu dersimizde, doğrudan zafiyetlerin kendisine odaklanalım. Bu zafiyetler, bir web uygulamasının yapı taşlarındaki hatalardır. Tıpkı bir binanın temelindeki çatlaklar gibi; ne kadar güzel görünürse görünsün, o çatlaklar binayı yıkıma götürür. Sana bu zafiyetleri, en yaygın ve en tehlikeli olanlarından başlayarak, hayatın içinden kısa örneklerle anlatacağım. Bu, OWASP Top 10 listesinin 2025 sürümünü temel alan, güncel bir ders olacak.

1. En Büyük Delik: Yetki ve Erişim Kontrolü Hataları (Broken Access Control)

Bu zafiyet, bir uygulamanın, bir kullanıcının sadece kendi yetkisi dahilindeki işlemleri yapmasını engelleyememesidir. Yani, bir kullanıcı başka bir kullanıcının hesabına girebilir, admin panelini görebilir veya yetkisi olmayan bir işlemi gerçekleştirebilir.

2. En Yaygın Hata: Yanlış Yapılandırma (Security Misconfiguration)

Bu, en sık rastlanan ve genellikle en basit ama en etkili zafiyetlerden biridir. Uygulama sunucusunun, veritabanının veya bulut ayarlarının güvenlik açısından zayıf bırakılmasıdır.

3. En Klasik Saldırı: Enjeksiyon (Injection)

Bu, uygulamanın, kullanıcıdan gelen veriyi bir komut veya sorgu olarak yorumlamasına izin veren zafiyettir. En meşhuru SQL Enjeksiyonu (SQLi)'dur. Saldırgan, arama kutusuna veya giriş formuna özel kodlar yazarak veritabanını kandırır.

4. En Sinsi Tehdit: Cross-Site Scripting (XSS)

Bu zafiyet, saldırganın, başka bir kullanıcının ziyaret ettiği web sayfasına kötü amaçlı bir kod (genellikle JavaScript) enjekte etmesine olanak tanır. Saldırgan, bu kod aracılığıyla kurbanın oturum çerezlerini (cookie) çalabilir, onun adına işlem yapabilir veya onu sahte bir sayfaya yönlendirebilir .

5. En Büyüyen Risk: Yazılım Tedarik Zinciri Zafiyetleri (Supply Chain Failures)

Bu zafiyet, uygulamanın kullandığı üçüncü taraf kütüphaneler, çerçeveler (framework) veya araçlardaki güvenlik açıklarından kaynaklanır. Saldırgan, bu bağımlılıkları hedef alarak milyonlarca uygulamaya sızabilir.

6. Güvensiz Tasarım (Insecure Design)

Bu zafiyet, bir uygulamanın en baştan, mimari aşamasında güvenli düşünülmemesinden kaynaklanır. Bu, bir kod hatası değil, bir tasarım kusurudur. Yani uygulama en baştan "Nasıl saldırılabilir?" sorusu sorulmadan inşa edilmiştir.

  • Hayattan Örnek: Bir binanın yangın merdivenini, yangın çıkış yönetmeliklerine uymadan, sadece "bina güzel görünsün" diye tasarlamak. Yangın çıktığında merdiven çöker.

  • Teknik Karşılığı: Örneğin, bir uygulama, kullanıcıların şifrelerini veritabanında düz metin (plain text) olarak saklayacak şekilde tasarlanmışsa, bu bir tasarım hatasıdır. Veya bir uygulama, tüm kullanıcı verilerini tek bir veritabanı tablosunda toplamış ve "Yetki" kontrolünü tamamen istemci tarafındaki (client-side) JavaScript ile yapıyorsa, bu da güvensiz tasarımdır. Saldırgan, tarayıcıdaki JavaScript'i devre dışı bırakarak admin paneline erişebilir.

Savunma:

  • Threat Modeling (Tehdit Modellemesi) yapılmalıdır. Yani proje başlamadan önce "Buraya kim saldırabilir? Nasıl saldırabilir?" soruları sorulmalıdır.

  • Güvenlik, yazılım yaşam döngüsünün (SDLC) en başına entegre edilmelidir (Shift-Left Security).

  • Varsayılan olarak "güvensiz" kabul edilir. Hiçbir girdiye, hiçbir kullanıcıya güvenilmez (Zero Trust).


7. Kimlik Doğrulama ve Oturum Yönetimi Zafiyetleri (Identification and Authentication Failures)

Bu zafiyet, uygulamanın, bir kullanıcının gerçekten o kişi olduğunu doğrulama (authentication) ve bu doğrulamayı oturum boyunca güvenli tutma (session management) süreçlerindeki hatalardır.

  • Hayattan Örnek: Bir apartmanın girişindeki güvenlik görevlisinin, her gelenin kimliğine bakmadan "Sen tanıdıksın, geç" demesi.

  • Teknik Karşılığı:

    • Brute Force (Kaba Kuvvet): Uygulamanın başarısız giriş denemelerinde bir sınırlama (rate limiting) veya bekleme süresi (captcha) olmaması. Saldırgan, binlerce şifreyi deneyerek hesabı kırabilir.

    • Zayıf Şifre Politikaları: "123456" veya "password" gibi basit şifrelere izin verilmesi.

    • Oturum Çalma (Session Hijacking): Oturum kimliği (Session ID) güvenli olmayan bir şekilde (örneğin URL'de açıkta) taşınırsa, saldırgan bu ID'yi çalarak kullanıcının oturumuna girebilir.

    • Çok Faktörlü Kimlik Doğrulama (MFA) Eksikliği: Tek şifreyle tüm sisteme erişim sağlanması.

Savunma:

  • MFA (İki Adımlı Doğrulama) zorunlu tutulmalıdır.

  • Başarısız giriş denemelerinde hesap geçici olarak kilitlenmeli veya süre gecikmeli olmalıdır (örneğin, 5 başarısız denemeden sonra 15 dakika bekle).

  • Oturum ID'leri, güvenli bir şekilde (HTTPOnly ve Secure flag ile) cookie içinde saklanmalı ve düzenli aralıklarla yenilenmelidir.

  • Şifreler asla düz metin olarak saklanmamalı, bcrypt, Argon2, PBKDF2 gibi güçlü hash algoritmalarıyla tuzlanarak (salting) saklanmalıdır.


8. Yazılım ve Veri Bütünlüğü Zafiyetleri (Software and Data Integrity Failures)

Bu zafiyet, yazılımın veya verinin, üretimden kullanıcıya ulaşana kadar olan süreçte kurcalanmaya karşı korunamamasıdır. Özellikle, uygulamanın güncellemeleri, eklentileri veya bağımlılıkları güvenli olmayan kanallardan indirmesi veya doğrulamaması durumunda ortaya çıkar.

  • Hayattan Örnek: Bir kargo firmasının, gönderdiğiniz kolinin içindekileri kontrol etmeden, güvenmediğiniz bir nakliyeciye teslim etmesi.

  • Teknik Karşılığı:

    • Güncelleme Saldırısı: Uygulama, güncelleme dosyalarını HTTP (şifresiz) üzerinden indiriyorsa, saldırgan bu indirme işlemine müdahale edip, zararlı bir dosya gönderebilir.

    • Dependency Confusion (Bağımlılık Karmaşası): Saldırgan, uygulamanın kullandığı özel bir kütüphanenin aynı isimli, ancak daha yüksek sürüm numaralı, kötü amaçlı bir kopyasını genel bir paket deposuna (örneğin npm, PyPI) yükler. Uygulama, özel depoyu değil de genel depoyu ararsa, bu kötü kütüphaneyi indirir.

    • Deserialization Zafiyeti: Uygulama, güvenilmeyen kaynaklardan gelen serileştirilmiş (serialized) nesneleri, doğrulama yapmadan tekrar nesneye dönüştürürse (deserialization), saldırgan bu nesnelere özel kod enjekte ederek uzaktan komut çalıştırabilir (RCE - Remote Code Execution).

Savunma:

  • Tüm güncellemeler ve bağımlılıklar, yalnızca güvenli (HTTPS) kanallardan indirilmelidir.

  • İndirilen dosyaların bütünlüğü, hash değerleri (SHA-256 gibi) veya dijital imzalar ile doğrulanmalıdır.

  • Yalnızca güvenilen ve doğrulanmış paket depoları kullanılmalıdır.

  • Güvenli deserialization uygulamaları (örneğin, gelen verinin bir beyaz liste ile sınırlandırılması) kullanılmalıdır.


9. Güvenlik Loglama ve İzleme Zafiyetleri (Security Logging and Monitoring Failures)

Bu zafiyet, bir saldırı gerçekleştiğinde veya gerçekleşmeye çalışıldığında, sistemin bunu yeterince kaydetmemesi (log) veya bu kayıtları takip edecek bir mekanizmasının olmamasıdır.

  • Hayattan Örnek: Bir hırsızlık olduktan sonra, iş yerinin güvenlik kamerasının bozuk olduğunun ortaya çıkması. Hırsız rahatça kaçar, kimse bulunamaz.

  • Teknik Karşılığı:

    • Kritik olayların (başarısız girişler, yetki değişiklikleri, önemli veri erişimleri) loglanmaması.

    • Logların yeterince detaylı olmaması (örneğin, sadece "Hata oluştu" yazıp, hangi IP'den, hangi kullanıcıyla, hangi işlem yapıldığını belirtmemesi).

    • Logların güvenliğinin olmaması (saldırgan, sisteme girdikten sonra kendi izlerini loglardan silebilir).

    • Logların düzenli olarak izlenmemesi (SIEM - Security Information and Event Management sistemi yoksa, uyarılar fark edilmez).

Savunma:

  • Tüm kritik işlemler detaylı ve merkezi bir log sistemine (ELK Stack, Splunk vb.) yazılmalıdır.

  • Loglar, yazıldıktan sonra değiştirilemeyecek şekilde (immutable) ve güvenli bir ortamda saklanmalıdır.

  • Anormal durumlar için gerçek zamanlı uyarı sistemleri (alerting) kurulmalıdır. Örneğin, 5 dakika içinde 10 başarısız giriş denemesi olursa, güvenlik ekibine otomatik mail gider.

  • Loglar, sadece saldırı sonrası adli inceleme için değil, proaktif tehdit avcılığı (threat hunting) için de kullanılmalıdır.


10. Sunucu Tarafı İstek Sahteciliği (Server-Side Request Forgery - SSRF)

Bu zafiyet, saldırganın, bir web uygulamasını kullanarak, uygulamanın arka ucundaki (backend) sunucudan, istenmeyen ve genellikle yasaklı yerlere (iç ağ, özel IP'ler, bulut metadata servisleri) istek göndermesine olanak tanır.

  • Hayattan Örnek: Bir otelde, resepsiyon görevlisine "Benim için bir taksi çağır" dersiniz. Ama görevli, sizin için taksi çağıracağına, sizin söylediğiniz bir adrese polis çağırır. Siz "taksi" dediniz, ama o "polis" çağırdı.

  • Teknik Karşılığı: Örneğin, bir web sitesinde, bir resim URL'si girip onu önizleme özelliği vardır. Saldırgan, bu URL alanına http://169.254.169.254/latest/meta-data/ gibi bir adres yazar. Bu adres, bulut sağlayıcılarının (AWS, GCP) sunucularında, o sunucunun kendi gizli kimlik bilgilerini (access key, secret key) sakladığı özel bir adrestir. Uygulama, saldırganın girdiği bu adrese arka taraftan istek gönderirse, bulut sağlayıcısı bu gizli bilgileri geri döndürür ve saldırgan bu bilgilerle tüm bulut hesabını ele geçirebilir. Ayrıca, saldırgan bu şekilde şirketin iç ağındaki (intranet) hassas servislere de erişebilir.

Savunma:

  • Uygulamanın dışarıdan alacağı URL'leri sıkı bir beyaz listeye (whitelist) almak. Sadece belirli, güvenilir domainlere istek göndermesine izin vermek.

  • Kullanıcının girdiği URL'yi doğrudan kullanmak yerine, bir proxy üzerinden yönlendirme yapmak ve bu proxy'de tehlikeli IP aralıklarını (örneğin, 169.254.0.0/16, 127.0.0.0/8 gibi özel IP'ler) engellemek.

  • Uygulamanın çalıştığı sunucunun, bulut metadata servisine erişimini en baştan (firewall veya iptables ile) kapatmak.

Evet Artık 10 büyük zafiyeti de tek tek tanıdık. Peki, bir güvenlik uzmanı olarak bu zafiyetleri nasıl tespit eder ve nasıl kapatırsın? İşte bu noktada iki temel kavram devreye girer: 1. Zafiyet Taraması (Vulnerability Scanning) Nedir? ve 2. Sızma Testi (Penetration Test) Nasıl Yapılır? 3 Dersimizde bu 2 ana başlığı detaylıca öğretmeye çalışacağım, okuduğunuz için teşekkürler.