Güvenli Yazılım Mühendisliği: Tehdit Modelinden Sızma Testine Uygulamalı Siber Güvenlik

Bir sistemi güvenli kılmak, son aşamada birkaç tarama aracı çalıştırmak değildir. Güvenlik; gereksiz güveni kaldırmak, sınırları görünür hâle getirmek, saldırganın ilerleyebileceği yolları daraltmak ve geriye kalan yolları ölçülebilir biçimde denetlemektir.

Giriş: Bayrağı kimden önce göreceğiz?

Siber güvenlik eğitimlerinde saldırı araçları kolay hatırlanır. Nmap ile port taranır, Wireshark ile paket yakalanır, Burp Suite üzerinden HTTP isteği değiştirilir, BloodHound bir Active Directory ortamındaki ilişkileri graf hâline getirir, Metasploit bir güvenlik açığının nasıl istismar edilebildiğini gösterir. Araçların somut çıktı üretmesi öğreticidir; ilk başarı duygusu da çoğu zaman buradan gelir. Fakat bir yazılımı gerçekten güvenli kılmak için araçların gerisindeki ortak soruyu görmek gerekir: saldırgan hangi varsayımımızdan yararlandı?

Uzun süre farklı saldırı ve savunma teknikleriyle çalışınca birbirinden bağımsız görünen açıkların aynı birkaç tasarım hatasına geri döndüğü fark edilir. SQL injection ile işletim sistemi komut enjeksiyonu farklı yorumlayıcılara yönelir ama ikisinde de veri ile komut arasındaki sınır kaybolmuştur. IDOR/BOLA ile hatalı dosya erişimi farklı kaynakları hedefler ama ikisinde de nesne üzerindeki yetki doğrulanmamıştır. Kerberoasting, fazla yetkili servis hesabı ve zayıf parola ilk bakışta üç ayrı konu gibi görünür; saldırı zincirinde ise aynı kimliğin hem kolay ele geçirilebilir hem de gereğinden fazla etkili olması tek bir mimari probleme dönüşür. XSS yalnız JavaScript meselesi değildir; güvenilmeyen verinin çalıştırılabilir bir bağlama taşınmasıdır. Güvensiz tersine serileştirme de benzer biçimde veriye, nesne oluşturma ve kimi zaman kod çalıştırma yeteneği kazandırır.

Bu ders notunda güvenliği saldırı isimlerini ezberleyerek değil, bu ortak nedenleri izleyerek ele alacağım. Amaç bir saldırı kataloğu oluşturmak değildir. Beyaz şapkalı hacker bakışını yazılım ve siber güvenlik mühendisliğiyle birleştirip bir sistemi tasarımdan işletime kadar savunulabilir hâle getirmektir.

CTF terminolojisiyle bir bayrağımız var. Fakat bu kez hedef saldırganın bayrağı alması değil; sistemin hangi aşamada saldırı zincirini kırdığını kanıtlamak. Bunun için hayalî fakat gerçekçi bir sistem düşünelim:

İnternet
   |
Ters Vekil / API Geçidi
   |
Web / Mobil İstemci ---- Kimlik Sağlayıcı
   |                         |
Uygulama API'si -------- Yetkilendirme
   |
Veritabanı ---- Dosya Deposu ---- Mesajlaşma / Harici Servisler
   |
İşletim Sistemi / Konteyner / Sanal Makine
   |
Kurumsal Ağ ---- Active Directory / DNS / SIEM

Bu yapının tek bir “güvenlik duvarı” yoktur. Her ok bir veri akışı, her bileşen bir varlık, her kimlik bir ayrıcalık kümesi, her protokol bir güven sınırı, her dış bağımlılık yeni bir saldırı yüzeyidir. Savunmanın seviyesi, en pahalı güvenlik ürününün gücüyle değil bu sınırların ne kadar doğru kurulduğuyla belirlenir.

Bu yaklaşım güncel çerçevelerle de uyumludur. OWASP Top 10:2025 yalnız klasik enjeksiyon ve kimlik doğrulama hatalarını değil; bozuk erişim denetimini, güvenlik yanlış yapılandırmalarını, yazılım tedarik zinciri başarısızlıklarını, güvensiz tasarımı, bütünlük problemlerini, yetersiz loglama ve alarm üretimini ve istisnai durumların hatalı ele alınmasını da en kritik web uygulaması riskleri arasında sayar. NIST Secure Software Development Framework (SSDF) güvenliği yazılım geliştirme yaşam döngüsüne eklenen bir son kontrol değil, sürecin içine yerleşen bir mühendislik pratiği olarak ele alır. NIST Cybersecurity Framework 2.0 ise yönetişimden kurtarmaya kadar daha geniş bir kurumsal çevrim kurar. Bu notta standartları birer kontrol listesi olarak değil, uygulamada gördüğümüz problemlerin düzenli bir dile çevrilmiş hâli olarak kullanacağız.

1. Güvenlik bir özellik değil, sistem davranışıdır

Bir kullanıcı formunun yanında kilit simgesi bulunması güvenlik değildir. TLS kullanmak da tek başına güvenlik değildir. Çok faktörlü kimlik doğrulama, güvenlik duvarı, antivirüs, EDR, WAF veya SIEM de tek başına güvenli sistem üretmez. Bunların her biri belirli bir tehdide karşı belirli varsayımlar altında çalışan kontrollerdir.

Güvenliği bir sistem davranışı olarak tanımlamak daha kullanışlıdır. Sistem istenen işi yaparken yetkisiz aktörün istemediğimiz sonucu üretmesini engelleyebiliyor mu? Engelleyemediği davranışı yeterince erken görebiliyor mu? Bir ihlal olduğunda hasarı sınırlayabiliyor ve güvenilir duruma dönebiliyor mu?

Klasik gizlilik, bütünlük ve erişilebilirlik üçlüsü hâlâ iyi bir başlangıçtır:

• Gizlilik, bilgiyi yalnız yetkili tarafların görebilmesini ister.
• Bütünlük, verinin ve işlemin yetkisiz biçimde değiştirilememesini ister.
• Erişilebilirlik, yetkili kullanıcının hizmete ihtiyaç duyduğu anda erişebilmesini ister.

Gerçek sistemde bunlara kimlik doğruluğu, inkâr edememe, izlenebilirlik, mahremiyet ve emniyet gibi özellikler eklenebilir. Kritik nokta, bunların soyut sözcük olarak kalmamasıdır. “Müşteri verisinin gizliliği önemlidir” gereksinimi test edilemez. “A kullanıcısı B kullanıcısının kaydını doğrudan nesne kimliği değiştirerek okuyamamalıdır” ise test edilebilir. Güvenlik gereksinimini test edilebilir hâle getirdiğimiz anda mühendislik başlamış olur.

1.1 Varlık, tehdit, güvenlik açığı ve risk

Bu kavramları birbirine karıştırmak yanlış önceliklendirmeye yol açar.

Bir varlık, korunması gereken şeydir: veri, hesap, anahtar, kaynak kodu, işlem kapasitesi, itibar, hizmet sürekliliği veya fiziksel süreç olabilir. Tehdit, bu varlığa zarar verme potansiyeli taşıyan durum veya aktördür. Güvenlik açığı, tehdidin kullanabileceği zayıflıktır. Risk ise bağlama göre olasılık ve etkinin birlikte değerlendirilmesidir.

Aynı güvenlik açığının riski iki sistemde aynı değildir. İnternetten erişilemeyen, ayrı bir ağda çalışan ve yalnız düşük yetkili deneme verisi tutan bir servis ile internete açık, kritik kimlik verisine erişen servis aynı CVSS puanına sahip bir açığı taşısa bile operasyonel riskleri farklıdır. Bu nedenle yalnız tarayıcı skoruyla güvenlik yönetmek, sistem bağlamını kaybetmektir.

1.2 Saldırı zinciri ve bileşik risk

Üretim sistemlerinde en tehlikeli olaylar çoğu zaman “kritik” etiketi taşıyan tek bir açıktan doğmaz. Birkaç orta düzey zayıflık birleşir:

Gereksiz bilgi sızıntısı
        -> kullanıcı adlarının öğrenilmesi
        -> parola püskürtme için hedef listesi
        -> düşük yetkili hesabın ele geçirilmesi
        -> yanlış dosya paylaşımı yetkisi
        -> yapılandırma dosyasından servis parolası
        -> fazla yetkili servis hesabı
        -> etki alanında yanal hareket

Her adım tek başına “sistemi ele geçirmek” anlamına gelmez. Fakat saldırgan graf üzerinde yol arar. BloodHound'un Active Directory ortamında güçlü olmasının nedeni de budur: tekil nesneleri değil ilişkileri görünür kılar. Güvenli tasarımın amacı yalnız açık sayısını azaltmak değil, saldırganın başlangıç noktasından kritik varlığa ulaşabileceği yolları kesmektir.

Bu düşünceyi uygulamanın tamamına yayacağız.

2. Önce sınırı çizmek: neyi test ediyoruz, neyi koruyoruz?

Sızma testinde ilk ciddi hata teknik değil, kapsam hatasıdır. Yetkili test ile izinsiz saldırı arasındaki çizgi yalnız niyetten ibaret değildir; kapsam, zaman, veri, yöntem ve durdurma koşulları açık olmalıdır. Bir CTF laboratuvarında her hedef test edilebilir. Üretim sisteminde aynı serbestlik yoktur.

Bir güvenlik çalışmasına başlamadan önce en az şu bilgiler belirlenmelidir:

| Alan | Sorulması gereken soru | |---|---| | Varlık | Hangi sistem, veri ve hizmet korunuyor? | | Sahiplik | Teknik ve iş sahibi kim? | | Kapsam | Hangi IP, alan adı, uygulama, API, istemci ve hesap test kapsamında? | | Hariç tutulanlar | Kesintiye uğramaması gereken sistemler hangileri? | | Veri | Gerçek veri kullanılabilir mi, maskeleme gerekir mi? | | Test türü | Kod inceleme, mimari inceleme, sızma testi, kırmızı takım, yapılandırma denetimi? | | Zaman | Yük ve kesinti riski olan testler ne zaman yapılabilir? | | Kanıt | Hangi loglar, ekran görüntüleri veya örnek kayıtlar tutulacak? | | Durdurma | Veri kaybı, performans bozulması veya beklenmeyen yayılım olduğunda ne yapılacak? | | İletişim | Kritik bulgu veya kesinti durumunda kim bilgilendirilecek? |

Bu çalışma yalnız hukuki güvence sağlamaz. Teknik sonucu da iyileştirir. Kapsam bilinmiyorsa varlık envanteri eksik kalır; envanter eksikse saldırı yüzeyi bilinmez; saldırı yüzeyi bilinmiyorsa risk değerlendirmesi yalnız tahmindir.

3. Varlık envanteri: bilmediğiniz sistemi koruyamazsınız

Güvenlik ekibinin göremediği sunucu saldırgan için görünmez değildir. Unutulmuş bir alt alan adı, eski test servisi, internete açık yönetim paneli, artık kullanılmayan VPN hesabı, eski mobil API sürümü veya terk edilmiş bir nesne depolama alanı sık rastlanan başlangıç noktalarıdır.

Bu nedenle güvenli kılma algoritmasının ilk teknik adımı envanterdir. CIS Controls v8.1'in ilk iki kontrolünün kurumsal ve yazılım varlıklarının envanterine ayrılması tesadüf değildir.

3.1 Envanter yalnız sunucu listesi değildir

Aşağıdakilerin her biri ayrı bir varlık sınıfıdır:

• fiziksel ve sanal sunucular,
• istemciler ve mobil cihazlar,
• ağ cihazları ve kablosuz erişim noktaları,
• alan adları, alt alan adları, DNS kayıtları ve sertifikalar,
• API'ler ve sürümleri,
• veritabanları ve veri kümeleri,
• servis hesapları, kullanıcılar, gruplar ve roller,
• kriptografik anahtarlar, sertifikalar ve diğer sırlar,
• kaynak kodu depoları,
• derleme sistemleri ve CI/CD çalışanları,
• üçüncü taraf kütüphaneler ve işletim sistemi paketleri,
• konteyner imajları,
• log kaynakları,
• yedekler,
• SaaS veya dış servis entegrasyonları,
• Active Directory nesneleri ve güven ilişkileri.

Özellikle servis hesabı ve makine kimliği envanteri çoğu projede insan kullanıcı envanterinden daha zayıftır. Oysa bir saldırgan için parolası yıllardır değişmeyen ve yüksek yetkili bir servis hesabı, güçlü MFA kullanan insan hesabından daha çekici olabilir.

3.2 Veri sınıflandırma

Her veri aynı korunma düzeyini gerektirmez. Şema tasarımından loglamaya kadar birçok karar, verinin niteliğini bilmeden doğru verilemez.

Pratik bir sınıflandırma şu sorularla başlar:

1. Bu veri ifşa olursa kim zarar görür?
2. Değiştirilirse sistem hangi yanlış kararı verir?
3. Kaybolursa geri üretilebilir mi?
4. Ne kadar süre tutulmalıdır?
5. Kimlerin gerçekten erişmesi gerekir?
6. Yedeklerde, loglarda veya hata raporlarında kopyası oluşuyor mu?

Bir parola hiçbir zaman uygulama loguna yazılmamalıdır. Bir erişim belirteci “hata ayıklama için” loglandığında belirtecin kriptografik olarak güçlü olması anlamını yitirir. Kişisel veri veritabanında şifrelenmiş olsa bile yedekte açık bulunuyorsa koruma yarımdır. Güvenlik, verinin yalnız ana depoda değil bütün yaşam döngüsünde izlenmesini gerektirir.

4. Saldırganın ilk işi: görünür yüzeyi haritalamak

Beyaz şapkalı testlerde bilgi toplama aşamasının değeri, yıllar önce kullanılan araç isimleri değişse de değişmedi. Pasif bilgi toplama ile aktif keşif arasındaki ayrım hâlâ önemlidir.

Pasif keşifte hedefe doğrudan veya belirgin trafik üretmeden açık kaynaklar, DNS bilgileri, sertifika şeffaflık kayıtları, kaynak kodu depoları, dokümantasyon, iş ilanları, geçmiş web içerikleri ve yayımlanmış meta veriler incelenebilir. Aktif keşifte hedef sistemle etkileşime girilir; portlar, servisler, protokoller, sürümler, uygulama yolları ve davranışlar ölçülür.

Bu aşamanın savunma açısından asıl değeri şudur: saldırganın görebildiği şeyi siz de görmelisiniz.

4.1 Bilgi sızıntısı küçük görünür, zincirde büyür

Bir HTTP Server başlığı, ayrıntılı hata ekranı veya kaynak haritadaki klasör yapısı tek başına sistem ihlali değildir. Ancak keşif maliyetini düşürür. Sürüm bilgisi belirli CVE'lere yöneltir. Kullanıcı adı biçimi parola püskürtme hedefi oluşturur. Çalışan teknoloji yığını doğru istismar sınıfını seçtirir. Dahili host adı Active Directory veya DNS topolojisi hakkında ipucu verir.

Bu nedenle hata mesajlarını “saldırgan hiçbir şey öğrenmesin” refleksiyle anlamsızlaştırmak yerine iki kanala ayırmak gerekir:

• kullanıcıya kararlı, sınırlı ve işlem yapılabilir hata kimliği,
• yalnız yetkili gözlemleme sisteminde ayrıntılı teknik bağlam.

OWASP Top 10:2025'te istisnai durumların hatalı ele alınmasının ayrı bir kategori hâline gelmesi de bu noktayı güçlendirir. Hata yolu, normal yol kadar tasarlanmalıdır.

4.2 Ağ keşfi bize mimarinin gerçeğini söyler

Mimari diyagram ile çalışan ağın aynı şey olduğunu varsaymak tehlikelidir. Port tarama ve servis keşfi çoğu zaman dokümantasyonda bulunmayan gerçekleri gösterir: unutulmuş yönetim portu, dışarı açılmış veritabanı dinleyicisi, eski SSH servisi, test amaçlı bırakılmış HTTP uç noktası veya yanlış VLAN'da duran cihaz.

Savunmada hedef “Nmap çalışmasın” değildir. Hedef, keşfedilen yüzeyin bilinçli ve gerekli olmasıdır. Bir servis iş gereği dışarı açık değilse kapatılır. Açık olmak zorundaysa kimlik, yetki, ağ kaynağı ve istek hızı sınırları tasarlanır. Portu gizlemek kontrol değildir; erişimi sınırlandırmak kontroldür.

5. Tehdit modelleme: kod yazmadan önce saldırı yolu aramak

Güvenlik testinin en ucuz açığı, henüz kodlanmamış açıktır. Tehdit modelleme bunun için yapılır.

Bir tasarım toplantısında veri akışını çizip “burada kim kime güveniyor?” sorusunu sormak, aylar sonra sızma testinde aynı problemin bulunmasından daha ucuzdur. Üstelik sızma testi her iş mantığı hatasını yakalayamaz. Test uzmanı sistemin bütün iş kurallarını geliştirici kadar bilmeyebilir; tehdit modelleme bu bilgiyi tasarım sırasında güvenlik açısından kullanır.

5.1 Veri akış diyagramı ve güven sınırı

Örnek bir akışı ele alalım:

[Tarayıcı]
    |
    | HTTPS
    v
[API Geçidi] ---- [Kimlik Sağlayıcı]
    |
    v
[Sipariş Servisi] ---- [Mesaj Kuyruğu] ---- [Faturalama]
    |
    v
[Veritabanı]

Her kutu süreç veya veri deposudur; oklar veri akışıdır. Fakat güvenlik açısından asıl önemli çizgiler güven sınırlarıdır. Tarayıcı bizim kontrolümüzde değildir. API geçidinden servis ağına geçiş başka bir sınırdır. Mesaj kuyruğundan gelen veri, daha önce bizim servisimiz üretmiş olsa bile değiştirilemez olduğunu varsaymamalıdır. Veritabanından okunan içerik de geçmişte saldırgan tarafından yazılmış olabilir.

“İç ağdan geliyor, güvenlidir” cümlesi birçok zayıflığın başlangıcıdır.

5.2 STRIDE bir düşünme aracı olarak

STRIDE hâlâ hızlı bir tehdit taraması için yararlıdır:

| Sınıf | Soru | |---|---| | Spoofing | Bir aktör başka bir kimlik gibi davranabilir mi? | | Tampering | Veri veya işlem yetkisiz değiştirilebilir mi? | | Repudiation | Bir işlem sonradan inkâr edilebilir mi; yeterli kanıt var mı? | | Information Disclosure | Yetkisiz bilgi açığa çıkabilir mi? | | Denial of Service | Kaynak tüketilerek hizmet durdurulabilir mi? | | Elevation of Privilege | Düşük yetki daha yüksek yetkiye çevrilebilir mi? |

Bu tabloyu doldurmak sonuç değildir. Her tehdit, doğrulanabilir güvenlik gereksinimine çevrilmelidir. Örneğin “tampering olabilir” yerine “mesaj tüketicisi kaynağı doğrulanmamış veya bütünlük koruması olmayan mesajı iş emrine dönüştürmeyecek” gibi bir gereksinim üretilir.

5.3 Saldırı ağacı ve graf düşüncesi

Active Directory çalışmalarında BloodHound'un öğrettiği en kalıcı derslerden biri graf düşüncesidir. Aynı düşünceyi uygulama mimarisine taşıyabiliriz.

Hedef: kritik raporu değiştirmek.

Muhtemel yollar:

Kritik raporu değiştir
├── Yönetici hesabını ele geçir
│   ├── oltalama
│   ├── zayıf parola
│   └── oturum belirtecinin sızdırılması
├── Yetki kontrolünü atla
│   ├── nesne düzeyi yetki eksikliği
│   └── rol kontrolündeki mantık hatası
├── Veritabanına doğrudan eriş
│   ├── SQL injection
│   ├── servis hesabı sırrı
│   └── ağ segmentasyonu hatası
└── Dağıtım zincirini ele geçir
    ├── CI/CD kimliği
    ├── bağımlılık zehirleme
    └── imzasız artefakt

Savunma stratejisi burada daha açıktır. Aynı hedefe giden dört yol varsa yalnız birini kapatmak yeterli değildir. Aynı kontrol birden fazla yolu kesiyorsa değeri yüksektir. Örneğin güçlü kimlik doğrulama kullanıcı hesabı yolunu daraltırken, en az ayrıcalıklı veritabanı hesabı hem SQL injection'ın etkisini hem sızmış servis sırrının etkisini azaltır.

6. Risk önceliklendirme: en çok bulguyu değil en tehlikeli yolu kapatmak

Güvenlik taramalarında yüzlerce bulgu üretmek kolaydır. Zor olan hangisinin önce düzeltilmesi gerektiğidir.

Pratikte şu bileşenleri birlikte düşünmek daha sağlıklıdır:

Risk ≈ istismar edilebilirlik × etki × maruziyet × saldırı zincirindeki kaldıraç

Bu matematiksel bir standart formül değildir; düşünme modelidir. İnternete açık, kimlik gerektirmeyen ve kolay istismar edilen orta etkili bir açık, yalnız ayrı yönetim ağından erişilen yüksek etkili bir açıktan önce ele alınabilir. Tersine, düşük yetkili hesaptan Domain Admin'e giden tek kenarı oluşturan yanlış grup üyeliği, sıradan bir yapılandırma bulgusundan çok daha önemlidir.

CVSS, CWE, OWASP, MITRE ATT&CK ve kurumun kendi risk matrisi birbirinin yerine geçmez. CVSS teknik şiddeti standartlaştırır; CWE hata sınıfını anlatır; ATT&CK saldırgan davranışını taktik ve tekniklerle ilişkilendirir; OWASP uygulama risklerini kümeler; iş etkisini ise sistemi işleten kurum bilir.

7. Güvenli mimari: saldırıyı kod seviyesine gelmeden zorlaştırmak

İyi mimarinin güvenlik avantajı, geliştiricinin her satırda kusursuz olmasını beklememesidir. İnsan hata yapar. Güvenli mimari, tek hatanın bütün sistemi ele geçirmesini zorlaştırır.

7.1 En az ayrıcalık

Bir servis yalnız üç tabloyu okuyup bir tabloya yazıyorsa bütün şemada DDL yetkisi istemez. Bir arka plan işi yalnız bir nesne deposuna yazıyorsa tüm depolara erişmemelidir. Bir konteyner root yetkisi gerektirmiyorsa root çalışmamalıdır. Bir kullanıcı rapor okuyorsa yönetim uç noktasına erişmemelidir.

En az ayrıcalık, “yetkiyi kısalım” yaklaşımı değil, işlev için gerekli en küçük yetki kümesini tanımlama işidir.

Bu ilkeye uyulmadığında küçük bir açık büyük bir ihlale dönüşür. SQL injection yalnız belirli kayıtları okuyabilecekken veritabanı hesabının aşırı yetkisi yüzünden dosya sistemi veya yönetim işlemlerine uzanabilir. Uygulama sunucusundaki bir RCE, süreç root çalışıyorsa işletim sistemini doğrudan etkiler. Domain servis hesabının gereksiz yönetici üyeliği, parola ele geçirilince yanal hareketi kolaylaştırır.

7.2 Yetkileri ayırmak

Tek hesapla geliştirme, dağıtım, veritabanı yönetimi ve üretim işletimi yapmak operasyonel olarak hızlı görünür. Güvenlik açısından ise tek kimliği sistemin ana anahtarına dönüştürür.

Yetki ayrılığı şu düzeylerde kurulabilir:

• geliştirici ve üretim işletim rolleri,
• uygulama ve veritabanı yönetim hesapları,
• okuma ve yazma servisleri,
• dağıtım imzası ve artefakt üretimi,
• günlük kullanım hesabı ve ayrıcalıklı yönetim hesabı,
• kritik işlemlerde iki kişi veya ek doğrulama gereksinimi.

Ayrılık yalnız saldırgana karşı değildir. Yanlış komut, hatalı otomasyon ve içeriden kaynaklanan riski de sınırlar.

7.3 Katmanlı savunma

Katmanlı savunma aynı kontrolü beş kez kurmak değildir. Birbirinden bağımsız hata türlerini yakalayan kontroller kurmaktır.

Örneğin bir API için:

Ağ erişim kısıtı
    + güçlü kimlik doğrulama
    + nesne düzeyi yetkilendirme
    + girdi doğrulama
    + parametreli sorgu
    + en az ayrıcalıklı DB hesabı
    + güvenlik logu ve alarm

SQL injection açığı yanlışlıkla ortaya çıksa bile DB hesabının sınırlı yetkisi etkiyi küçültür; anormal sorgu davranışı gözlenebilir; yedek ve olay müdahalesi geri dönüş olanağı sağlar. Katmanların değeri, aynı varsayıma bağlı olmamalarından gelir.

7.4 Güvenli varsayılan

CISA'nın Secure by Design yaklaşımındaki önemli fikirlerden biri güvenlik yükünün müşteriye bırakılmamasıdır. Ürün kurulduğunda varsayılan parola, açık yönetim portu veya “isterseniz MFA'yı açabilirsiniz” yaklaşımı güvenli varsayılan değildir.

En kolay yol güvenli yol olmalıdır. Güvenlik özelliği ayrıca satın alınan veya onlarca gizli ayarla etkinleştirilen bir seçenek hâline gelirse gerçek dağıtımların önemli bölümü güvensiz kalır.

7.5 Hata durumunda güvenli davranış

Bir yetkilendirme servisine erişilemediğinde “iş devam etsin” diye erişim vermek fail-open davranıştır. Bazı yüksek erişilebilirlik gereksinimlerinde kontrollü istisna tasarlanabilir; fakat bunun bilinçli bir risk kararı olması gerekir.

Hata yolunda şu sorular sorulmalıdır:

• Kimlik sağlayıcı yoksa ne olur?
• Sertifika doğrulanamazsa bağlantı devam eder mi?
• Yetki servisi zaman aşımına uğrarsa izin mi, ret mi üretir?
• Log diski dolarsa uygulama durur mu, log atlar mı?
• Rate limiter deposu çalışmazsa sınır kalkar mı?
• İmza doğrulama anahtarı bulunamazsa belirteç kabul edilir mi?

Saldırgan yalnız normal akışı kullanmaz. Hata koşulu da saldırı yüzeyidir.

8. Güvenli geliştirme yaşam döngüsü: güvenliği sona bırakmamak

Bir uygulama tamamlandıktan sonra güvenlik ekibine verilip “açıklarını bulun” denildiğinde güvenlik maliyeti en yüksek noktadadır. Mimari hata bulunursa düzeltme yalnız kodu değil API sözleşmesini, veri modelini, istemcileri ve dağıtımı etkileyebilir.

NIST SSDF 1.1 güvenli geliştirme pratiklerini dört ana grupta düzenler: kuruluşu hazırlamak, yazılımı korumak, iyi güvenli yazılım üretmek ve güvenlik açıklarına karşılık vermek. Bu çerçeveyi günlük geliştirmeye çevirdiğimizde şu akış ortaya çıkar:

Gereksinim
   -> tehdit modelleme
   -> güvenlik kabul ölçütleri
   -> mimari karar
   -> güvenli kodlama
   -> kod inceleme
   -> otomatik analiz
   -> güvenlik testi
   -> güvenilir derleme
   -> kontrollü dağıtım
   -> gözlemleme
   -> güvenlik açığı yönetimi
   -> kök neden analizi
   -> yeni gereksinim

Buradaki son ok önemlidir. Aynı hata sınıfı üçüncü kez bulunuyorsa yalnız üç bug kapatılmamıştır; geliştirme sürecinde sistematik eksik vardır.

8.1 Güvenlik kabul ölçütleri

Bir kullanıcı hikâyesi'nin “çalışıyor” olması yeterli değildir. Güvenlik açısından da kabul ölçütü gerekir.

Örnek: “Kullanıcı kendi belgesini indirebilir.”

Güvenlik kabul ölçütleri:

• nesne kimliği değiştirilse bile başka kullanıcının belgesi dönmez,
• kullanıcı kimliği istemciden gelen userId alanına güvenilerek belirlenmez,
• indirme işlemi yetki denetiminden sonra yapılır,
• dosya yolu kullanıcı girdisinden doğrudan oluşturulmaz,
• erişim olayı denetlenebilir biçimde kaydedilir,
• hata cevabı dosyanın varlığını yetkisiz tarafa gereksiz yere ifşa etmez.

Bunlar sızma testinden önce yazıldığında güvenlik, test ekibinin bulmasını beklediğimiz gizli bir özellik olmaktan çıkar.

9. Kimlik doğrulama: parola alanından daha büyük bir problem

Kimlik doğrulama, “kullanıcı adı ve parola doğru mu?” sorusundan ibaret değildir. Kayıt, kimlik kanıtlama, kimlik doğrulayıcı bağlama, giriş, MFA, oturum oluşturma, kurtarma, parola sıfırlama, cihaz kaybı ve hesabın kapatılması tek bir yaşam döngüsüdür.

En güçlü giriş ekranı bile zayıf parola sıfırlama akışıyla aşılabilir. Güvenlik sorusunun cevabı sosyal medyadan bulunabiliyorsa MFA'nın yanındaki “hesabı kurtar” bağlantısı saldırganın tercih ettiği yol olur.

9.1 Parola politikası: karmaşıklık tiyatrosundan maliyet modeline

Uzun süre parola politikaları büyük harf, küçük harf, sayı, sembol ve periyodik değişiklik üzerine kuruldu. Güncel NIST SP 800-63B-4 bu yaklaşımı değiştirmiştir. Tek faktör olarak kullanılan parolalarda en az 15 karakter ister; MFA'nın parçası olarak kullanılan parolalarda en az 8 karaktere izin verir, en az 64 karakterlik üst sınır desteğini önerir, keyfî karakter sınıfı kurallarını ve kanıt olmadan periyodik parola değişimini reddeder. Yaygın, beklenen veya ele geçirilmiş parolaların blok listesiyle engellenmesini ve çevrimiçi tahminlere karşı hız sınırlamasını ister.

Bu yaklaşım saldırganın gerçek maliyetine odaklanır. Password1! karmaşıklık kuralını geçebilir ama güçlü değildir. Uzun ve benzersiz parola, parola yöneticisi, ihlal edilmiş parola blok listesi, güvenli saklama ve doğru hız sınırlama birlikte daha anlamlıdır.

9.2 Parolayı saklamak

Parola şifrelenip daha sonra çözülecek bir veri değildir. Doğrulama için tek yönlü, maliyeti ayarlanabilir parola özetleme algoritması kullanılmalıdır. Genel amaçlı SHA-256 gibi hızlı özet algoritmaları parola saklama için uygun değildir; saldırganın saniyede çok fazla tahmin yapmasına izin verir.

OWASP Password Storage Cheat Sheet güncel olarak Argon2id'i birincil seçeneklerden biri olarak önerir. Algoritmanın parametreleri üretim donanımında ölçülmelidir. Amaç meşru giriş gecikmesini kabul edilebilir düzeyde tutarken çevrimdışı tahmin maliyetini yükseltmektir.

password
   + benzersiz salt
   + maliyet parametreleri
   -> Argon2id / uygun parola KDF'si
   -> saklanan doğrulayıcı

pepper kullanılıyorsa veritabanından ayrı bir sır yönetiminde tutulmalıdır. Veritabanı ile pepper aynı yapılandırma dosyasında bulunuyorsa beklenen ayrışma oluşmaz.

9.3 MFA'nın sınırı

MFA her saldırıyı çözmez. SMS tabanlı faktör SIM değişimi veya telekom saldırılarından etkilenebilir. TOTP kodu gerçek zamanlı oltalama proxy'siyle çalınabilir. Push bildirimleri kullanıcı yorgunluğu üzerinden kötüye kullanılabilir. Phishing-resistant kimlik doğrulayıcı'lar bu nedenle daha değerlidir.

Doğru soru “MFA açık mı?” değil, hangi tehdide karşı hangi kimlik doğrulayıcı kullanılıyor ve kurtarma yolu aynı güvenceyi koruyor mu? sorusudur.

9.4 Parola püskürtme ve hesap kilitleme

Notlarda Active Directory ve CrackMapExec çalışmalarında görülen parola püskürtme mantığı, klasik brute force'tan farklıdır. Bir hesapta çok parola denemek yerine az sayıda muhtemel parola çok kullanıcıya uygulanır. Basit hesap kilitleme politikası bu davranışı her zaman yakalayamaz; saldırgan kilitlenme eşiğinin altında kalabilir.

Savunma için başarısız girişleri yalnız kullanıcı başına değil kaynak, hedef kümesi, zaman aralığı ve davranış paterniyle birlikte değerlendirmek gerekir. Bunun yanında MFA, zayıf parola blok listesi, eski protokollerin kapatılması ve servis hesaplarının doğru yönetimi saldırı yüzeyini azaltır.

10. Yetkilendirme: giriş yapmış olmak izin sahibi olmak değildir

Uygulama güvenliğinde en kalıcı hatalardan biri kimlik doğrulama ile yetkilendirmeyi aynı şey sanmaktır. Kullanıcının kim olduğunu bilmek, o kullanıcının istenen nesne üzerinde belirtilen işlemi yapabileceğini göstermez.

Bir API şu isteği alıyor olsun:

GET /api/documents/73152
Authorization: Bearer <belirteç>

Belirteç geçerli olabilir. Kullanıcı gerçekten giriş yapmış olabilir. Fakat 73152 numaralı belge ona ait değilse cevap yine reddedilmelidir. Menüde “Belgeler” bağlantısını gizlemek, JavaScript'te butonu devre dışı bırakmak veya kullanıcı rolünü istemcide kontrol etmek sunucu tarafı yetkilendirmenin yerine geçmez.

10.1 Nesne düzeyinde yetkilendirme

En güvenilir desen, kaynağı getirirken yetki kapsamını sorguya taşımaktır:

SELECT id, name, content
FROM document
WHERE id = ?
  AND owner_id = ?;

Burada ikinci parametre istemcinin gönderdiği ownerId değildir; doğrulanmış kimlik bağlamından gelir. Daha karmaşık sistemlerde RBAC, ABAC veya politika motoru kullanılabilir. İlke değişmez: işlem, nesne ve aktör birlikte değerlendirilir.

10.2 Deny by default

Yeni uç nokta eklenip yetki kuralı unutulduğunda herkesin erişebilmesi tehlikeli varsayılandır. Yetkilendirme mimarisi mümkün olduğunca “açıkça izin verilmediyse reddet” biçiminde kurulmalıdır.

Bu yaklaşım özellikle büyük projelerde önemlidir. Birkaç uç nokta için manuel kontrol kolaydır; yüzlerce route, mesaj tüketicisi ve arka plan görevi olan sistemde unutulan tek kontrol üretim açığına dönüşebilir.

10.3 Dikey ve yatay yetki yükseltme

Yatay yetki yükseltme, aynı yetki seviyesindeki başka kullanıcının kaynağına erişmektir. Dikey yetki yükseltme, daha yüksek rolün yapabildiği işlemi yapabilmektir.

Testte ikisini ayrı düşünmek gerekir:

• kullanıcı A, kullanıcı B'nin nesnesini okuyabiliyor mu?
• normal kullanıcı yönetici uç noktasını çağırabiliyor mu?
• yalnız okuma yetkisi olan kullanıcı yazabiliyor mu?
• bir tenant kullanıcısı başka tenant'ın nesnesine erişebiliyor mu?
• toplu uç nokta tekil uç noktadaki yetki kontrolünü atlıyor mu?
• export, arama, geçmiş veya ek dosya yolları ana nesne kadar sıkı korunuyor mu?

Birçok yetki açığı ana CRUD uç noktasında değil, ikincil işlevde ortaya çıkar.

11. Oturum güvenliği: kimliği bir istekten diğerine taşımak

HTTP durum tutmaz. Kullanıcının bir kez kimlik doğruladıktan sonra sonraki isteklerde tanınması için oturum kimliği veya belirteç kullanılır. Bu değer ele geçirilirse saldırgan parolayı bilmeden kullanıcı gibi davranabilir.

Bu yüzden oturum kimliği bir sırdır.

11.1 Çerez tabanlı oturum

Tarayıcı tabanlı uygulamalarda çerez kullanılıyorsa en az şu özellikler değerlendirilmelidir:

• Secure: yalnız HTTPS üzerinden gönderim,
• HttpOnly: JavaScript'in çerezi doğrudan okumasını sınırlama,
• SameSite: siteler arası istek davranışını kontrol etme,
• uygun Domain ve Path: gereksiz kapsamı azaltma,
• kimlik doğrulamadan sonra oturum ID yenileme,
• çıkışta sunucu tarafı geçersizleştirme,
• mutlak ve hareketsizlik zaman aşımı.

HttpOnly XSS'yi çözmez; yalnız belirli çerez hırsızlığı yolunu daraltır. XSS varsa saldırgan kullanıcı adına aynı origin üzerinde işlem yapabilir. Katmanlı savunmayı yanlış yorumlamamak gerekir.

11.2 JWT: imzalı olmak güvenli olmak değildir

JWT bir kimlik doğrulama protokolü değildir; belirli iddiaları taşıyabilen bir belirteç biçimidir. İmzayı doğrulamak zorunludur ama yeterli değildir. Kaynak sunucu en az şu bağlamı doğrulamalıdır:

• beklenen imza algoritması,
• güvenilen anahtar,
• iss veren taraf,
• aud hedef kitle,
• exp süresi,
• gerektiğinde nbf,
• yetki iddialarının semantiği,
• anahtar döndürme ve iptal stratejisi.

Belirteç içeriği Base64URL ile kodlanmış olduğu için gizli değildir. Parola, özel anahtar veya gereksiz kişisel veri JWT içine konmamalıdır.

Asimetrik imza mimarisi, kaynak sunucuların doğrulama anahtarını bilip imzalama anahtarına sahip olmamasını sağlar. Bu ayrım mikroservis ortamında değerlidir. Buna rağmen uzun ömürlü bearer belirteci çalındığında imza saldırganı durdurmaz. Belirteç ömrü, yenileme, hedef kitle (aud) kısıtı, gönderim kanalı ve hassas işlemlerde yeniden doğrulama birlikte düşünülmelidir.

12. Kriptografi: algoritma seçmekten çok anahtar yönetmek

Kriptografi güvenli sistemlerin temelidir; fakat yanlış uygulandığında yalnız güven hissi üretir. AES kullanmak tek başına verinin güvende olduğunu göstermez. Mod, nonce/IV üretimi, anahtar uzunluğu, anahtar saklama, bütünlük, anahtar döndürme, yedek ve erişim modeli de önemlidir.

12.1 Şifreleme, özet, MAC ve imza farklı problemleri çözer

| Mekanizma | Temel amaç | |---|---| | Şifreleme | Gizlilik | | Kriptografik özet | Veri için sabit uzunluklu özet; tek başına kimlik doğrulamaz | | HMAC/MAC | Paylaşılan sırla bütünlük ve kaynak doğrulama | | Dijital imza | Özel/açık anahtar modeliyle bütünlük ve imzalayanın doğrulanması | | Parola KDF'si | Parola tahminini maliyetli hâle getirmek |

Güvensiz tersine serileştirme notlarında HMAC ile istemciye verilen seri hâle getirilmiş verinin değişip değişmediğini kontrol etme fikri görülür. Bu iyi bir ders verir: bütünlük ile gizlilik aynı şey değildir. HMAC veriyi gizlemez; değiştirilmesini tespit etmeye yarar. Üstelik güvenilmeyen veriyi native nesne grafiğine dönüştürmek zorunlu değilse daha iyi çözüm serileştirme biçimini güvenli bir veri modeline çevirmektir. Kriptografik doğrulama, tehlikeli ayrıştırıcı davranışını meşrulaştırmamalıdır.

12.2 Kendi kriptografinizi tasarlamayın

Kriptografik ilkelere aşina olmak gerekir; fakat üretim protokolünü “AES + SHA-256 + Base64 yaptım” biçiminde birleştirmek ciddi risk taşır. Doğrulanmış protokoller ve iyi incelenmiş kütüphaneler kullanılmalıdır.

TLS'de sertifika doğrulamasını kapatmak, güçlü şifreleme algoritmasını anlamsızlaştırır. Mobil testlerde certificate pinning'i aşma çalışmaları da bunu görünür kılar: istemci, güven kararını nerede ve nasıl veriyor? Pinning bazı tehditlerde ek savunma sağlayabilir; fakat ana güven modeli standart sertifika doğrulamasının doğru uygulanmasına dayanmalıdır. Test için TrustAll benzeri kodun üretime taşınması, TLS'i yalnız şifreli ama kimliği belirsiz bir tünele dönüştürür.

12.3 Sır yönetimi

Sırları şu yerlerde bırakmamak gerekir:

• kaynak kodu,
• Git geçmişi,
• istemci uygulaması,
• Docker image katmanı,
• CI logu,
• hata mesajı,
• genel yapılandırma dosyası,
• herkesin okuyabildiği ortam değişkeni dökümü,
• destek paketleri ve diagnostic dump'lar.

Bir sır sızdığında yalnız dosyayı silmek yetmez; sırın ele geçirilmiş kabul edilip döndürülmesi gerekir. Git geçmişindeki anahtarı son commit'ten kaldırmak onu internetten geri çağırmaz.

13. Güvenilmeyen veri: saldırıların ortak kökü

Bir verinin kaynağını “kendi frontend'im”, “veritabanım”, “mesaj kuyruğum” veya “iç ağ” olarak adlandırmak onu güvenilir yapmaz. Güven, verinin geçmişine göre değil kullanıldığı güven sınırına göre değerlendirilmelidir.

Bir tarayıcı isteği değiştirilebilir. Mobil uygulama tersine mühendislikle incelenebilir ve istemci kontrolleri atlanabilir. Veritabanındaki kayıt geçmişte XSS ile yazılmış olabilir. Mesaj kuyruğundaki veri ele geçirilmiş bir üreticiden gelmiş olabilir. Dosya adı kullanıcı kontrolünde olabilir. LDAP özniteliği dış sistem tarafından doldurulmuş olabilir.

Bu nedenle her yorumlayıcı sınırında iki soru sorulur:

1. Veri hangi biçimde kabul edilecek?
2. Bu veri hangi bağlamda kullanılacak?

İlk soru girdi doğrulama, ikincisi çoğu zaman bağlama uygun güvenli API veya çıktı kodlama problemidir.

13.1 İzin listesi düşüncesi

“Tehlikeli karakterleri silelim” yaklaşımı uzun vadede zayıftır. Yasak liste saldırganın bütün temsil biçimlerini öngörmeye çalışır. Unicode, farklı kodlamalar, canonicalization, ayrıştırıcı farkları ve yeni sözdizimleri bu yaklaşımı kırar.

Bir alan UUID ise UUID biçimini kabul edin. Bir sayfa numarası pozitif tam sayıysa bunu parse edin ve aralığını doğrulayın. Bir enum yalnız belirli değerleri alıyorsa diğerlerini reddedin. Dosya uzantısı güvenlik kararıysa yalnız dosya adına bakmayın; içerik, MIME ve işleme biçimini birlikte değerlendirin.

Doğrulama uygulama gereksinimini tanımlar. Enjeksiyonu tek başına çözmez. SQL için parametreli sorgu, HTML için bağlama uygun çıktı kodlama gibi mekanizmalar ayrıca gerekir.

14. Enjeksiyon: veri komuta dönüştüğünde

Enjeksiyon saldırılarının farklı isimleri vardır; kök problem aynıdır. Uygulama, dışarıdan gelen veriyi komutun veya kodun parçası hâline getirir.

14.1 SQL injection

Savunmasız düşünce biçimi:

String sql = "SELECT id, role FROM users WHERE username = '" + username + "'";

Buradaki sorun yalnız tek tırnaktır. Kullanıcı verisi SQL sözdiziminin içine birleştirilmiştir. Karakter kaçırma ile bütün SQL lehçelerini, kodlamaları ve gelecekteki değişiklikleri doğru yönetmeye çalışmak gereksiz risk üretir.

Güvenli sınır parametreli sorgudur:

PreparedStatement ps = connection.prepareStatement("SELECT id, role FROM users WHERE username = ?");
ps.setString(1, username);

Parametreli sorguda SQL yapısı ile veri ayrı kanallardadır. Bu ayrım güvenlik ilkesidir; PreparedStatement yalnız uygulama aracıdır.

Dinamik tablo adı, kolon adı veya ORDER BY yönü parametrelenemiyorsa kullanıcı girdisini doğrudan birleştirmek yerine uygulama içindeki sabit bir izin listesi'ten seçim yapılır.

İkinci savunma DB hesabının en az ayrıcalığıdır. Enjeksiyon hatası oluşsa bile uygulama hesabı yalnız işlevi için gereken işlemleri yapabiliyorsa etki sınırlandırılır.

14.2 İşletim sistemi komut enjeksiyonu

Bir dosyayı dönüştürmek için shell komutu oluşturup kullanıcı dosya adını metne eklemek, SQL injection'ın başka yorumlayıcıdaki karşılığıdır. Mümkünse shell yerine doğrudan kütüphane veya process API'si kullanılmalı, argümanlar ayrı aktarılmalıdır. sh -c benzeri ek yorumlayıcı katmanı saldırı yüzeyini büyütür.

Güvenlik açısından en güçlü çözüm çoğu zaman “daha iyi escape” değil, yorumlayıcıyı aradan çıkarmaktır.

14.3 LDAP, template ve diğer yorumlayıcılar

LDAP filter injection, expression language injection, template injection ve benzeri sınıflar da aynı modele girer. Uygulama geliştirirken “bu string daha sonra hangi ayrıştırıcıya gidecek?” sorusu alışkanlık hâline gelmelidir.

Bir değişken sırayla URL, JSON, HTML ve JavaScript bağlamına giriyorsa her sınırın kuralları farklıdır. Tek bir sanitize() fonksiyonuyla bütün bağlamları güvenli kılmak gerçekçi değildir.

15. XSS: karakter filtresi değil, bağlam problemi

Eski eğitim materyallerinde XSS çoğu zaman <script>alert(...)</script> saldırı yükünün çalışmasıyla gösterilir ve çözüm olarak belirli etiketleri silme önerilir. Bu, açığı anlamak için başlangıç olabilir fakat güncel savunma için yetersizdir.

XSS'nin asıl sorusu şudur: güvenilmeyen veri tarayıcıda hangi bağlamda yorumlanıyor?

Aynı veri şu bağlamlarda farklı kurallara tabidir:

<div>METİN</div>
<input value="ÖZNİTELİK">
<script>const x = "JAVASCRIPT_DİZGESİ";</script>
<a href="URL">bağlantı</a>
<style>CSS_BAĞLAMI</style>

HTML metin düğümünde güvenli olan kodlama JavaScript bağlamında aynı anlamı taşımayabilir. Bu nedenle bağlama duyarlı çıktı kodlama gerekir.

15.1 DOM XSS

İstemci tarafında innerHTML gibi sink'lere kullanıcı kontrollü veri taşımak risklidir. Metin göstermek için textContent gibi semantiği güvenli API'ler tercih edilir. Gerekiyorsa HTML sanitizasyonu, bu amaç için olgun bir kütüphane ve dar bir izin listesi ile yapılmalıdır.

15.2 CSP savunma katmanıdır

Content Security Policy, doğru tasarlandığında XSS etkisini ciddi biçimde azaltabilir. Fakat CSP'yi çıktı kodlamanın yerine koymak yanlıştır. Nonce/hash tabanlı sıkı politika, inline script bağımlılığını azaltır ve beklenmeyen script kaynaklarını sınırlar.

Örnek ilke:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-<istek-specific>'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'

Gerçek politika uygulamanın kaynak ihtiyaçlarına göre oluşturulmalı, önce raporlama modunda ölçülmeli ve gereksiz genişletmelerden kaçınılmalıdır. unsafe-inline ile açılan geniş bir script-src, politikanın değerini önemli ölçüde azaltabilir.

15.3 Çerez çalınmıyorsa XSS önemsiz değildir

HttpOnly çerez nedeniyle document.cookie okunamaması XSS'nin etkisini ortadan kaldırmaz. Saldırgan aynı origin'de kullanıcının yapabildiği istekleri yapabilir, DOM'u değiştirebilir, hassas veriyi okuyabilir veya kullanıcıyı yanıltabilir. Savunmada güvenlik açığını gerçek yetenek modeliyle değerlendirmek gerekir.

16. CSRF ve CORS: birbirine benzeyen isimler, farklı güven sınırları

CSRF, tarayıcının kullanıcının kimlik bilgilerini otomatik olarak hedef siteye eklemesinden yararlanır. Kullanıcı saldırganın sayfasındayken hedef uygulamaya istek gönderilir; hedef yalnız çereze bakıyorsa isteği gerçek kullanıcı isteği sanabilir.

Savunmada durum değiştiren işlemlerde CSRF belirteci, uygun SameSite politikası, Origin/Referer değerlendirmesi ve çerçevenin yerleşik koruması kullanılabilir. Hangi mekanizmanın gerektiği kimlik doğrulama taşıma modeline bağlıdır.

CORS ise tarayıcının farklı origin'ler arasında script tarafından erişilebilecek cevapları belirleyen politikadır. CORS bir kimlik doğrulama veya sunucu tarafı yetkilendirme mekanizması değildir.

Şu politika gereksiz geniştir:

Access-Control-Allow-Origin: *

Hassas uygulamalarda ihtiyaç duyulan origin'ler açıkça tanımlanmalıdır. Dinamik origin yansıtılıyorsa girdinin gerçekten izin listesi'te olduğu doğrulanmalıdır. Origin değerini körlemesine geri yansıtmak kontrol değildir.

17. SSRF: sunucunun ağ konumunu saldırgana kiralamak

Bir uygulama kullanıcıdan URL alıp o adrese sunucu tarafından istek gönderiyorsa yalnız “URL indiriyoruz” işi yapmıyordur; saldırgana sunucunun ağ erişim konumundan istek üretme yeteneği verebilir.

Örnek kullanım alanları meşrudur:

• uzak resim alma,
• webhook doğrulama,
• PDF oluşturmak için dış URL çekme,
• entegrasyon testi,
• URL önizleme.

Ancak saldırgan hedefi iç ağ adresine, loopback'e, link-local servise veya beklenmeyen protokole yöneltebilirse SSRF oluşabilir.

Güvenli tasarımda mümkünse hedefler izin listesi ile sınırlanır. DNS çözümlemesinin zaman içinde değişebileceği, redirect'in ilk doğrulamayı aşabileceği ve IPv4/IPv6'nin farklı gösterimleri olduğu düşünülmelidir. Uygulama katmanındaki doğrulamaya ek olarak sunucunun gereksiz ağ erişimi egress firewall veya ağ politikasıyla kapatılmalıdır.

Bu, katmanlı savunmanın iyi örneğidir: ayrıştırıcı hatası olsa bile ağ katmanı kritik hedefe giden yolu kesebilir.

18. Yol geçişi ve dosya yükleme: dosya adı veri değildir

Kullanıcıdan alınan dosya adını doğrudan dizinle birleştirmek, ../ ve benzeri yol geçişi davranışlarına kapı açabilir. Normalizasyon ve canonical path denetimi önemlidir; daha güçlü tasarım ise fiziksel dosya yolunu kullanıcı girdisinden türetmemektir.

Dosya yüklemede yalnız uzantı kontrolü güvenilir değildir. Şu boyutlar birlikte değerlendirilir:

• izin verilen dosya türleri,
• içerik doğrulama,
• boyut ve adet limiti,
• kullanıcıdan bağımsız üretilen depolama adı,
• web root dışında depolama,
• çalıştırma yetkisinin olmaması,
• görüntü/medya ise güvenli yeniden işleme,
• antivirüs veya içerik analizi gereksinimi,
• indirme sırasında doğru Content-Type ve Content-Disposition,
• erişim yetkisinin her indirmede yeniden doğrulanması.

Bir yükleme servisi yalnız “dosya kabul eden uç nokta” değildir; ayrıştırıcı, depolama ve servis etme zinciridir.

19. Güvensiz tersine serileştirme: veriyi nesne grafiğine dönüştürmenin bedeli

Serileştirme, nesneyi taşınabilir veya saklanabilir biçime dönüştürür. Sorun, güvenilmeyen baytların güçlü bir native nesne modeline geri çevrilmesinde başlar. Bazı platformlarda nesne oluşturma sırasında magic method, gadget chain veya callback mekanizmaları beklenmeyen davranış üretebilir.

PHP, Python pickle/YAML ve .NET serileştirme örneklerinin ortak dersi araçtan bağımsızdır: güvenilmeyen veriyi davranış taşıyan nesne grafiğine dönüştürmeyin.

Daha güvenli desen, sınırlı veri şeması kullanmaktır:

{
  "userId": 42,
  "theme": "dark",
  "language": "tr"
}

JSON da otomatik olarak güvenli değildir; ayrıştırıcı ve tip bağlama seçenekleri önemlidir. Ancak yalnız gerekli primitive alanları tanımlayan şema, keyfî sınıf üretimine göre saldırı yüzeyini önemli ölçüde küçültür.

HMAC veya dijital imza, verinin güvenilir üreticiden geldiğini doğrulamak için yararlı olabilir. Fakat imzalı tehlikeli nesne formatı, anahtar sızdığında veya başka bir güvenilir üretici yanlış veri oluşturduğunda yine tehlikelidir. En güçlü çözüm veri modelini daraltmaktır.

20. API güvenliği: protokol kadar iş mantığını korumak

API güvenliği yalnız HTTP header seti değildir. Modern uygulamada iş mantığının büyük bölümü API üzerinden erişilebilir olduğundan, istemci arayüzünde görünmeyen işlevlerin de saldırı yüzeyi olduğu unutulmamalıdır.

Her uç nokta için şu beş soru etkili bir inceleme çerçevesi oluşturur:

1. Kim çağırıyor? Kimlik nasıl doğrulanıyor?
2. Neyi yapmaya yetkili? Nesne ve işlem bazında kontrol var mı?
3. Ne gönderebilir? Şema, boyut, biçim ve semantik sınırlar var mı?
4. Ne kadar çağırabilir? Kaynak tüketimi ve otomasyon sınırı nedir?
5. Ne öğrenebilir? Cevap, hata, süre ve durum kodları gereksiz bilgi sızdırıyor mu?

20.1 Mass assignment

İstemciden gelen JSON'u doğrudan domain nesnesine bağlamak beklenmeyen alanların değişmesine izin verebilir:

{
  "displayName": "Ali",
  "role": "ADMIN",
  "approved": true
}

UI yalnız displayName gönderiyor olabilir; saldırgan HTTP isteğini kendisi oluşturur. DTO/command modeli yalnız değiştirilebilir alanları taşımak için kullanılmalı, hassas alanlar sunucu tarafındaki iş kuralından üretilmelidir.

20.2 Hız sınırlama yalnız DoS için değildir

İstek hızını sınırlandırmak parola tahmini, OTP denemesi, kullanıcı adı keşfi, pahalı rapor üretimi, toplu veri çekme ve scraping gibi birçok saldırıda maliyeti artırır. Ancak sabit “IP başına 100 istek” kuralı her problem için yeterli değildir. NAT, botnet, kullanıcı kimliği, işlem türü ve uç nokta maliyeti hesaba katılmalıdır.

Bir parola uç noktası ile statik içerik uç noktasının aynı limite tabi olması anlamlı değildir.

21. Veri katmanı: enjeksiyondan daha fazlası

Veritabanı güvenliği çoğu eğitimde SQL injection ile başlar ve orada biter. Üretim sisteminde veri katmanı çok daha geniştir: kimlik bilgileri, ağ erişimi, şema yetkileri, denetim izi, yedek, replikasyon, veri yaşam döngüsü, toplu dışa aktarma ve yönetim araçları aynı güven sınırının parçalarıdır.

21.1 Uygulama hesabı ile yönetici hesabını ayırmak

Uygulamanın çalışma hesabı şema sahibi veya DBA olmamalıdır. Normal işlev için gereken DML yetkileri mümkün olduğunca sınırlı tutulmalıdır. Şema göçü gerekiyorsa bunu ayrı kimlik ve ayrı dağıtım adımı yapmalıdır.

Bunun iki sonucu vardır. Birincisi, uygulama açığının etki alanı'u küçülür. İkincisi, hatalı uygulama kodunun yanlışlıkla şemayı değiştirmesi zorlaşır.

21.2 Veritabanı ağ sınırı

İnternete açık uygulamanın veritabanı portunun da internete açık olmasına gerek yoktur. Uygulama ve DB arasında gereken akış net biçimde tanımlanmalıdır. Yönetim erişimi ayrı ağ veya bastion üzerinden yapılabilir. “Parolası güçlü” diye gereksiz ağ erişimini açık bırakmak iyi savunma değildir.

21.3 Yedek de üretim verisidir

Canlı veritabanı şifreli, erişim kontrollü ve denetlenebilir olabilir; ancak günlük yedek herkesin erişebildiği paylaşıma yazılıyorsa sistemin gerçek veri güvenliği yedek kadar güçlüdür.

Yedeklerde şu kontroller düşünülmelidir:

• erişim yetkisi,
• şifreleme ve anahtar ayrılığı,
• bütünlük doğrulama,
• değiştirilemez veya offline kopya gereksinimi,
• geri yükleme testi,
• saklama süresi,
• güvenli silme,
• test ortamına veri taşırken maskeleme.

Ransomware olaylarında yedeğin varlığı değil geri yüklenebilir, saldırgandan ayrılmış ve doğrulanmış yedeğin varlığı önemlidir.

22. Bellek güvenliği: birkaç bayttan süreç denetimine

The Shellcoder's Handbook gibi klasik kaynakların kalıcı değeri, belirli istismar'lerin bugün hâlâ aynı biçimde çalışması değildir. Değeri, bir bellek hatasının makinenin yürütme modeline nasıl bağlandığını göstermesidir.

C ve C++ ile çalışırken dizi sınırı, pointer ömrü, integer dönüşümü, format string veya use-after-free gibi hatalar yalnız programın çökmesine neden olmaz. Uygun koşullarda saldırganın bellek düzenini etkilemesine, veri yönlendirmesine veya kontrol akışını değiştirmesine kadar ilerleyebilir.

22.1 Stack taşması bize ne öğretir?

Klasik bir stack overflow örneğinde sabit boyutlu tamponun sınırı aşılır. Tarihsel örneklerde dönüş adresinin üzerine yazılması, instruction pointer'ın saldırganın seçtiği adrese yönelmesi ve shellcode çalıştırılması gösterilir.

Modern sistemlerde şu azaltımlar saldırıyı zorlaştırır:

• stack canary,
• NX/DEP,
• ASLR,
• PIE,
• RELRO,
• Control-Flow Integrity'nin çeşitli biçimleri,
• donanım destekli kontrol akışı korumaları,
• güvenli derleyici seçenekleri.

Bunların varlığı “buffer overflow artık önemsiz” anlamına gelmez. İstismar tekniği değişir; bellek bozulması kök problem olarak kalır.

22.2 Savunmanın ilk katmanı istismar azaltımı değildir

Canary veya ASLR hatayı gidermediği için birinci savunma olamaz. Asıl hedef bellek hatasını üretmemektir:

• boyutu bilinen buffer API'leri,
• doğru integer ve uzunluk kontrolü,
• sahiplik/ömür modelinin açık olması,
• fuzzing,
• sanitizers,
• statik analiz,
• güvenli standard library bileşenleri,
• mümkün olan bileşenlerde bellek güvenli dil tercihi.

Güvenlik azaltımları ikinci katmandır. Bir hata kaçarsa istismar maliyetini yükseltir.

22.3 Heap, use-after-free ve karmaşık bellek hataları

Heap overflow veya use-after-free klasik stack taşmasına göre daha az sezgiseldir. Modern allocator davranışı, metadata yapısı ve nesne yerleşimi istismar edilebilirliği belirler. Savunmada kaynak kodu seviyesinde lifetime disiplini, sahiplik modeli, güvenli kapsayıcılar ve dinamik analiz araçları önem kazanır.

Bu alanda istismar geliştirme deneyiminin savunmaya en büyük katkısı şudur: “program çöküyor” ifadesi güvenlik analizini bitirmez. Çöküşün saldırgan kontrollü veriyle deterministik biçimde tekrar üretilebilmesi, instruction pointer veya kritik pointer'ların etkilenebilmesi ve bellek düzeninin yönlendirilebilmesi ayrıca incelenmelidir.

23. Tersine mühendislik: istemcide saklanan sır, sır değildir

Reversing: Secrets of Reverse Engineering çizgisindeki çalışmalar, derlenmiş programı yalnız assembly okumaya indirgemez. Bir uygulamanın güvenlik varsayımlarını binary seviyesinde gözlemlemeyi öğretir.

Mobil veya masaüstü istemcide şu varsayımlar tehlikelidir:

• “API adresini gizledik, bulunamaz.”
• “Admin butonu görünmüyor, çağrı yapılamaz.”
• “Anahtarı binary içine gömdük.”
• “Lisans kontrolü istemcide, kullanıcı değiştiremez.”
• “Certificate pinning var, trafik incelenemez.”
• “Kod obfuscate edildi, iş mantığı güvenli.”

Saldırgan dosyayı kendi makinesinde çalıştırır. Statik analiz, hata ayıklamager, API hooking, instrumentation veya bellek inceleme yeteneğine sahiptir. İstemcinin sahibi saldırgandır varsayımıyla tasarım yapmak gerekir.

23.1 Obfuscation güven sınırı değildir

Kod karartma tersine mühendislik maliyetini artırabilir. Fikri mülkiyet veya otomatik analiz direnci için yararlı olabilir. Ancak sunucu tarafı yetkilendirmenin yerine geçmez. Binary içinde bulunan uzun ömürlü ortak sır, yeterli zaman verildiğinde çıkarılabilir kabul edilmelidir.

23.2 Güvenlik testinde tersine mühendisliğin yeri

Tersine mühendislik özellikle şu sorular için değerlidir:

• istemci hangi uç noktaları çağırıyor?
• hata ayıklama/test işlevi unutulmuş mu?
• sertifika doğrulama gerçekten yapılıyor mu?
• hassas veri diske hangi biçimde yazılıyor?
• yerel veritabanında belirteç veya parola var mı?
• native kütüphanelerde bellek güvenliği problemi var mı?
• sunucunun yapması gereken yetki kararı istemciye bırakılmış mı?

Amaç binary'yi “kırmak” değil, istemcinin taşıyamayacağı güven sorumluluklarını ortaya çıkarmaktır.

24. İşletim sistemi güvenliği: uygulamanın altında kalan katman

Uygulama güvenli olsa bile üzerinde çalıştığı işletim sistemi gereksiz servisler, aşırı yetkiler veya zayıf dosya izinleri taşıyorsa saldırı yüzeyi devam eder.

24.1 Süreci olabildiğince güçsüz çalıştırmak

Bir web servisi root yetkisine ihtiyaç duymuyorsa root olarak çalışmamalıdır. Linux üzerinde systemd gibi mekanizmalar ek izolasyon sağlayabilir:

[Service]
User=app
Group=app
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true

Gerçek servis gereksinimine göre ReadWritePaths, capability sınırları, syscall filtreleri veya namespace özellikleri ayrıca değerlendirilebilir. Sıkılaştırma'i körlemesine kopyalamak doğru değildir; servis davranışı ölçülmeli ve gereken en küçük izin verilmelidir.

24.2 Dosya izinleri

Sır dosyası yalnız servis hesabı tarafından okunmalıysa 0644 uygun değildir. Log dosyası hassas bilgi içeriyorsa herkesin okuyabildiği dizine yazılmamalıdır. Uygulamanın binary veya config dizinine yazma ihtiyacı yoksa çalışma hesabına yazma yetkisi verilmemelidir.

Bu küçük izin kararları RCE sonrası saldırganın ne kadar ilerleyebileceğini belirler.

24.3 Yama yönetimi

“Çalışan sisteme dokunma” refleksi kritik üretim sistemlerinde anlaşılırdır; fakat yıllarca yama uygulanmaması da güvenlik stratejisi değildir. Doğru yöntem test, aşamalı dağıtım, geri dönüş planı ve envanterle kontrollü güncellemedir.

Yama kararı şu verilerle yönetilmelidir:

• bileşen gerçekten kullanılıyor mu?
• güvenlik açığı bizim yapılandırmamızda erişilebilir mi?
• istismar biliniyor mu veya aktif istismar var mı?
• bileşen hangi güven sınırında?
• telafi edici kontrol var mı?
• güncellemenin operasyonel riski nedir?

Risk kabulü süreli ve kayıtlı olmalıdır. “Şimdilik dokunmuyoruz” kararı sonsuz erteleme anlamına gelmemelidir.

25. Active Directory: kimlik sistemi aynı zamanda saldırı grafıdır

Active Directory ortamında kullanıcı, bilgisayar, grup, oturum, ACL, GPO, servis hesabı ve trust ilişkileri birlikte değerlendirilmelidir. BloodHound'un graf yaklaşımı bu karmaşıklığı görünür kılar.

Bir kullanıcının doğrudan Domain Admin grubunda olmaması güvenli olduğu anlamına gelmez. Kullanıcı A, Grup B üzerinde değişiklik yetkisine; Grup B, Bilgisayar C üzerinde yerel yönetici yetkisine; Bilgisayar C'de Domain Admin oturumuna erişim olanağına sahip olabilir. Saldırgan açısından kritik olan doğrudan üyelik değil ulaşılabilir yoldur.

25.1 BloodHound'u yalnız kırmızı takım aracı olarak görmemek

BloodHound, saldırı yolunu saldırgandan önce görmek için savunmada da kullanılabilir. Özellikle şu sorular değerlidir:

• yüksek değerli varlıklara en kısa yollar neler?
• hangi kullanıcı veya grup beklenmedik derecede merkezi?
• hangi servis hesapları fazla yetkili?
• hangi bilgisayarlardaki oturumlar kimlik zincirini büyütüyor?
• ACL üzerinden gizli yetki yükseltme yolları var mı?
• GPO veya delegation ilişkileri hangi yolları açıyor?

Grafı periyodik karşılaştırmak, yeni bir grup üyeliğinin veya ACL değişikliğinin saldırı yolu oluşturup oluşturmadığını gösterebilir.

25.2 Kerberos'u protokol olarak anlamak

Kerberos yalnız “ticket kullanan Windows kimlik doğrulaması” değildir. Ticket Granting Ticket (TGT), Ticket Granting Service (TGS), KDC, SPN ve anahtar ilişkisini anlamadan Kerberoasting, AS-REP Roasting veya ticket saldırılarını doğru değerlendirmek zordur.

Kerberoasting'in savunma açısından önemli dersi şudur: servis hesabının parolası çevrimdışı tahmine konu olabilir. Bu nedenle servis hesabı parolasının uzun, rastgele ve yönetilen olması; mümkün olduğunda Group Managed Service Account gibi mekanizmaların kullanılması; eski şifreleme türlerinin ve gereksiz SPN'lerin azaltılması önemlidir.

AS-REP Roasting ise Kerberos ön kimlik doğrulaması devre dışı bırakılmış hesapların neden özel risk taşıdığını gösterir. Kullanılmayan eski yapılandırmaların “çalışıyor, dokunmayalım” diye kalması kimlik sisteminde saldırı yüzeyi üretir.

25.3 Pass-the-Hash ve Pass-the-Ticket'in öğrettiği ayrım

Saldırgan her zaman açık metin parolaya ihtiyaç duymaz. Kimlik doğrulama mekanizmasının kabul ettiği hash veya ticket ele geçirildiğinde bunlar yeniden kullanılabilir. Bu, sır yönetiminde “parolayı göremedi, güvendeyiz” varsayımının hatalı olduğunu gösterir.

Bellek ve kimlik bilgisi korumaları, ayrı yönetici hesapları, ayrıcalıklı oturumların düşük güvenli istemcilerde açılmaması, SMB/NTLM kullanımının azaltılması ve modern kimlik güvenlik özellikleri bu riskin parçalarını azaltır.

25.4 krbtgt ve etki alanı güven kökü

Etki alanının kritik sırlarından biri krbtgt hesabıyla ilişkilidir. Bu seviyedeki bir ihlal normal kullanıcı parolası değişikliğiyle çözülemez. Olay müdahalesi etki alanı güven modelini ve ticket yaşam döngüsünü hesaba katmalıdır.

Bu örnek, kritik kimlik materyalinin envanterde ayrıca sınıflandırılması gerektiğini gösterir. Her parola aynı değildir; bazı sırların ele geçirilmesi bütün güven alanını etkiler.

26. Ağ güvenliği: paketi görmeden varsayım üretmeyin

Wireshark ve tcpdump ile çalışmak, ağ güvenliğini soyut diyagramdan gerçek paketlere indirir. Bir uygulamanın “HTTPS kullanıyor” dediği durumda DNS sorgusunun, TLS el sıkışmasının, yönlendirme davranışının ve gerçek hedefin görülmesi birçok yanlış varsayımı ortaya çıkarabilir.

26.1 Paket analizi neden hâlâ önemlidir?

Modern sistemlerde trafik şifreli olsa bile şu meta veriler değerlidir:

• kaynak ve hedef,
• port ve protokol,
• bağlantı sıklığı,
• TCP bayrakları,
• paket boyutları,
• DNS istekleri,
• TLS handshake bilgileri,
• yeniden iletimler,
• bağlantı kurma ve kapatma davranışı.

Uygulama katmanında loglanmayan bir davranış ağ katmanında görülebilir. Tersine, ağ katmanındaki anomaliyi yorumlamak için uygulama bağlamı gerekir.

26.2 Segmentasyon

Düz ağ saldırgana yanal hareket için geniş alan verir. Segmentasyonun amacı VLAN sayısını artırmak değil, güven sınırlarını ağ üzerinde uygulamaktır.

Örneğin:

İnternet -> Ters Vekil: 443
Ters Vekil -> Uygulama: 8443
Uygulama -> DB: 5432
Uygulama -> Kimlik Servisi: 443
Yönetim Ağı -> Sunucular: yönetim portları
Diğer her şey: reddet

Bu politika yalnız giriş trafiğine değil çıkış trafiğine de uygulanmalıdır. RCE alan uygulama sunucusunun internette her adrese ve iç ağdaki her porta bağlanabilmesi saldırganın seçeneklerini artırır.

26.3 Güvenlik duvarı uygulama açığını çözmez

Firewall, belirli ağ akışlarını sınırlar. İzin verilen 443 portundaki uygulama SQL injection içeriyorsa firewall bunu otomatik çözmez. WAF bazı saldırı yüklerini engelleyebilir; ancak uygulama güvenlik açığının kök nedenini ortadan kaldırmaz.

En iyi kullanım, kontrolleri görevlerine göre konumlandırmaktır:

• firewall: ağ erişim sınırı,
• WAF: belirli web saldırı örüntülerine ek koruma ve görünürlük,
• uygulama: iş mantığı, yetki, veri/komut ayrımı,
• IDS/IPS: şüpheli davranışı tespit/engelleme,
• SIEM: olayları birleştirme ve korelasyon.

27. IDS/IPS, Snort, Suricata ve Wazuh: gördüğümüz şeyi anlamlandırmak

Önleme katmanlarının hiçbiri kusursuz değildir. Bu nedenle sistemin saldırı belirtilerini gözleyebilmesi gerekir.

Snort ve Suricata ağ trafiği üzerinde imza ve davranış temelli algılama sağlayabilir. Wazuh gibi platformlar uç nokta olaylarını, dosya bütünlüğünü, güvenlik loglarını, güvenlik açığı verilerini ve çeşitli alarm kaynaklarını merkezi değerlendirmeye taşıyabilir.

27.1 İmza ile gerçek olay arasındaki fark

Bir IDS kuralı pakette belirli örüntüyü gördüğünde alarm üretebilir. Fakat bu her zaman başarılı saldırı değildir. Aynı saldırı yükü savunmasız olmayan sürüme gitmiş olabilir; test ortamından gelmiş olabilir; saldırı denemesi uygulama tarafından reddedilmiş olabilir.

Tersine, yalnız bilinen imzaları aramak yeni veya değiştirilmiş davranışı kaçırabilir.

Bu nedenle güvenlik izleme üç bağlamı birleştirmelidir:

Ağ olayı
 + uygulama olayı
 + kimlik olayı
 + varlık bağlamı
 + zaman
 = daha anlamlı alarm

Örneğin aynı kaynaktan önce yüzlerce başarısız giriş, sonra başarılı giriş, ardından alışılmadık veri dışa aktarımı görülmesi tek tek üç normal log satırı gibi değerlendirilemez.

27.2 Yanlış pozitif ve yanlış negatif

Güvenlik operasyonunda çok alarm iyi algılama demek değildir. Sürekli yanlış alarm üreten kural, operatör tarafından zihinsel olarak kapatılır. Buna alarm yorgunluğu eşlik eder.

Bir kural şu metriklerle izlenebilir:

• günlük alarm sayısı,
• doğrulanan olay oranı,
• yanlış pozitif oranı,
• tespit süresi,
• müdahale süresi,
• kapsadığı saldırı tekniği,
• veri kaynağının güvenilirliği.

Tuning, alarmı susturmak değil sinyal/gürültü oranını iyileştirmektir.

27.3 MITRE ATT&CK ile görünürlük matrisi

MITRE ATT&CK'in güncel Enterprise matrisi saldırgan davranışlarını taktik ve teknikler altında sınıflandırır. ATT&CK v19.2, 28 Nisan 2026 itibarıyla güncel sürümdür. Bunu “bütün teknikleri engelleyelim” listesi olarak kullanmak yerine şu soruyu sormak daha değerlidir:

Bizim tehdit modelimizde muhtemel tekniklerin hangilerini görebiliyoruz?

Bir teknik için önleme mümkün olmayabilir ama güvenilir tespit olabilir. Bazı tekniklerde ise tespit yerine mimari olarak yolu kapatmak daha doğru olur.

28. Erişilebilirlik güvenliği: DoS/DDoS bir performans probleminden fazlasıdır

DoS ve DDoS çalışmalarında paket üretme araçları, SYN flood, UDP flood, amplification ve benzeri örnekler saldırının ağ davranışını anlamak için yararlıdır. Fakat modern uygulamada erişilebilirlik yalnız bant genişliği değildir.

Bir sistem şu kaynaklardan herhangi biri tükenerek hizmet dışı kalabilir:

• ağ bant genişliği,
• connection table,
• thread veya event-loop kapasitesi,
• CPU,
• bellek,
• dosya descriptor,
• DB connection pool,
• sorgu kapasitesi,
• disk I/O,
• queue backlog,
• üçüncü taraf API kotası,
• pahalı kriptografik işlem,
• log diski.

28.1 Uygulama katmanı DoS

Bir uç nokta tek istekle yüz milyon satırlık rapor üretiyorsa saldırganın milyonlarca paket göndermesine gerek yoktur. On pahalı istek yüz bin ucuz istekten daha etkili olabilir.

Bu nedenle hız sınırlama yalnız istek sayısına değil iş maliyetine göre düşünülmelidir. Arama sorgusuna maksimum zaman, sayfalama sınırı, dosya boyutu sınırı, concurrency bütçesi ve backpressure uygulanabilir.

28.2 Kuyruk her zaman dayanıklılık değildir

Mesaj kuyruğu ani yükü absorbe edebilir. Ancak üretim hızı tüketim hızından uzun süre yüksekse backlog büyür ve yalnız çöküş zamanını erteler. Little's Law gibi temel kuyruk teorisi güvenlikte de önemlidir: saldırgan sistemi kaynak tüketim rejimine sokabiliyorsa kapasite planı savunmanın parçasıdır.

28.3 DDoS savunmasında katmanlar

Yüksek hacimli ağ DDoS saldırısını yalnız uygulama sunucusunda çözmeye çalışmak mümkün olmayabilir. Upstream sağlayıcı, CDN/edge, scrubbing, hız sınırlama, SYN korumaları ve uygulama düzeyi maliyet kontrolü birlikte ele alınır.

Adli analiz açısından paket örnekleri, NetFlow/IPFIX benzeri akış verileri, load balancer logları ve uygulama metrikleri olayın tipini ve etkisini belirlemek için saklanmalıdır.

29. Mobil uygulama güvenliği: istemciyi düşman ortamda çalıştırmak

Mobil uygulama, kontrol ettiğimiz sunucunun uzantısı değildir. Kullanıcının cihazında çalışır; cihaz root/jailbreak olabilir, trafik proxy'lenebilir, binary analiz edilebilir ve runtime davranışı değiştirilebilir.

Bu nedenle şu kontroller sunucu tarafına ait kalmalıdır:

• yetkilendirme,
• fiyat ve kritik iş kuralı,
• hesap statüsü,
• işlem limiti,
• veri sahipliği,
• kritik bütünlük kararı.

29.1 Certificate pinning'in doğru yeri

Pinning bazı tehdit modellerinde MITM direncini yükseltebilir; özellikle yönetilen mobil uygulamalarda ek kontrol olarak değerlendirilebilir. Ancak sertifika/anahtar döndürme, acil durum, CDN ve işletim maliyeti oluşturur. Yanlış pinning servis kesintisine yol açabilir.

Güvenlik testinde pinning'in devre dışı bırakılabilmesi, uygulama protokolünün test edilmesine yardım eder. Buradan çıkarılacak savunma dersi “pinning kırılabiliyor, gereksiz” değildir. Asıl ders istemci üzerindeki kontrolün nihai güven sınırı olmadığıdır.

29.2 Yerel veri

Mobil cihazda şu veriler dikkatle ele alınmalıdır:

• access/yenileme belirteci,
• kullanıcı verisi cache'i,
• loglar,
• SQLite veritabanı,
• indirilen dosyalar,
• clipboard,
• ekran görüntüleri,
• çökme dump,
• push notification içeriği.

Platformun güvenli saklama mekanizmaları kullanılmalı, gereksiz veri kalıcılığı azaltılmalıdır.

30. Yazılım tedarik zinciri: sizin yazmadığınız kod da sizin saldırı yüzeyinizdir

Modern uygulamaların büyük bölümü üçüncü taraf kütüphanelerden oluşur. Güvenlik açığı artık yalnız kendi kaynak kodunuzda bulunmaz; bağımlılık, derleme eklentisi, konteyner temel imajı, CI eylemi, paket deposu veya derleme altyapısı üzerinden gelebilir.

OWASP Top 10:2025'te Software Supply Chain Failures'ın A03 olarak yer alması bu değişimin önemini gösterir.

30.1 Bağımlılık envanteri

“Log4j kullanıyor muyuz?” sorusuna hızlı cevap veremeyen ekip, güvenlik açığı duyurulduğunda saatler veya günler kaybeder. SBOM bu nedenle yararlıdır. Fakat SBOM üretip hiç kullanmamak güvenlik değildir.

Envanter şu bilgileri mümkün olduğunca taşımalıdır:

• paket adı ve sürüm,
• kaynağı,
• doğrudan/dolaylı bağımlılık,
• hash veya bütünlük bilgisi,
• lisans,
• kullanıldığı artefakt,
• destek/yaşam döngüsü durumu.

30.2 Dependency confusion ve paket kaynağı

Kurumsal paket adı dış registry'de saldırgan tarafından yayımlanabiliyor ve derleme sistemi yanlış kaynağı tercih ediyorsa aynı isimdeki paket tedarik zincirine girebilir. Paket yöneticisi yapılandırması, namespace kontrolü, özel registry kullanımı ve lockfile/integrity doğrulaması bu nedenle önemlidir.

30.3 Derleme ortamı kritik varlıktır

CI/CD sistemi üretime yazılım gönderebiliyorsa üretim yetkisine sahiptir. Derleme çalıştırıcısı, imzalama anahtarı, dağıtım belirteci ve kaynak kodu deposu yetkileri kritik kimlik materyalidir.

Güvenli zincirde:

Kaynak
  -> gözden geçirilmiş değişiklik
  -> kontrollü bağımlılıklar
  -> izole derleme
  -> test
  -> SBOM/provenance
  -> imzalı artefakt
  -> doğrulanan dağıtım

Artefakt'ın hangi commit'ten, hangi bağımlılıklarla ve hangi derleme ortamında üretildiğini kanıtlayabilmek olay müdahalesinde de değerlidir.

31. CI/CD güvenliği: otomasyonun yetkisi insanı geçebilir

CI/CD işlem hattı genellikle kaynak kodu okuyabilir, secret kullanabilir, artefakt yayımlayabilir ve üretime dağıtabilir. Bu nedenle “yardımcı araç” değil ayrı bir güven alanıdır.

31.1 Pull istek güven sınırı

Dış katkı veya güvenilmeyen branch kodu, secret erişimi olan runner üzerinde otomatik çalıştırılmamalıdır. Derleme betiği'in kendisi koddur; saldırgan test dosyasına bile secret exfiltration davranışı ekleyebilir.

31.2 Sırlar kısa ömürlü olmalı

Mümkün olduğunda statik uzun ömürlü cloud/API anahtarları yerine workload identity ve kısa ömürlü kimlik bilgisi kullanılmalıdır. Bu, sızıntı penceresini küçültür ve döndürmeyi kolaylaştırır.

31.3 Güvenlik kapıları

İşlem hattı'a her tarayıcıyı eklemek kalite sağlamaz. Gürültülü ve bağlamsız araç geliştiricinin güvenlik bulgularını görmezden gelmesine neden olur.

Daha iyi politika:

• yeni kritik/yüksek bulguda derlemeyi durdur,
• mevcut teknik borcu ayrı baseline ile izle,
• secret sızıntısını kesin hata yap,
• dependency riskinde istismar edilebilirlik ve çalışma bağlamını değerlendir,
• artefakt bütünlüğünü dağıtım öncesi doğrula,
• yanlış pozitif için kayıtlı ve süreli istisna kullan.

32. Güvenlik testi: tek araç hiçbir zaman yeterli değildir

Statik analiz, dinamik analiz, dependency taraması, fuzzing ve sızma testi aynı şeyi yapmaz. Birinin bulamadığını diğerinin bulması beklenir.

| Yöntem | Güçlü olduğu alan | Kör noktası | |---|---|---| | Kod inceleme | İş mantığı, bağlam, tasarım niyeti | İnsan zamanı, kapsam | | SAST | Kaynakta tehlikeli veri akışları, örüntüler | Yanlış pozitif, runtime bağlamı | | DAST | Çalışan uygulamanın dış davranışı | Kodun tamamını göremez | | SCA | Bilinen bağımlılık açıkları | Özel kod ve yanlış kullanım | | Fuzzing | Ayrıştırıcı, bellek ve beklenmeyen girdi hataları | Doğru harness/oracle gerektirir | | Sızma testi | Zincirleme, iş mantığı, gerçek saldırgan bakışı | Zamanla sınırlı örnekleme | | Yapılandırma denetimi | Güvenlik ayarları, sıkılaştırma | Uygulama mantığı |

32.1 SAST çıktısını doğrulamak

Statik analiz bir fonksiyona SQL Injection etiketi koyduğunda bunu otomatik gerçek açık kabul etmek kadar “araç hep yanlış söylüyor” diyerek kapatmak da hatalıdır. Veri kaynağından sink'e kadar akış incelenmelidir. Parametre binding gerçekten kullanılıyor mu? Dinamik query parçası var mı? İzin listesi doğru mu?

32.2 DAST ve Burp Suite

Proxy tabanlı web testi HTTP'nin gerçek hâlini görünür kılar. UI'nin göndermediği alan eklenebilir, ID değiştirilebilir, method değiştirilebilir, header kaldırılabilir. Bu deneyim yazılım geliştirici için önemlidir; istemci kontrollerinin güvenlik sınırı olmadığını elle gösterir.

Testin hedefi yalnız saldırı yükü çalıştırmak değildir. Sistematik olarak authn, authz, validation, state transition, hata davranışı ve concurrency incelenmelidir.

32.3 Fuzzing

Fuzzing özellikle native ayrıştırıcı, dosya biçimi, protokol ve karmaşık veri dönüştürücülerde değerlidir. Rastgele byte üretmekten daha fazlasıdır; coverage-guided fuzzing programın yeni yollarına ulaşan girdileri seçerek arama uzayını etkili kullanabilir.

Çökme bulunduğunda süreç bitmez:

1. tekrar üretilebilir mi?
2. en küçük girdiye indirgenebilir mi?
3. memory sanitizer ne gösteriyor?
4. attacker-controlled hangi veri hangi yapıyı bozuyor?
5. güvenlik etkisi var mı?
6. aynı kök neden başka ayrıştırıcı yollarında var mı?

Bir çökme'i yalnız patch'lemek yerine hata sınıfını kapatmak daha değerlidir.

33. Sızma testi: taramadan farklı bir mühendislik faaliyeti

Zafiyet tarayıcısı bilinen problemleri ölçekli biçimde bulur. Sızma testi ise saldırgan gibi düşünerek kontrollerin birbirine nasıl bağlandığını inceler.

İyi bir test akışı şu disipline sahiptir:

Kapsam
 -> pasif keşif
 -> aktif keşif
 -> saldırı yüzeyi
 -> güvenlik açığı hipotezi
 -> kontrollü doğrulama
 -> yetki yükseltme olasılığı
 -> yanal hareket olasılığı
 -> etki doğrulaması
 -> kanıt
 -> temizleme
 -> kök neden
 -> düzeltme
 -> yeniden test

“İstismar başarılı” tek başına rapor değildir. Hangi önkoşul gerekti, hangi kontrol eksikti, saldırgan ne elde etti, gerçek iş etkisi neydi, nasıl tespit edilebilirdi ve kök neden nasıl kapatılacak soruları cevaplanmalıdır.

33.1 Metasploit'in doğru öğretim değeri

Metasploit hızlı doğrulama için güçlü bir çerçevedir; fakat modül çalıştırmayı bilmek güvenlik açığını anlamakla aynı değildir. En yararlı yaklaşım, modülün ne yaptığını protokol ve hedef davranışıyla birlikte okumaktır.

Bir istismar şu zinciri izliyorsa:

hedef sürümü tanı
 -> özel isteği oluştur
 -> bellek/logic hatasını tetikle
 -> kontrol elde et
 -> saldırı yükü çalıştır

savunma her adımı farklı yerde kesebilir. Sürüm yükseltmek kök açığı kapatabilir; WAF belirli isteği geçici olarak engelleyebilir; process sandbox etkiyi azaltabilir; EDR post-istismaration davranışını görebilir. Hangisinin kalıcı, hangisinin telafi edici kontrol olduğunu ayırmak gerekir.

34. Sosyal mühendislik: insanı “en zayıf halka” diye suçlamak yetmez

Kevin Mitnick'in sosyal mühendislik örneklerinin kalıcı tarafı belirli telefon senaryoları değildir. İnsanların otorite, aciliyet, yardım etme isteği, merak ve alışkanlık üzerinden karar vermesidir.

“İnsan en zayıf halkadır” cümlesi çoğu zaman tasarım sorumluluğunu kullanıcıya atar. Daha doğru soru şudur: bir insanın tek yanlış kararı ne kadar etki yaratabiliyor?

Bir kullanıcı oltalama sayfasına parola girdiğinde phishing-resistant MFA saldırıyı kesebilir. Yardım masası telefonla MFA'yı kaldırabiliyorsa teknik kontrol dolanılabilir. Yönetici kullanıcısı günlük e-postasını yüksek ayrıcalıklı hesapla okuyorsa oltalamanın etkisi büyür.

34.1 Süreç de güvenlik kontrolüdür

Özellikle şu işlemler sosyal mühendisliğe dayanıklı tasarlanmalıdır:

• parola/MFA sıfırlama,
• yeni cihaz kaydı,
• ayrıcalıklı grup üyeliği,
• para veya hassas veri transferi,
• uzaktan erişim açma,
• üçüncü taraf kullanıcı oluşturma,
• acil durum istisnaları.

Kimlik doğrulama sorularının cevabı internette bulunabiliyorsa güvenlik sorusu değildir. “Müdür istedi” tek başına yetki kanıtı değildir. Kritik işlemde bağımsız ikinci kanal veya ikinci onay insan hatasının etkisini azaltır.

34.2 Güvenlik farkındalığı ölçülmelidir

Yılda bir kez sunum izletmek güvenlik programı değildir. Eğitim, iş rolüne göre gerçek davranışa dönüşmelidir. Oltalama simülasyonu yalnız “kim tıkladı?” metriğine indirgenirse korku üretir. Daha yararlı metrikler:

• şüpheli mesajı raporlama süresi,
• doğru kanala raporlama oranı,
• yardım masasının kimlik doğrulama prosedürüne uyumu,
• ayrıcalıklı kullanıcıların güvenli istemci kullanımı,
• olaydan sonra aynı hata sınıfının tekrarı.

Amaç kullanıcıyı sınamak değil, sistemin insan hatasına dayanıklılığını geliştirmektir.

35. Loglama: olaydan sonra “keşke kaydetseydik” dememek

Güvenlik logu uygulamanın hata ayıklama logundan farklıdır. Hata ayıklama log geliştiriciye hata ayıklamada yardımcı olur; güvenlik logu bir güvenlik kararının, kimlik olayının veya önemli durum değişikliğinin denetlenebilir kaydını tutar.

35.1 Neyi kaydetmeli?

Bağlama göre şu olaylar değerlidir:

• başarılı/başarısız kimlik doğrulama,
• MFA kayıt ve sıfırlama,
• parola değişimi,
• ayrıcalık değişimi,
• kullanıcı/servis hesabı oluşturma ve kapatma,
• kritik veri okuma/yazma/silme,
• yetkilendirme reddi,
• yönetim işlemleri,
• güvenlik ayarı değişiklikleri,
• belirteç/anahtar yaşam döngüsü olayları,
• dosya yükleme ve indirme,
• toplu export,
• rate limit tetiklenmesi,
• beklenmeyen ayrıştırıcı veya doğrulama hataları.

Log olayında en az zaman, aktör, kaynak, işlem, hedef, sonuç ve korelasyon kimliği bulunması çoğu analizi kolaylaştırır.

35.2 Neyi kaydetmemeli?

• parola,
• tam oturum belirteç,
• özel anahtar,
• kredi kartı gibi gereksiz hassas veri,
• kullanıcı tarafından girilen sırlar,
• bütün istek body'yi körlemesine.

Log enjeksiyonu da düşünülmelidir. Kullanıcı girdisi newline veya kontrol karakteriyle log biçimini bozmamalı; yapılandırılmış log kullanımı analizi kolaylaştırır.

35.3 Zaman senkronizasyonu

Dağıtık sistemde olay sırasını kurmak için saatlerin tutarlı olması gerekir. Adli incelemede birkaç dakikalık sapma bile farklı sistemlerden gelen olayları yanlış sıraya sokabilir. NTP/kurumsal zaman kaynağı, log mimarisinin sessiz ama kritik bileşenidir.

36. Olay müdahalesi: saldırı olduğunda ilk kez düşünmeye başlamamak

Güvenlik açığı yönetimi saldırı öncesini, olay müdahalesi saldırı anı ve sonrasını yönetir. Plan üretimde olay yaşandığında ilk kez yazılıyorsa geç kalınmıştır.

NIST CSF 2.0'ın Govern, Identify, Protect, Detect, Respond ve Recover fonksiyonları bu sürekliliği iyi ifade eder.

36.1 Hazırlık

Olaydan önce bilinmesi gerekenler:

• kritik sistem sahipleri,
• iletişim zinciri,
• log ve kanıt kaynakları,
• izolasyon yetkisi,
• hesap/anahtar iptal mekanizması,
• yedek ve geri yükleme yöntemi,
• hukuki/kurumsal bildirim gereksinimleri,
• olay sınıflandırması,
• temiz sistem kurulum kaynağı.

36.2 Tespit ve doğrulama

Her IDS alarmı olay değildir. Fakat “yanlış pozitiftir” varsayımıyla kapatmak da risklidir. Alarmın varlık bağlamı, kullanıcı davranışı ve diğer loglarla korelasyonu yapılır.

36.3 Sınırlama

Containment saldırganın yayılmasını durdurur. Ağ izolasyonu, hesabın devre dışı bırakılması, belirteç iptali, anahtar döndürme veya servis erişiminin sınırlandırılması gerekebilir.

Burada kritik karar delili korumak ile operasyonu sürdürmek arasındadır. Körlemesine sunucuyu kapatmak volatil bellekteki önemli kanıtı kaybettirebilir; sistemi açık bırakmak saldırganın ilerlemesine izin verebilir. Olay türüne göre playbook gerekir.

36.4 Temizleme ve kurtarma

Saldırganın bıraktığı dosyayı silmek yeterli olmayabilir. Kalıcılık mekanizması, yeni hesap, scheduled task, servis, SSH key, OAuth consent, GPO değişikliği veya başka bir arka kapı bulunabilir.

Güvenilir kurtarma, bilinen temiz durumdan yeniden kurulum gerektirebilir. “Antivirüs temizledi” ifadesi her olay için yeterli güvence değildir.

36.5 Kök neden

Olay kapatıldıktan sonra en değerli soru “hangi IP saldırdı?” olmayabilir. Şunlar daha kalıcı sonuç üretir:

• saldırgan ilk erişimi nasıl aldı?
• neden bu erişim kritik varlığa ulaşabildi?
• hangi kontrol çalışmadı?
• hangi log eksikti?
• benzer zayıflık başka sistemlerde var mı?
• süreç hangi değişikliği yapmalı?

Aynı olay sınıfı tekrar ediyorsa yalnız IOC temizlenmiştir; sistem öğrenmemiştir.

37. Adli bilişim: kanıtın güvenilirliğini korumak

Adli bilişim güvenlik olayının yalnız “ne oldu?” sorusuna değil, ne zaman, hangi sıra ile, hangi kanıtla sorularına cevap verir.

37.1 Volatil ve kalıcı veri

Olay sırasında bazı bilgiler sistem kapanınca kaybolabilir:

• çalışan süreçler,
• ağ bağlantıları,
• memory-resident kimlik bilgisi veya artefakt,
• geçici dosya sistemi bilgileri,
• process memory.

Disk, log, registry, dosya sistemi metadata'sı ve merkezi kayıtlar daha kalıcı olabilir. Toplama sırası olay bağlamına göre belirlenmelidir.

37.2 Bütünlük

Kanıt kopyalanırken hash alınması ve zincirleme teslim kayıtlarının tutulması, sonradan verinin değişmediğini göstermek için önemlidir. İnceleme orijinal kanıt üzerinde yapılmamalı; mümkün olduğunda doğrulanmış kopyalar kullanılmalıdır.

Bu disiplin yalnız hukuki süreç için değil teknik güvenilirlik için de değerlidir. “Bu dosya saldırgan bıraktı” diyebilmek için olay müdahalesi sırasında analistin dosyayı kendisinin üretmediğini gösterebilmesi gerekir.

37.3 Uygulama geliştiricinin adli bilişime katkısı

Geliştirici log tasarımını yaparken ileride olay analizi yapılacağını düşünmelidir. İstek korelasyon kimliği, kullanıcı/servis kimliği, güvenlik kararı sonucu ve veri değişikliği kimliği olay zincirini kurmayı kolaylaştırır.

Aşırı log da çözüm değildir; kişisel veri, sır ve yüksek hacimli gürültü hem risk hem maliyet üretir. Amaç sonradan anlamlı soruları cevaplayacak kadar kanıt bırakmaktır.

38. Güvenlik açığı yönetimi: tarama sonucu yaşam döngüsünün başlangıcıdır

Bir CVE bulunduğunda ilk refleks “patch var mı?” olabilir. Fakat büyük ortamlarda önceliklendirme gerekir.

Bir bulgu için şu kayıt yararlıdır:

Varlık
Bileşen / sürüm
CVE / CWE
Maruziyet
İstismar önkoşulu
Aktif istismar bilgisi
İş etkisi
Mevcut kontroller
Önerilen kalıcı düzeltme
Geçici azaltım
Sorumlu
Hedef tarih
Yeniden test sonucu

38.1 Yalnız versiyon eşleşmesi yetmez

SCA aracının vulnerable sürüm bulması, açık kod yolunun uygulamada erişilebilir olduğunu her zaman göstermez. Tersi de önemlidir: “şu anda reachable değil” kararı, gelecekte kod yolu değiştiğinde geçersiz olabilir. Bu nedenle en iyi çözüm mümkün olduğunda güncellemektir; reachability bilgisi önceliklendirme için kullanılır.

38.2 Güvenlik borcu

Bir bulgu için “risk kabul edildi” demek onu yok etmez. Kabul kararı süreli olmalı, sahibi olmalı ve hangi telafi edici kontrole dayandığı yazılmalıdır. Son kullanma tarihi olmayan istisna güvenlik politikasının kalıcı deliğine dönüşür.

39. Güvenlik yanlış yapılandırmaları: kod doğru, sistem yine açık

OWASP Top 10:2025'te Security Misconfiguration'ın ikinci sırada bulunması, güvenlik açığının yalnız kaynak kodu olmadığını hatırlatır.

Yaygın örnekler:

• varsayılan hesaplar,
• hata ayıklama modunun açık olması,
• directory listing,
• gereksiz HTTP method'ları,
• ayrıntılı stack trace,
• herkese açık yönetim arayüzü,
• geniş CORS,
• bulut/storage public erişimi,
• gereksiz servisler,
• zayıf TLS yapılandırması,
• test anahtarının üretimde kullanılması,
• örnek uç nokta veya actuator/management yüzeyinin korunmaması.

Configuration as Code burada avantaj sağlar: ayarlar gözden geçirilebilir, sürümlenebilir ve otomatik test edilebilir. Ancak secret'ları aynı repository'ye koymak çözüm değildir.

40. Güvenlik ve performans birbirinin düşmanı olmak zorunda değildir

Kritik ve yüksek trafikli sistemlerde güvenlik kontrolü tasarlarken gecikme, throughput ve kaynak tüketimi göz ardı edilirse ekip sonunda kontrolü kapatmaya yönelir. Bu yüzden güvenlik mekanizması da performans mühendisliği ister.

40.1 Parola hash maliyeti

Argon2id maliyeti ne kadar yüksekse o kadar iyi değildir. Kimlik doğrulama servisinin kapasitesi ölçülmeden aşırı parametre seçmek meşru kullanıcılar için DoS vektörü oluşturabilir. Hedef, saldırganın çevrimdışı tahmin maliyetini artırırken meşru çevrimiçi doğrulamanın kapasitesini yönetmektir.

40.2 Belirteç doğrulama mimarisi

Her istekte yetkilendirme sunucusu'a senkron belirteç introspection çağrısı yapmak merkezi servisi darboğaza dönüştürebilir. İmzalı JWT ile yerel doğrulama latency ve bağımlılığı azaltır; karşılığında iptal ve yetki değişikliğinin yayılma süresi gibi problemler oluşur.

Burada güvenlik–performans değiş tokuşu ölçülmelidir:

• belirteç ömrü,
• key rotation,
• revocation gereksinimi,
• cache,
• kritik işlemde yeniden doğrulama,
• audience daraltma.

40.3 Loglama

Her istek body'yi senkron diske yazmak performans ve gizlilik problemi yaratır. Yapılandırılmış, sınırlı güvenlik olayları; uygun buffer/queue; backpressure politikası ve log kaybı davranışı açık tasarlanmalıdır.

Güvenlik kontrolü sistemin çalışma modeline uymazsa kâğıt üzerinde kalır.

41. Güvenlik ve kullanılabilirlik: kullanıcıyı kontrolü aşmaya zorlamamak

İnsanların tahmin edilebilir davranışları yalnız saldırı değil tasarım girdisidir. Çok karmaşık parola kuralları parolanın yazılmasına veya tekrar kullanılmasına neden olabilir. Her işlemde gereksiz MFA istemek kullanıcıyı onay bildirimlerine duyarsızlaştırabilir. Aşırı kısa oturum süresi çalışma akışını bozup güvensiz workaround üretebilir.

Güvenli tasarımın hedefi kullanıcıyı cezalandırmak değildir. CISA'nın Secure by Design yaklaşımındaki “müşteri güvenlik yükünü tek başına taşımamalı” ilkesi burada da geçerlidir.

En iyi kontrol mümkün olduğunca:

• varsayılan açık,
• anlaşılır,
• iş akışına uygun,
• güvenli hata veren,
• kullanıcının güvenliği kapatmasını gerektirmeyen

bir davranış üretir.

42. Kod incelemede saldırgan gibi okumak

Güvenlik kod incelemesi yalnız eval, exec, string query veya hardcoded password aramak değildir. Kodun güven varsayımlarını okumaktır.

Bir uç nokta incelerken şu sıra etkilidir:

Girdi nereden geliyor?
 -> kimlik nasıl kuruluyor?
 -> yetki nerede kontrol ediliyor?
 -> veri normalize/doğrulanıyor mu?
 -> hangi yorumlayıcıya gidiyor?
 -> hangi kaynağı tüketiyor?
 -> hangi sır/yetkiyle işlem yapıyor?
 -> hata yolunda ne oluyor?
 -> olay nasıl loglanıyor?

Bu yöntem dil ve uygulama çerçevesinden bağımsızdır.

42.1 Tehlikeli kolaylıklar

Uygulama çerçeveleri güvenlik yükünü azaltır; yanlış kullanımda ise açığı standartlaştırabilir. Şunlar özellikle dikkat ister:

• entity'yi doğrudan istek body'ye bind etmek,
• joker karakterli CORS,
• CSRF'yi nedenini anlamadan kapatmak,
• TLS doğrulamasını test için devre dışı bırakıp unutmak,
• template'e raw HTML vermek,
• query string birleştirmek,
• object deserialization'ı geniş tiplerle açmak,
• dosya yolunu kullanıcı girdisinden üretmek,
• yetkilendirmeyi controller/UI seviyesinde bırakmak.

Güvenli uygulama çerçevesi kullanımı, varsayılan güvenlik mekanizmasını koruyup yalnız gerekçeli yerde değiştirmektir.

43. Spring Security'yi güvenlik ilkelerinin uygulaması olarak okumak

Spring Security eğitimlerinde filtre zinciri, SecurityFilterChain, kimlik doğrulama sağlayıcısı, kullanıcı ayrıntıları, CSRF, CORS, OAuth 2 ve yöntem düzeyi güvenlik gibi başlıklar ayrı ayrı öğrenilir. Üretim tasarımında bunların her birini daha temel soruya bağlamak gerekir.

• Kimlik doğrulama: kimlik hangi kanıta dayanıyor?
• Security context: doğrulanmış kimlik istek yaşam döngüsünde nasıl taşınıyor?
• Yetkilendirme: karar hangi kaynak ve işlem üzerinde veriliyor?
• Filter chain: güvenlik kararı uygulama kodundan önce hangi sırada uygulanıyor?
• CSRF: tarayıcının otomatik kimlik bilgisi gönderimi hangi saldırı yolunu açıyor?
• OAuth 2/OIDC: kimlik ve yetki farklı sistemler arasında nasıl aktarılıyor?
• JWT: kaynak sunucu assertion'ın bütünlüğünü ve kapsamını nasıl doğruluyor?

Sürüm bağımlı API'leri ezberlemek yerine bu model öğrenildiğinde uygulama çerçevesi değişse bile güvenlik mantığı korunur.

43.1 Güvenlik testleri regresyon testidir

Bir uç nokta için yetkilendirme testi yazılmadıysa yeniden düzenleme sırasında güvenlik kuralının kaybolması fark edilmeyebilir. Pozitif test kadar negatif test önemlidir:

ADMIN -> 200
USER  -> 403
Anonim -> 401
Başka kullanıcıya ait nesne -> 403/404 tasarımına göre

Aynı davranış method security, uç nokta kuralı ve alan yetkilendirmesi katmanlarında uygun testlerle korunmalıdır.

44. Hata ve istisna yönetimi: olağan dışı yol da tasarımın parçasıdır

Birçok sistem “happy path” üzerinde güvenlidir. Beklenmeyen durumda ise gizli ayrıntı döndürür, yetki kontrolünü atlar veya transaction'ı yarım bırakır.

OWASP Top 10:2025'in A10 kategorisi olan Mishandling of Exceptional Conditions bu alanı görünür kılar.

44.1 Ayrıştırıcı başarısızlığı

Geçersiz JSON, aşırı derin nesne, dev sayı, bozuk Unicode, çok büyük multipart veya beklenmeyen content type sistemin davranışını değiştirebilir. Ayrıştırıcı limitleri açık olmalıdır.

44.2 Transaction bütünlüğü

Kritik işlem üç adım yapıyor ve ikinci adım hata veriyorsa ilk adım geri alınacak mı? Dağıtık sistemde retry aynı işlemi iki kez üretebilir mi? Idempotency güvenlik açısından da önemlidir; ödeme, kota, yetki değişimi gibi işlemlerde tekrar gönderim saldırı veya veri bütünlüğü problemine dönüşebilir.

44.3 Error oracle

“Bu kullanıcı yok”, “parola yanlış”, “MFA cihazı bulunamadı” gibi ayrıntılar saldırgana hesap keşfi yaptırabilir. Her durumda tamamen aynı cevap vermek de kullanılabilirliği bozabilir. Tehdit modeline göre dış cevap ile iç log ayrılır.

45. DNS güvenliği: isim çözümleme bir güvenlik bağımlılığıdır

DNS çoğu mimari diyagramda ince bir okla geçilir; gerçekte uygulamanın kime bağlanacağını belirleyen temel altyapılardan biridir. DNS yanıtı yanlışsa TLS gibi üst katman kontrolleri doğru yapılandırılmadığı sürece istemci yanlış sisteme yönlenebilir. İç ağda DNS ayrıca Active Directory, servis keşfi ve çok sayıda yönetim işlevinin parçasıdır.

45.1 Zone transfer ve gereksiz envanter ifşası

Yetkisiz zone transfer, saldırgana alt alan adlarının ve host adlarının toplu listesini verebilir. Modern DNS sunucusunda transfer yalnız yetkili ikincil sunuculara sınırlandırılmalıdır. Buradaki ders yalnız AXFR değildir: yönetim işlevi ile genel hizmet aynı erişim modelini paylaşmamalıdır.

Bir DNS kaydının kendisi hassas olmayabilir; fakat vpn, dev, jenkins, backup, db, old-admin gibi adlar saldırı yüzeyinin keşif maliyetini düşürür. İsimlendirme güvenlik kontrolü değildir, fakat kullanılmayan kaydı kaldırmak saldırı yüzeyi yönetimidir.

45.2 DNS spoofing ve cache poisoning

DNS cache poisoning tarihsel olarak transaction ID ve kaynak port öngörülebilirliği gibi zayıflıklardan yararlandı. Modern resolver'lar daha güçlü rastgelelik ve ek korumalar kullanır; DNSSEC uygun senaryoda veri bütünlüğü ve kaynak doğrulaması sağlar. Fakat DNSSEC, DNS trafiğinin gizliliğini sağlamaz ve uygulama katmanındaki TLS doğrulamasının yerine geçmez.

Savunma katmanları:

• güvenilir ve güncel resolver,
• gereksiz recursion'ın dışarı kapatılması,
• zone transfer kısıtı,
• DNSSEC'in uygun alanlarda kullanımı,
• istemci–sunucu TLS kimlik doğrulaması,
• anormal DNS davranışının izlenmesi,
• iç ve dış DNS rolünün ayrılması gereken ortamlarda split-horizon tasarımının kontrollü uygulanması.

45.3 DNS aynı zamanda tespit kaynağıdır

Zararlı yazılımlar ve komuta-kontrol altyapıları sıklıkla DNS kullanır. Olağandışı uzun alt alan adları, yeni görülen domain'ler, yüksek hata oranı, domain generation algorithm davranışları veya normal iş profilinden sapan sorgular tespit sinyali olabilir.

Burada yine tek başına gösterge yeterli değildir. Yeni bir CDN veya telemetry servisi de benzer örüntü üretebilir. DNS logu varlık ve süreç bağlamıyla ilişkilendirildiğinde anlam kazanır.

46. ARP, MITM ve kablosuz ağ: yerel ağ da güvenilir değildir

Eski beyaz şapkalı hacker eğitimlerinde ARP spoofing/poisoning ve kablosuz ağ trafiği yakalama örnekleri, yerel ağdaki temel bir varsayımı çok net biçimde kırar: aynı LAN'da olmak kimlik kanıtı değildir.

ARP, IPv4 yerel ağında IP adresini MAC adresine eşlemek için tasarlanmıştır; güçlü kimlik doğrulama sağlamaz. Saldırgan uygun konumdaysa sahte ARP cevaplarıyla trafiği kendi üzerinden geçirmeye çalışabilir. Üst katmanda TLS doğru uygulanmışsa içeriğin okunması zorlaşır; sertifika doğrulaması kapatılmışsa veya kullanıcı yanlış sertifikayı kabul ediyorsa saldırı etkisi büyür.

46.1 “İç ağ güvenli” varsayımını kaldırmak

Yerel ağ saldırılarının savunma açısından en önemli sonucu, hizmet kimliğinin ağ konumuna bağlanmamasıdır. Bir istek kurumsal IP'den geliyor diye yetkili sayılmamalıdır. Yönetim arayüzünü yalnız iç ağa açmak yararlı bir katmandır fakat kimlik doğrulamanın yerine geçmez.

Ağ anahtarlarında DHCP snooping, Dynamic ARP Inspection, port security ve uygun segmentasyon gibi kontroller belirli ortamlarda yararlı olabilir. Yine de uçtan uca protokol kimlik doğrulaması korunmalıdır.

46.2 Kablosuz güvenlik

WEP tarihsel açıdan önemlidir çünkü kriptografik tasarım hatalarının pratikte nasıl hızlı kırılabildiğini gösterir; güncel sistemlerde kullanılmamalıdır. WPA/WPA2/WPA3 ailesinde güvenlik, mod ve yapılandırmaya bağlıdır. Kişisel ağlarda zayıf PSK çevrimdışı tahmin riskini büyütebilir. Kurumsal 802.1X/EAP dağıtımlarında istemcinin RADIUS sunucu sertifikasını doğru doğrulamaması evil-twin senaryolarını kolaylaştırabilir.

Kablosuz güvenlikte şu ilkeler daha kalıcıdır:

• eski ve kırılmış protokolleri kapatmak,
• güçlü ve benzersiz kimlik bilgisi,
• kurumsal kimlik doğrulamada sunucu sertifikasını doğrulamak,
• misafir ağını kurumsal ağdan ayırmak,
• istemci izolasyonunu ihtiyaca göre kullanmak,
• erişim noktası envanteri ve rogue AP tespiti,
• yönetim düzlemini kullanıcı trafiğinden ayırmak.

Deauthentication gibi yönetim çerçevelerinin kötüye kullanımı, 802.11w/Protected Management Frames gibi mekanizmaların neden ortaya çıktığını açıklar. Araç ve saldırı adından çok, kimlik doğrulanmamış yönetim mesajının erişilebilirliği etkileyebilmesi tasarım dersidir.

46.3 VPN bir güven seviyesi değil taşıma kanalıdır

VPN bağlantısı kuruldu diye istemci güvenilir hâle gelmez. VPN, belirli ağlar arasında güvenli kanal ve erişim yolu sağlayabilir; ancak ele geçirilmiş istemci aynı tüneli saldırgan adına kullanabilir. Bu nedenle VPN sonrası da cihaz durumu, kullanıcı kimliği, segmentasyon ve uygulama yetkisi değerlendirilmelidir.

47. Zararlı yazılım, rootkit ve ransomware: saldırganın kalıcılık ve etki mühendisliği

Zararlı yazılım konusu çok geniştir. Virüs, worm, trojan, rootkit, bot, downloader, information stealer ve ransomware farklı davranışlara sahip olabilir. Savunma açısından isimden daha kullanışlı yaklaşım saldırganın yaşam döngüsünü incelemektir:

İlk erişim
 -> çalıştırma
 -> kalıcılık
 -> ayrıcalık yükseltme
 -> savunmadan kaçınma
 -> kimlik bilgisi erişimi
 -> keşif
 -> yanal hareket
 -> veri toplama / dışarı çıkarma
 -> etki

Bu akış MITRE ATT&CK taktikleriyle de uyumludur.

47.1 Trojan bize güven zincirini öğretir

Kullanıcı beklediği uygulama yerine içine zararlı davranış eklenmiş bir programı çalıştırıyorsa sorun yalnız antivirüs değildir. Yazılımın kaynağı ve bütünlüğü doğrulanmamıştır. Kod imzası, güvenilir dağıtım kanalı, izin listesiing ve tedarik zinciri kontrolleri bu nedenle değerlidir.

47.2 Rootkit ve görünürlük problemi

Rootkit'in savunmadaki ana fikri, gözlem aracının kendisi ele geçirilmiş sistemin içinde çalışıyorsa gerçeği göremeyebileceğidir. Kernel veya düşük seviye bileşen değiştirilmişse ps, dosya listeleme veya yerel loglara kör güven duyulamaz.

Bu nedenle kritik ortamlarda merkezi/uzak loglama, ağ telemetry'si, bütünlük kontrolü, secure boot/ölçümlü boot gibi mekanizmalar ve güvenilir yeniden kurulum kaynağı önemlidir.

47.3 Ransomware yalnız şifreleme değildir

Modern ransomware operasyonları çoğu zaman şifreleme öncesinde kimlik bilgisi toplama, yanal hareket, yedekleri devre dışı bırakma ve veri dışarı çıkarma içerir. “Yedeğimiz var” tek başına savunma değildir.

Dayanıklı tasarım için:

• ayrıcalık alanlarını ayırmak,
• yönetici hesabını günlük işte kullanmamak,
• yanal hareket yollarını azaltmak,
• kritik yedekleri saldırganın normal domain yetkilerinden ayırmak,
• geri yüklemeyi düzenli test etmek,
• anormal toplu dosya değişikliği ve kimlik davranışını tespit etmek,
• kritik servisler için yeniden kurulum planı oluşturmak

gerekir.

Ransomware olayında bir makineyi temizlemek yerine saldırganın kimlik sisteminde hangi yetkilere ulaştığını anlamak belirleyicidir.

48. E-posta ve oltalama: kimlik sistemine açılan sosyal protokol

Oltalama teknik olarak bir web sayfası veya e-posta problemi gibi görünür; aslında kimlik doğrulama, insan davranışı, e-posta altyapısı ve süreç güvenliğinin kesişimidir.

48.1 Teknik e-posta doğrulama

SPF, DKIM ve DMARC gönderen alanın kötüye kullanımını azaltmak için birlikte kullanılabilir. Hiçbiri kullanıcıyı her oltalama mesajından korumaz; benzer yazılmış domain, ele geçirilmiş gerçek hesap veya üçüncü taraf servis üzerinden gelen kötü amaçlı mesaj hâlâ mümkündür.

Bu yüzden e-posta güvenliği şu katmanları birleştirir:

• gönderen alan politikaları,
• bağlantı ve ek analizi,
• makro/aktif içerik kısıtları,
• sandbox gereksinimi,
• kullanıcı raporlama mekanizması,
• phishing-resistant MFA,
• ayrıcalıklı hesapların e-posta kullanımından ayrılması,
• olay korelasyonu.

48.2 Oltalamanın başarısı sonrası ne oluyor?

Bir çalışan parola girdiyse olay yalnız “kullanıcı hata yaptı” diye kapanmamalıdır. Şunlar kontrol edilir:

• parola başka sistemlerde tekrar kullanılmış mı?
• MFA faktörü ele geçirilmiş mi?
• oturum belirteç oluşturulmuş mu?
• OAuth consent verilmiş mi?
• mailbox forwarding rule eklenmiş mi?
• yeni kimlik doğrulayıcı kaydedilmiş mi?
• aynı kimlikle VPN veya kurumsal uygulama erişimi yapılmış mı?

Kimlik olayını yalnız parola değiştirerek kapatmak kalıcılık yollarını kaçırabilir.

49. OSINT ve güvenlik tarayıcıları: ne kadar görünür olduğumuzu ölçmek

Google hacking/dorking, arama motorlarının özel sorgu operatörleriyle internete yanlışlıkla açılmış içeriği bulma yaklaşımıdır. Bugün aynı düşünce yalnız Google ile sınırlı değildir. Kod depoları, certificate transparency, internet ölçüm servisleri, paket registry'leri, arşiv siteleri ve veri ihlali kaynakları saldırganın pasif keşif yüzeyidir.

Savunma açısından düzenli external attack surface management yapılmalıdır. Amaç “arama motorundan gizlenmek” değil, internet üzerinden erişilebilir olmaması gereken varlığın gerçekten erişilebilir olup olmadığını görmektir.

49.1 Nmap, Nessus/OpenVAS/Nikto benzeri araçların sınırı

Tarayıcıların en büyük avantajı tekrarlanabilir ve geniş kapsamlı olmalarıdır. Yanlış sürüm, açık port, bilinen CVE veya belirli web yanlış yapılandırmalarını hızlı bulabilirler.

Fakat tarayıcı şu soruları her zaman cevaplayamaz:

• bu kullanıcı başka tenant'ın verisini okuyabilir mi?
• iş akışındaki onay adımı atlanabilir mi?
• iki orta seviye bulgu birleşince kritik yol oluşuyor mu?
• özel kriptografik protokol yanlış mı tasarlanmış?
• uygulama yanlış güven sınırına mı dayanıyor?

Bu nedenle “Nessus temiz çıktı, sistem güvenli” çıkarımı hatalıdır.

49.2 Kimlik doğrulamalı tarama

İşletim sistemi ve sunucu güvenlik açığı taramasında kimlik doğrulamalı tarama, yalnız dış banner'a bakmaktan daha doğru envanter sağlayabilir. Ancak tarayıcı hesabının kendisi yüksek yetkili sır olduğundan erişimi, saklanması ve rotasyonu güvenli olmalıdır.

50. OAuth 2, OpenID Connect ve SAML: kimlik ile yetkiyi protokole dökmek

OAuth 2 bir yetkilendirme çerçevesidir; kullanıcının parolasını üçüncü taraf uygulamaya vermeden belirli kaynağa sınırlı erişim devri sağlar. OpenID Connect (OIDC), OAuth 2 üzerine kimlik katmanı ekler. SAML ise özellikle kurumsal federasyon ve SSO dünyasında XML tabanlı assertion modeliyle yaygındır.

Bu ayrımı bilmemek ciddi tasarım hatalarına yol açar. Erişim belirtecini “kullanıcının kimlik kartı” diye her yerde kullanmak, ID belirtecini API yetkilendirme belirteci gibi kabul etmek veya belirtecin yalnız varlığına bakmak doğru değildir.

50.1 OAuth 2 akışında güven sınırları

Modern web/mobil istemcilerde Authorization Code + PKCE yaygın ve güvenli temel akıştır. İstemci türü, sır saklayabilme yeteneği ve redirect URI güvenliği dikkate alınır.

Kaynak sunucu şunları doğrulamalıdır:

• belirteç güvenilen issuer'dan mı?
• bu API için mi verilmiş (aud)?
• süresi geçerli mi?
• gereken scope/authority var mı?
• signature güvenilen anahtarla doğrulanıyor mu?

scope uygulamanın bütün alan yetkilendirmesi'ını ifade etmek zorunda değildir. “documents.read” yetkisine sahip kullanıcının her belgeyi okuyabileceği sonucu çıkmaz; nesne sahipliği ayrıca değerlendirilir.

50.2 Redirect URI

OAuth/OIDC tasarımında redirect URI geniş joker karakterli ile kabul edilirse yetkilendirme kodu veya belirteç saldırganın kontrol ettiği adrese yönlendirilebilir. Redirect hedefleri önceden kayıtlı ve mümkün olduğunca kesin eşleşmeli olmalıdır.

50.3 PKCE neden vardır?

Public client, gömülü client secret'ı güvenilir biçimde saklayamaz. PKCE, yetkilendirme isteği ile belirteç değişimini aynı istemci örneğine bağlamak için tek kullanımlık verifier/challenge modeli sağlar. Mobil uygulamaya sabit secret gömmek PKCE'nin yerine geçmez.

50.4 SAML ve XML güvenliği

SAML assertion'ın imza doğrulaması, issuer, audience, recipient, süre ve replay koşulları doğru değerlendirilmelidir. XML Signature Wrapping gibi tarihsel açıklar, “XML imzalıysa güvenlidir” varsayımının yetersiz olduğunu göstermiştir; uygulama doğrulanan düğüm ile işlediği düğümün aynı olduğundan emin olmalıdır.

Federasyon protokollerinde çoğu kritik hata kriptografik algoritmadan değil assertion'ın hangi bağlamda geçerli olduğunun eksik doğrulanmasından doğar.

51. XML, XXE, LFI/RFI ve template injection: ayrıştırıcı özelliklerini saldırı yüzeyi saymak

Ayrıştırıcı'lar kolaylık için güçlü özellikler sunar. Güvenilmeyen içerikte bu özellikler beklenmeyen dosya, ağ veya kod erişimine dönüşebilir.

51.1 XXE

XML External Entity saldırılarında ayrıştırıcı dış entity çözümlemeye izin veriyorsa uygulama yerel dosya veya ağ kaynağı okuyabilir. Güvenli yaklaşım ihtiyaç yoksa DTD/external entity özelliklerini kapatmaktır. Sadece saldırı yükü filtrelemek ayrıştırıcının bütün sözdizimini öngörmeye çalışır.

XXE, SSRF ile de birleşebilir. Ayrıştırıcı'ın dış kaynağa bağlanabilmesi sunucunun ağ konumunu kullanır. Bu yüzden ayrıştırıcı sıkılaştırma ve egress kısıtı birlikte değerlidir.

51.2 LFI/RFI ve include semantiği

Local File Inclusion ve Remote File Inclusion tarihsel olarak özellikle dinamik dosya include eden uygulamalarda görülmüştür. Kök neden, kullanıcı girdisinin çalıştırılacak veya okunacak kaynağı belirlemesine izin verilmesidir.

Modern tasarımda route veya template seçimi kullanıcı dosya adıyla yapılmamalı; izin verilen kaynaklar kod içindeki sabit eşlemeyle seçilmelidir:

"home"    -> templates/home
"profile" -> templates/profile
"report"  -> templates/report

Kullanıcının ../../... veya URL üretebildiği serbest kaynak seçimi gereksizdir.

51.3 Server-Side Template Injection

Template motoru kullanıcı girdisini yalnız veri olarak değil template kodu olarak derliyorsa SSTI oluşabilir. “Kullanıcı kendi şablonunu yazsın” iş gereksinimi varsa sandbox gerçekten güvenlik sınırı mıdır, hangi fonksiyonlara ve nesnelere erişilebilir soruları ayrıca incelenmelidir.

İdeal durumda güvenilmeyen kullanıcı yalnız değişken değerlerini sağlar; çalıştırılabilir template yapısını belirlemez.

52. Yarış durumları ve TOCTOU: doğru kontrol yanlış zamanda yapıldığında

Güvenlik kontrollerinin yalnız varlığı değil zamanı da önemlidir. Time-of-check to time-of-use (TOCTOU) hatasında bir kaynak kontrol edildikten sonra kullanılmadan önce değişebilir.

Basit örnek:

1. Dosya yolunun güvenli olduğunu kontrol et
2. Başka işlem symlink'i değiştirir
3. Dosyayı aç

Kontrol edilen nesne ile kullanılan nesne aynı olmayabilir.

52.1 İş mantığında yarış

Race condition yalnız native dosya sistemi problemi değildir. Web uygulamalarında:

• bakiye kontrolü sonrası iki eşzamanlı çekim,
• tek kullanımlık kuponun paralel kullanımı,
• kota kontrolü sonrası paralel kaynak oluşturma,
• “yalnız bir kez onayla” işleminin iki kez çalışması,
• belirteç iptali ile kullanım arasındaki yarış

güvenlik veya veri bütünlüğü sorununa dönüşebilir.

52.2 Çözüm mutex eklemekten ibaret değildir

Dağıtık sistemde uygulama içi mutex yalnız tek süreçte çalışır. Çözüm işlemin doğasına göre DB transaction/locking, unique constraint, compare-and-set, idempotency key, atomik datastore işlemi veya doğru seri hale getirme olabilir.

Güvenlik testi concurrency içermezse normal sırada doğru çalışan iş kuralı yarışta kırılabilir.

53. Konteyner, Kubernetes ve bulut: izolasyonu güven sınırı sanmamak

Konteyner uygulamayı paketleme ve izolasyon için güçlü araçtır; sanal makineyle aynı güven modeli değildir. Host kernel paylaşılır. --privileged, hostPath, geniş capability, Docker socket veya aşırı Kubernetes RBAC yetkileri izolasyonu önemli ölçüde zayıflatabilir.

53.1 Konteyner imajı

İmaj güvenliği şunları içerir:

• küçük ve kontrollü base image,
• gereksiz paketleri kaldırma,
• root olmayan kullanıcı,
• secret'ı image katmanına koymama,
• digest ile sabitleme gereken yerler,
• bilinen güvenlik açığı taraması,
• imza/provenance,
• read-only filesystem gereksinimi.

Çok aşamalı derleme, son imajdaki derleme araçlarını azaltarak saldırı yüzeyini küçültebilir.

53.2 Kubernetes

Kubernetes'te güvenlik hataları çoğu zaman orkestratörün güçlü yeteneklerinin gereğinden geniş verilmesinden doğar:

• cluster-admin servis hesabı,
• varsayılan servis hesabı belirtecine gereksiz erişim,
• geniş NetworkPolicy,
• secret'ların kontrolsüz kullanımı,
• privileged pod,
• host namespace erişimi,
• admission kontrolünün eksikliği.

Namespace tek başına güçlü tenant güvenlik sınırı sayılmamalıdır. Çok kiracılı ortamın tehdit modeli ayrıca tasarlanmalıdır.

53.3 Bulut kimliği

Bulutta klasik “iç ağ” kavramından çok IAM belirleyici hâle gelir. Fazla yetkili rol, public object storage veya sızmış access key büyük etki yaratabilir. Metadata servisine SSRF de bu nedenle tehlikelidir: uygulamanın instance/workload kimliğine erişim yolu açabilir.

Uzun ömürlü access key yerine workload identity/managed identity gibi kısa ömürlü mekanizmalar tercih edilmelidir. Denetim logları merkezi ve değiştirilmeye karşı korumalı tutulmalıdır.

53.4 Azure/AD grafının genişlemesi

BloodHound/AzureHound türü çalışmalar hibrit kimlik ortamında on-premises AD ile bulut kimliği arasındaki ilişkilerin de saldırı yolu oluşturabileceğini gösterir. Bir kullanıcı doğrudan yüksek yetkili olmayabilir; grup, uygulama kaydı, service principal, role assignment veya secret üzerinden kritik kaynağa yol bulunabilir.

Savunma burada yine graf düşüncesine döner: kritik varlığa ulaşabilen dolaylı kimlik yollarını periyodik çıkarmak gerekir.

54. Honeypot ve aldatma: saldırganın davranışından erken sinyal üretmek

Honeypot normal iş akışında kullanılmaması gereken fakat saldırgan etkileşimini gözlemek için tasarlanan sistem veya kaynaktır. Honeynet daha geniş kontrollü ortamı ifade eder. Doğru kullanıldığında yüksek sinyal/gürültü oranı sağlayabilir: kimsenin erişmemesi gereken bir kimlik bilgisi veya paylaşım kullanıldıysa bu güçlü göstergedir.

Ancak honeypot savunmanın yerine geçmez. Kötü izole edilmiş yüksek etkileşimli honeypot saldırganın başka sistemlere sıçrama noktası olabilir. Hukuki, mahremiyet ve veri toplama gereksinimleri de değerlendirilmelidir.

Daha hafif deception örnekleri:

• honey kimlik bilgisi,
• normalde kullanılmayan izlenen dosya,
• sahte yönetim kaynağı,
• decoy servis hesabı,
• erişilmemesi gereken özel paylaşım.

Bu kaynakların değeri “saldırganı kandırmak” kadar, normal kullanıcının üretmeyeceği davranışı yüksek güvenle alarm hâline getirmesidir.

55. Güvenli tasarım ilkelerini kısa kurallara indirgemek

Uzun notun sonunda bazı ilkeler araçlardan daha kalıcıdır:

1. Güvenilmeyen veriyi komutla birleştirmeyin.
2. Kimliği doğrulamak yetki vermek değildir.
3. İstemci güven sınırı değildir.
4. En az ayrıcalık tek açığın etkisini küçültür.
5. Güvenli varsayılan, dokümantasyondaki güvenlik tavsiyesinden güçlüdür.
6. Sır saklanan yerde değil kullanıldığı bütün yaşam döngüsünde korunur.
7. Kriptografi anahtar yönetimi kadar güçlüdür.
8. Gözleyemediğiniz saldırıya güvenilir biçimde müdahale edemezsiniz.
9. Yedek geri yüklenmedikçe yedek değildir.
10. Tarama bulgu üretir; risk analizi öncelik üretir.
11. Sızma testi kontrolün varlığını değil gerçekten çalışıp çalışmadığını sınar.
12. Aynı güvenlik açığı tekrar ediyorsa süreç hatası vardır.
13. İç ağ güvenilir kabul edilmez; her sınırın kendi kimlik ve yetki modeli vardır.
14. Bir hata kaçacakmış gibi tasarlayın; etki alanı'u sınırlayın.
15. Savunma saldırı zincirindeki yolları kesmelidir, yalnız göstergeleri saklamamalıdır.

Bunlar slogan olarak değil tasarım inceleme sorusu olarak kullanılmalıdır.

56. Uygulamalı güvenli kılma algoritması

Şimdi bütün parçaları tek süreçte birleştirebiliriz. Yeni veya mevcut bir projeyi güvenli kılarken aşağıdaki sıra pratikte iyi sonuç verir.

Adım 1 — Varlığı belirle

Sistemin ne yaptığını ve hangi veri/işlevin kritik olduğunu yazın. Varlık bilinmeden risk konuşmayın.

Çıktı: varlık ve veri sınıflandırma listesi.

Adım 2 — Gerçek saldırı yüzeyini çıkar

Kod deposundan mimari diyagramı alın ama onunla yetinmeyin. DNS, port, API, sertifika, mobil istemci, üçüncü taraf ve yönetim yüzeylerini doğrulayın.

Çıktı: doğrulanmış envanter ve veri akış diyagramı.

Adım 3 — Güven sınırlarını çiz

İstemci–sunucu, servis–servis, uygulama–DB, kurum–üçüncü taraf, normal kullanıcı–yönetici ve geliştirme–üretim sınırlarını işaretleyin.

Çıktı: hangi sınırda hangi kimlik ve kontrolün gerektiği.

Adım 4 — Tehditleri üret

STRIDE, attack tree, abuse case ve MITRE ATT&CK bilgisiyle sistem bağlamına uygun yolları çıkarın.

Çıktı: test edilebilir tehdit senaryoları.

Adım 5 — Mimariyle yolları kapat

En az ayrıcalık, segmentasyon, güvenli varsayılan, trust minimization, görev ayrılığı ve egress kontrolünü koddan önce uygulayın.

Çıktı: bir hata oluşsa bile sınırlı etki.

Adım 6 — Kimlik ve yetkiyi merkezî ilkelere bağla

Kimlik doğrulama yaşam döngüsünü, MFA/kurtarma yolunu, servis kimliklerini ve nesne düzeyi yetkilendirmeyi tanımlayın.

Çıktı: “kim, neye, hangi koşulda?” sorusunun tek ve test edilebilir cevabı.

Adım 7 — Veri ile komut arasına sert sınır koy

Parametreli sorgu, güvenli process API, context-aware output encoding, dar ayrıştırıcı şeması, dosya yolunun bağımsız üretilmesi gibi yapıları kullanın.

Çıktı: enjeksiyon sınıflarının kökten daraltılması.

Adım 8 — Sır ve kriptografiyi yaşam döngüsüyle yönet

Üretim, saklama, erişim, döndürme, iptal ve yok etmeyi birlikte tasarlayın.

Çıktı: sızıntının fark edilebilir ve yönetilebilir olması.

Adım 9 — Çalışma ortamını kısıtla

Servis kullanıcısı, dosya izinleri, capability, container/systemd sıkılaştırma, ağ politikası ve DB yetkilerini küçültün.

Çıktı: RCE veya kimlik bilgisi sızıntısının etki alanı'unun düşmesi.

Adım 10 — Tedarik zincirini doğrula

Bağımlılıkları, temel imajları, CI çalıştırıcılarını, sırları, artefaktları ve dağıtım yetkilerini envantere alın. SBOM ve provenance üretin.

Çıktı: “bu binary nereden geldi?” sorusuna kanıtlı cevap.

Adım 11 — Otomatik ve manuel testleri birleştir

SAST, SCA, DAST, fuzzing, configuration test, unit/integration security test ve sızma testini farklı hata sınıfları için kullanın.

Çıktı: tek aracın kör noktasına bağımlı olmayan doğrulama.

Adım 12 — Sisteme saldır

Yetkili laboratuvar veya tanımlı sızma testi kapsamında en gerçekçi saldırı yollarını deneyin. UI'yi değil protokolü test edin; tek açığı değil zinciri düşünün.

Çıktı: kontrolün teorik değil gerçek davranışı.

Adım 13 — Görünürlük üret

Önemli güvenlik kararlarını loglayın, ağ/host/application telemetry'yi ilişkilendirin, anlamlı alarmlar oluşturun.

Çıktı: başarısız olmayan ama fark edilen saldırı.

Adım 14 — Olayı prova et

Hesap ele geçirilmesi, ransomware, belirteç sızıntısı veya web RCE senaryosu seçin. Kim karar veriyor, hangi sistemi izole ediyor, hangi anahtarı döndürüyor, hangi kanıtı topluyor test edin.

Çıktı: kâğıt üzerindeki IR planının gerçek kapasiteye dönüşmesi.

Adım 15 — Kök nedeni sisteme geri besle

Bulgunun yalnız örneğini değil sınıfını kapatın. Güvenli library, lint kuralı, reusable component, mimari kural veya test üreterek aynı hatanın tekrarını zorlaştırın.

Çıktı: her olaydan sonra daha düşük tekrar olasılığı.

57. Son CTF: Bayrağa giden yolu kapatmak

Başlangıçtaki sistemi yeniden ele alalım. İlk sürümde şu kusurlar bulunsun:

• hata ayıklama uç nokta internete açık,
• hata mesajı kullanıcı adlarını ifşa ediyor,
• zayıf parola politikası var,
• MFA yok,
• API nesne sahipliğini kontrol etmiyor,
• arama sorgusu string birleştiriyor,
• uygulama DB hesabı şema sahibi,
• dosya indirme yolu kullanıcı girdisinden oluşuyor,
• servis root çalışıyor,
• iç ağa sınırsız çıkış yapabiliyor,
• servis hesabı AD'de gereğinden fazla yetkili,
• loglar korelasyon kimliği taşımıyor,
• CI statik dağıtım belirteç kullanıyor.

Saldırgan ilk bayrağa ulaşmak için tek açığa bağlı değildir:

Bilgi sızıntısı
 -> hesap keşfi
 -> parola püskürtme
 -> kullanıcı hesabı
 -> IDOR
 -> servis yapılandırması
 -> servis kimlik bilgisi
 -> AD saldırı yolu
 -> ayrıcalık yükseltme
 -> kritik veri
 -> BAYRAK

Başka yol:

SQL injection
 -> DB sahibinin yetkileri
 -> kritik veri değişikliği
 -> BAYRAK

Başka yol:

Dosya yükleme / ayrıştırıcı açığı
 -> RCE
 -> root süreç
 -> iç ağa sınırsız erişim
 -> yanal hareket
 -> BAYRAK

Şimdi savunma kararlarını yerleştirelim.

Hata ayıklama uç noktası kaldırıldığında keşif kolaylığı azalır ama sistem güvenli değildir. Parola politikasını ve MFA'yı düzelttiğimizde hesap yolu daralır ama yetkilendirme açığı hâlâ vardır. Nesne düzeyi yetkilendirme IDOR'u kapatır. Parametreli sorgu SQL injection yolunu keser. En az ayrıcalıklı DB hesabı gelecekteki bilinmeyen bir DB açığının etkisini küçültür. Dosya işleme sandbox'ı ve root olmayan servis RCE'nin etkisini azaltır. Egress kısıtı iç ağa sıçramayı zorlaştırır. AD grafındaki gereksiz grup/ACL yollarını temizlemek ele geçirilmiş servis hesabının değerini düşürür. SIEM korelasyonu başarısız girişlerden yanal harekete kadar zinciri görünür kılar.

Sonunda “hiç açık yok” iddiasında bulunmayız. Böyle bir iddia ölçülemez. Daha güçlü bir ifade kullanırız:

Bilinen saldırı yüzeyi çıkarıldı; kritik varlığa giden tehdit yolları modellendi; öncelikli yollar bağımsız güvenlik kontrolleriyle kesildi; bu kontroller otomatik ve manuel testlerle doğrulandı; kalan riskler kayıtlı; tespit ve olay müdahale yolları prova edildi.

Bayrağı böyle koruruz.

58. Güvenlik değerlendirme matrisi

Bir projeyi kısa sürede gözden geçirirken aşağıdaki matris ilk geçiş için kullanılabilir. Bu bir standardın yerini tutmaz; araştırılacak alanı hızla görünür kılar.

| Alan | Temel doğrulama | |---|---| | Envanter | Tüm internet yüzeyi, servisler, API'ler ve bağımlılıklar biliniyor mu? | | Veri | Hassas veri sınıflandırılmış, saklama süresi ve erişim modeli belirli mi? | | Tehdit modeli | Güven sınırları ve kritik saldırı yolları çıkarılmış mı? | | Kimlik | Güncel parola/MFA/kurtarma politikası var mı? | | Yetki | Sunucu tarafında nesne ve işlem düzeyi yetkilendirme yapılıyor mu? | | Oturum | Belirteç/çerez yaşam döngüsü, süre, iptal ve güvenli taşıma doğru mu? | | Enjeksiyon | Yorumlayıcı sınırlarında veri ve komut ayrılıyor mu? | | XSS | Bağlama uygun çıktı kodlama ve güvenli DOM kullanımı var mı? | | CSRF/CORS | Tarayıcı güven modeli doğru anlaşılmış ve dar politika uygulanmış mı? | | SSRF | Sunucu çıkışları ve hedef URL davranışı sınırlandırılmış mı? | | Dosya | Yol, tür, boyut, saklama ve servis etme güvenliği var mı? | | Kriptografi | Standart algoritmalar, doğru key management ve rotation var mı? | | Sırlar | Kod/repo/log dışında, denetimli sır yönetiminde mi? | | DB | Parametreli sorgu, en az ayrıcalık, ağ sınırı ve yedek güvenliği var mı? | | İşletim sistemi | Root olmayan süreç, az servis, sıkı izin ve güncel yamalar var mı? | | AD | Ayrıcalıklı yollar, servis hesapları, Kerberos/NTLM riskleri izleniyor mu? | | Ağ | Segmentasyon ve egress kontrolü gerçek veri akışıyla uyumlu mu? | | Tedarik zinciri | SCA, SBOM, güvenilir paket deposu, derleme köken bilgisi ve imza var mı? | | CI/CD | Runner ve dağıtım kimlikleri en az ayrıcalıklı ve kısa ömürlü mü? | | Test | SAST/DAST/SCA/fuzzing/manual test birlikte kullanılıyor mu? | | Loglama | Güvenlik olayları korele edilebilir ama sır içermeyecek şekilde loglanıyor mu? | | Algılama | Kritik ATT&CK davranışları için görünürlük var mı? | | IR | İzolasyon, kimlik bilgisi rotation ve recovery playbook'ları test edildi mi? | | Yedek | Geri yükleme düzenli ve güvenli biçimde doğrulanıyor mu? | | İnsan | Kritik süreçler sosyal mühendisliğe tek adımlı açık bırakılmış mı? |

59. Olgunluk: güvenlik açığı sayısından daha anlamlı göstergeler

Bir güvenlik programının başarısını yalnız “kaç açık kapattık?” ile ölçmek yanıltıcıdır. Tarama kapsamını artırdığınızda açık sayısı artabilir; bu güvenliğin kötüleştiğini değil görünürlüğün arttığını gösterebilir.

Daha anlamlı metrikler bağlama göre şunlar olabilir:

• kritik varlıkların envanter kapsama oranı,
• threat model yapılmış kritik akış oranı,
• güvenlik gereksinimi bulunan özellik oranı,
• kritik/yüksek bulgunun ortalama kapatılma süresi,
• aynı CWE sınıfının tekrar oranı,
• privileged account sayısı ve trendi,
• uzun ömürlü secret sayısı,
• MFA/phishing-resistant kimlik doğrulayıcı kapsaması,
• log kaynağı kapsaması,
• mean time to detect / respond,
• yedek geri yükleme başarısı,
• attack path sayısı veya kritik path uzunluğu,
• security test işlem hattı başarısızlıklarının türü,
• süreli risk kabulünün zamanında yeniden değerlendirilme oranı.

Metrik davranışı değiştirdiği için dikkatle seçilmelidir. Ekibi “bulgu sayısını azaltmakla” ödüllendirirseniz tarama kapsamı küçülebilir. Hedef gerçek riski azaltmaktır.

60. Sonuç: güvenli sistemin sade tarifi

Siber güvenliğe ilk girildiğinde araç sayısı ürkütücüdür. Nmap, Wireshark, Burp Suite, Metasploit, BloodHound, CrackMapExec/NetExec, Hashcat, Snort, Suricata, Wazuh, hata ayıklamager'lar, disassembler'lar, fuzzing araçları, SAST ve DAST ürünleri birbirinden bağımsız uzmanlıklar gibi görünür.

Zamanla araçların geçici, ilkelerin daha kalıcı olduğu anlaşılır.

Bir paket analizinde öğrendiğimiz güven sınırı, bir REST API'de de karşımıza çıkar. Stack overflow çalışırken gördüğümüz “küçük veri hatası kontrol akışını değiştirebilir” ilkesi, güvensiz tersine serileştirmede başka biçimde görünür. Active Directory grafında gördüğümüz saldırı yolu, mikroservis yetki grafında tekrar eder. Sosyal mühendislik, kimlik doğrulamanın yalnız kriptografi olmadığını gösterir. DDoS, erişilebilirliğin kapasite mühendisliğinden ayrı düşünülemeyeceğini öğretir. Adli bilişim ise tasarım sırasında bırakmadığımız kanıtı olaydan sonra üretemeyeceğimizi hatırlatır.

Bu nedenle güvenli yazılım mühendisliğini tek cümleye indirgemem gerekirse şu şekilde ifade ederim:

Sistemin hangi varsayımlara güvendiğini görünür kıl, gereksiz güveni kaldır, kalan güveni doğrula, hatanın etkisini sınırla ve kontrolün gerçekten çalıştığını saldırganın bakışıyla kanıtla.

Zen yaklaşımının güvenlikteki karşılığı da burada belirir. Daha çok araç, daha çok ürün, daha çok kural her zaman daha güvenli sistem üretmez. Gereksiz servis kapalıysa firewall kuralına ihtiyaç duymaz. Shell kullanılmıyorsa command escaping problemi küçülür. Kullanıcıdan fiziksel dosya yolu alınmıyorsa path traversal sınıfı daralır. Native nesne deserialization yapılmıyorsa gadget chain aramak gerekmez. Servis gereksiz yetkiye sahip değilse RCE'nin etkisi sınırlanır. Veri tutulmuyorsa sızdırılamaz.

En güçlü güvenlik kontrolü bazen eklediğimiz değil, ihtiyaç olmadığı için sistemden çıkardığımız yetenek olur.

Bayrak hâlâ oradadır. Fakat ona ulaşan yol artık rastlantılardan oluşmaz. Her geçitte kimlik sorulur, her kaynakta yetki doğrulanır, her yorumlayıcıda veri komuttan ayrılır, her süreç yalnız ihtiyacı kadar yetki taşır, her önemli olay iz bırakır. Bir kontrol kırılırsa diğeri saldırının etkisini sınırlar. Bir şey yine de geçerse görürüz. Görürsek müdahale ederiz. Müdahale ettikten sonra aynı hatanın tekrarını zorlaştırırız.

Güvenli sistem, saldırıya hiç uğramayan sistem değildir. Saldırıya hazırlanmış, sınırları belirli, davranışı ölçülebilir ve ihlal karşısında dirençli sistemdir.

Kaynakça ve güncel başvuru kaynakları

Bu ders notu; paylaşılan siber güvenlik çalışma notlarındaki uygulamalı konular, klasik güvenlik literatürü ve güncel güvenli yazılım geliştirme standartlarının birlikte değerlendirilmesiyle hazırlanmıştır. Eski araç ve sürümlere bağlı anlatımlar tarihsel öğretim değeri korunarak güncel mühendislik ilkeleriyle yeniden ele alınmıştır.

1. OWASP Foundation, OWASP Top 10:2025 — https://owasp.org/Top10/
2. OWASP Foundation, Application Security Verification Standard (ASVS) 5.0.0 — https://owasp.org/www-project-application-security-verification-standard/
3. OWASP Foundation, OWASP Cheat Sheet Series — https://cheatsheetseries.owasp.org/
4. NIST, SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, 2022 — https://csrc.nist.gov/pubs/sp/800/218/final
5. NIST, Cybersecurity Framework (CSF) 2.0, 2024 — https://www.nist.gov/cyberframework
6. NIST, SP 800-63-4: Digital Identity Guidelines, 2025 — https://csrc.nist.gov/pubs/sp/800/63/4/final
7. NIST, SP 800-63B-4: Authentication and Authenticator Management, 2025 — https://csrc.nist.gov/pubs/sp/800/63/B/4/final
8. CISA ve ortak kurumlar, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software — https://www.cisa.gov/securebydesign
9. Center for Internet Security, CIS Critical Security Controls v8.1 — https://www.cisecurity.org/controls/v8-1
10. MITRE, ATT&CK Enterprise Matrix, güncel sürüm bilgisi ve teknik kataloğu — https://attack.mitre.org/
11. MITRE, Common Weakness Enumeration (CWE) — https://cwe.mitre.org/
12. FIRST, Common Vulnerability Scoring System (CVSS) — https://www.first.org/cvss/
13. Anley, C.; Heasman, J.; Lindner, F.; Richarte, G., The Shellcoder's Handbook: Discovering and İstismaring Security Holes, 2nd ed., Wiley, 2007.
14. Eilam, E., Reversing: Secrets of Reverse Engineering, Wiley, 2005.
15. Easttom, C., Computer Security Fundamentals, Pearson.
16. Mitnick, K. D.; Simon, W. L., The Art of Deception: Controlling the Human Element of Security, Wiley, 2002.
17. Spilcă, L., Spring Security in Action, Manning Publications.
18. BloodHound Enterprise / Community Edition documentation — https://bloodhound.specterops.io/
19. Microsoft Learn, Active Directory Domain Services and Windows security documentation — https://learn.microsoft.com/windows-server/identity/
20. Wazuh Documentation — https://documentation.wazuh.com/
21. Snort Documentation — https://www.snort.org/documents
22. Suricata Documentation — https://docs.suricata.io/
23. Wireshark Documentation — https://www.wireshark.org/docs/
24. PortSwigger, Web Security Academy — https://portswigger.net/web-security
25. OWASP, Web Security Testing Guide (WSTG) — https://owasp.org/www-project-web-security-testing-guide/
26. OWASP, Mobile Application Security (MAS) Project — https://mas.owasp.org/

Standartları birlikte kullanmak için kısa not

Bu kaynakların işlevleri farklıdır. OWASP Top 10 farkındalık ve risk kümeleri için; ASVS uygulama seviyesinde doğrulanabilir güvenlik gereksinimleri için; NIST SSDF güvenli geliştirme süreci için; NIST CSF kurumsal siber risk yaşam döngüsü için; CIS Controls uygulanabilir kurumsal öncelikler için; MITRE ATT&CK saldırgan davranışı ve algılama kapsamını düşünmek için uygundur. Birini diğerinin yerine kullanmak yerine aralarında izlenebilirlik kurmak daha doğru sonuç verir.