Bölüm 38
Kapanış: Tekrarlayan Kök Nedenler ve CVE Derlemesi
Önceki 37 bölümün temel kavramları ve vaka analizleri.
Gerçek vakaları tek bir haritada birleştirerek tekrarlayan kök nedenleri ve savunmacının zihinsel modelini göreceksiniz.
Bu bölüm bir vuln bölümü değil, kitabın sentezidir. 37 bölüm boyunca gördüğümüz gerçek CVE ve vakaları tek bir haritada topluyor; onların altında yatan tekrarlayan kök nedenleri çıkarıyor; ve bir savunmacının bu derslerden inşa etmesi gereken zihinsel modeli özetliyor. Bir açığı ezberlemek değil, açıkların nereden geldiğini görmek — kitabın asıl amacı buydu.
1. Neden Bir Kapanış Bölümü?
Bu kitap 37 farklı açık sınıfını, her birini gerçek bir CVE veya ihlale bağlayarak inceledi. Ama amaç, 37 ayrı "kural" ezberletmek değildi. Dikkatli okuduysanız, aynı birkaç kök nedenin — farklı kılıklarda — tekrar tekrar geri geldiğini fark etmişsinizdir. SQL injection ile SSRF, path traversal ile deserialization, JWT karışıklığı ile SolarWinds — yüzeyde çok farklı görünen bu açıklar, altta aynı birkaç ilkenin ihlalidir.
Bu bölüm, o ilkeleri açığa çıkarır. Çünkü bir güvenlik uzmanını değerli kılan şey, bilinen açıkların bir listesini ezberlemesi değil — daha önce görmediği bir sistemde, daha önce yayımlanmamış bir açığı, kök nedenlerin sezgisiyle görebilmesidir. Yeni bir framework, yeni bir protokol, yeni bir bulut servisi çıktığında, güvenli programlamayı ezberlemiş biri kaybolur; kök nedenleri anlamış biri ise doğru soruları sorar.
Bu son bölüm üç şey yapar: (1) gördüğümüz tüm gerçek vakaları tek bir katalogda toplar; (2) altlarındaki tekrarlayan kök nedenleri çıkarır; (3) bunları bir savunmacının zihinsel modeline dönüştürür.
2. Gerçek Vaka Kataloğu — 37 Bölüm, 37 Ders
Bu kitaptaki her açık bölümü, uydurma değil gerçek, doğrulanmış bir vakaya dayandı. İşte bütün harita:
Kısım I — Temeller
| Böl. | Konu | Gerçek vaka / kavram |
|---|---|---|
| 1 | PHP Güvenlik Temelleri | Type juggling / magic hash; hash_equals |
| 2 | Threat Modeling | STRIDE / DFD (metodoloji) |
| 3 | Secure SDLC | Shift-left, SAST/DAST (metodoloji) |
| 4 | Input Validation | Beyaz liste, kanonikleştirme, mass assignment |
| 5 | Output Encoding | Beş bağlam, bağlama-göre kaçış |
Kısım II — Enjeksiyon
| Böl. | Konu | Gerçek vaka |
|---|---|---|
| 6 | SQL Injection | Drupageddon (CVE-2014-3704) |
| 7 | XSS | Samy solucanı (2005) |
| 8 | Command Injection | ImageTragick (CVE-2016-3714) |
| 9 | SSTI | Smarty (CVE-2021-26120/26119) |
| 10 | XXE | WordPress getID3 (CVE-2021-29447) |
| 11 | Unsafe Deserialization | Joomla (CVE-2015-8562) |
Kısım III — Kimlik ve Erişim
| Böl. | Konu | Gerçek vaka |
|---|---|---|
| 12 | Authentication | MantisBT type juggling (CVE-2023-53894) |
| 13 | Password & Cryptography | Adobe 2013 ihlali (153M, 3DES-ECB) |
| 14 | Authorization | WordPress REST (CVE-2017-1001000) |
| 15 | IDOR / BOLA | First American Financial (2019, 885M kayıt) |
| 16 | Session & Cookie | Firesheep (2010) |
| 17 | CSRF | Gmail filtre CSRF (2007) |
| 18 | Business Logic & Race | Starbucks yarış koşulu (2015) |
Kısım IV — Dosya, Kaynak ve Sunucu
| Böl. | Konu | Gerçek vaka |
|---|---|---|
| 19 | File Upload | WP File Manager (CVE-2020-25213, ~700K site) |
| 20 | File Inclusion / Path Traversal | Apache (CVE-2021-41773/42013) |
| 21 | SSRF | Capital One (2019, 106M kayıt) |
Kısım V — API ve Modern Servisler
| Böl. | Konu | Gerçek vaka |
|---|---|---|
| 22 | API & REST | Optus (2022, ~9.8M kayıt) |
| 23 | JWT | Tim McLean bulgusu (2015, CVE-2015-9235) |
| 24 | OAuth / OIDC | Sign in with Apple (2020, $100K) |
| 25 | Secrets Management | Uber (2016, 57M kayıt) |
Kısım VI — Altyapı ve Dağıtım
| Böl. | Konu | Gerçek vaka |
|---|---|---|
| 26 | php.ini & PHP-FPM | CVE-2024-4577 (PHP-CGI argüman enjeksiyonu) |
| 27 | Apache & Nginx | CVE-2019-11043 + cgi.fix_pathinfo sınıfı |
| 28 | Linux İzinleri | PwnKit (CVE-2021-4034) |
| 29 | Docker & Container | runc escape (CVE-2019-5736) |
| 30 | Composer & Supply Chain | PHP git ele geçirilmesi (2021) + XZ/event-stream/Codecov |
Kısım VII — Operasyonel Güvenlik ve İleri Konular
| Böl. | Konu | Gerçek vaka |
|---|---|---|
| 31 | Logging & Monitoring | Equifax (2017, 147M kayıt) |
| 32 | Incident Response & Disclosure | Uber / Joe Sullivan mahkûmiyeti (2022) |
| 33 | Secure Deployment & CI/CD | SolarWinds SUNBURST (2020, 18K+ kurum) |
| 34 | Web Shell / Backdoor | China Chopper / ProxyLogon (2021) |
| 35 | WordPress | Eklenti privesc dalgası (OttoKit CVE-2025-27007) |
| 36 | Laravel | Ignition RCE (CVE-2021-3129) |
| 37 | Symfony | Profiler üretimde ifşa |
Bu 37 vaka, birlikte, son yirmi yılın en öğretici web güvenlik olaylarının bir haritasıdır. Ama asıl değer, tek tek vakalarda değil, aralarındaki ortaklıklardadır.
3. Tekrarlayan Kök Nedenler — Kitabın Asıl Dersi
Aşağıdaki on iki ilke, 37 bölümün tamamının altında yatan tekrarlayan kök nedenlerdir. Her açık, bunlardan birinin (veya birkaçının) ihlalidir. Bunları içselleştirirseniz, hiç görmediğiniz bir açığı bile tanıyabilirsiniz.
1. Güven sınırı: güvenilmez veri + güçlü bağlam (Bölüm 1). Tüm enjeksiyonun (SQL, XSS, komut, SSTI, XXE, deserialization — Bölüm 6-11), web shell'in (34) ve daha fazlasının ortak kalıbı: güvenilmez veri, onu yorumlayabilecek/çalıştırabilecek güçlü bir bağlama (SQL motoru, HTML, kabuk, şablon, XML ayrıştırıcı, eval) doğrulama olmadan ulaşıyor. Fark yalnızca "yorumlayıcının" ne olduğudur. Soru: güvenilmez veri nereye akıyor ve hangi güçlü bağlama ulaşabiliyor?
2. Etkiyi en az yetki belirler (Bölüm 1, 14, 21, 25, 28). Bir açığın varlığı ile etkisi farklıdır; etkiyi, arkasındaki yetki belirler. Capital One'da felaketi SSRF değil, WAF rolünün S3'e erişebilmesi yarattı; Uber'de tek "full admin" anahtar; PwnKit'te SUID; container'da root-in-container. Soru: bu başarısız olursa hasar (blast radius) ne kadar?
3. Kanonikleştir-sonra-doğrula (Bölüm 4, 20). Doğrulama, verinin kanonik biçiminde yapılmalı; aksi hâlde alternatif kodlamalar (URL-encode, çift kodlama, Unicode, ....//) kontrolü atlatır. Apache CVE-2021-41773 tam bir "decode-sonra-kontrol" sıra hatasıydı; 2.4.50'nin eksik yaması (42013) kanıtın devamıydı. Soru: doğrulamadan önce veriyi kanonik biçime indirgedim mi?
4. Beyaz liste > kara liste (Bölüm 4, 8, 12, 19, 20, 21, 23). Kara liste "kötü olanı engelle" der ve daima atlatılır (yeni bir bypass, bir kodlama, bir uzantı). Beyaz liste "yalnızca iyi olana izin ver" der. Bu kitap boyunca kara liste her seferinde başarısız oldu; beyaz liste her seferinde kazandı. Soru: izin verdiklerimi mi, yasakladıklarımı mı sayıyorum?
5. Derinlemesine savunma: tek katman yetmez (Bölüm 1, tüm bölümler). Hiçbir kontrol kusursuz değildir. Optus'ta beş temel kontrolün hepsi eksikti ve bir "domino"ya dönüştü; herhangi biri olsaydı ihlal kırılırdı. Web shell savunması iki cephelidir (yerleşmeyi önle + çalışmayı engelle); container güvenliği katmanlıdır. Soru: bu kontrol düşerse, arkasında başka bir katman var mı?
6. Geçerli imza ≠ güvenilir iddia (Bölüm 23, 24, 33). Bir şeyin imzalı/geçerli olması, güvenilir olduğu anlamına gelmez. JWT'de imza doğru ama algoritma saldırgan-kontrollü olabilir; Sign in with Apple'da Apple gerçekten imzalamıştı ama özneyi doğrulamamıştı; SolarWinds'te artefakt gerçekten imzalıydı ama build ele geçirilmişti. Soru: buna yalnızca "geçerli/imzalı" olduğu için mi güveniyorum — ne iddia ettiğini doğruladım mı?
7. Debug/ayrıntılı hata üretimde = felaket (Bölüm 26, 36, 37). display_errors, Laravel Ignition, Symfony Profiler — üçü de aynı ders: geliştirmede paha biçilmez olan ayrıntılı hata/debug araçları, üretimde bilgi ifşasından (yol, kaynak, sır, kimlik bilgisi) RCE'ye tırmanır. Soru: üretimde debug/verbose kapalı mı?
8. Yapılandırma ve ekosistem, kod kadar önemli (Bölüm 26-30, 35). En kusursuz kod bile, yanlış yapılandırılmış bir ortamda (php.ini, web sunucusu, izinler, container) veya ele geçirilmiş bir bağımlılıkta (Composer, WordPress eklentisi) savunmasızdır. Güvenlik yalnızca yazdığınız kod değildir; onu çalıştıran her şeydir. Soru: kodum kadar ortamım ve bağımlılıklarım da güvenli mi?
9. Göremediğini savunamazsın (Bölüm 31). Tespit, savunmanın son ve vazgeçilmez katmanıdır. Equifax'ın süresi dolmuş sertifikası izlemeyi 76 gün kör etti; izleme geri gelince ihlal anında görüldü. Soru: yanılırsam, fark edebilir miyim?
10. Gizleme ihlalden kötüdür; süreç ve etik önemlidir (Bölüm 3, 30, 32). Uber'in CSO'su ihlal yüzünden değil, örtbas yüzünden mahkûm oldu. PHP git backdoor'unu otomatik araç değil insan kod incelemesi yakaladı. Güvenlik salt teknik değil, süreç ve etik meselesidir. Soru: yanlış giderse doğru olanı mı yapacağım?
11. Eski açıklar geri döner; güvenlik bitmiş bir iş değildir (Bölüm 23, 26). CVE-2024-4577, 2012'de kapatılan bir açığın yeniden doğuşuydu; JWT'nin 2015 hataları hâlâ yeni kodda görülüyor; Apache'nin ilk yaması eksikti. Bir açığın "çözülmüş" olması, bir kenar-durumla geri dönmeyeceği anlamına gelmez. Soru: bunu "hallolmuş" mu sayıyorum — bir varyantı geri gelebilir mi?
12. Kimlik doğrulama ≠ yetkilendirme (Bölüm 12, 14, 15, 22, 35). "Kimsin?" ile "buna erişebilir misin?" farklı sorulardır. First American ve Optus'ta kimlik doğrulama vardı ama nesne-düzeyi yetki (BOLA/IDOR) yoktu; WordPress'te nonce (CSRF) yetki vermez. Soru: kimliği doğruladım — peki bu kaynağa/eyleme yetkili olduğunu da doğruladım mı?
4. Savunmacının Zihinsel Modeli
Yukarıdaki on iki ilke, pratikte birkaç alışkanlık sorusuna indirgenebilir. Yeni bir özellik yazarken, bir kod incelemesi yaparken veya bir sistemi denetlerken, kendinize şunları sorun:
Veri akışı (güven sınırı):
- Güvenilmez veri nereden giriyor ve hangi güçlü bağlamlara (SQL, HTML, kabuk, şablon, dosya sistemi, deserializer, eval) ulaşabiliyor?
- Doğrulamadan önce kanonikleştiriyor muyum? Beyaz liste mi kullanıyorum?
Yetki ve etki: - Kimlik doğrulama var — peki bu nesneye/eyleme yetki de doğrulanıyor mu? - Bu bileşen ele geçirilirse hasar ne kadar? En az yetki uyguladım mı?
Güven ve doğrulama: - Buna yalnızca "geçerli/imzalı/dahili/güvenilir kaynaktan" olduğu için mi güveniyorum? Ne iddia ettiğini doğruladım mı? - Tek bir kontrole mi bel bağlıyorum, yoksa katmanlarım var mı?
Ortam ve süreç: - Üretimde debug/verbose kapalı mı? Yapılandırmam, bağımlılıklarım ve ekosistemim kodum kadar güvenli mi? - Yanılırsam fark edebilir miyim (loglama/izleme)? Yanlış giderse doğru müdahale ve açıklamayı yapabilir miyim?
Bu sorular, 37 bölümün özüdür. Bir açığın adını hatırlamasanız bile, bu soruları sorarsanız çoğu açığı yakalarsınız — ve daha önemlisi, henüz keşfedilmemiş olanları da.
5. Bu Kitabı Bundan Sonra Nasıl Kullanmalı
Bu kitap bir referanstır, bir kez okunup rafa kaldırılacak bir roman değil. Önerilen kullanım:
- Kod incelemesinde: İlgili bölümün Checklist (15) ve Detection (12) kısımlarını bir denetim listesi olarak kullanın.
grepdesenleri, hızlı bir ilk taramadır. - Yeni özellik tasarlarken: İlgili açık sınıfının Güvenli Kod (8) ve Prevention (13) kısımlarını referans alın; kalıpları kendi bağlamınıza uyarlayın.
- Bir olay sonrası: Incident Response (Bölüm 32), Web Shell Analizi (34) ve ilgili açığın Mitigation (14) kısmına gidin.
- Framework'e özgü: WordPress/Laravel/Symfony (35-37) bölümleri, o framework'ün güvenli varsayılanlarını ve tuzaklarını özetler.
- Öğretirken/öğrenirken: Her bölümün Laboratuvar (16) ve Quiz (17) kısımları, izole ortamda pratik ve kendini sınama içindir.
- Güncel kalmak için: Bu kitaptaki CVE'ler zamanla eskir; ama kök nedenler (Bölüm 3) eskimез. Yeni bir CVE okuduğunuzda, "bu on iki ilkeden hangisinin ihlali?" diye sorun — yerini hemen bulacaksınız.
Ve unutmayın: bu kitaptaki hiçbir teknik, izinsiz sistemlerde kullanılmak için değildir. Tüm laboratuvarlar izole ortamlar içindir; tüm bilgi savunma içindir. Bir açığı anlamak, onu istismar etmek için değil, önlemek içindir — kitabın önsözündeki etik taahhüt, son sayfasında da geçerlidir.
6. Kapanış
Web güvenliği, kazanılıp bitirilen bir savaş değildir; sürekli bir disiplindir. Saldırganlar yeni teknikler bulacak, framework'ler yeni özellikler ekleyecek, bulut yeni soyutlamalar getirecek — ve her yeni katman, yeni bir saldırı yüzeyi taşıyacak. Bu kitaptaki 37 CVE, on yıl sonra tarihe karışmış olabilir; ama altlarındaki on iki kök neden, muhtemelen o zaman da yeni açıkların altında yatıyor olacak.
Bu yüzden bir güvenlik uzmanının en değerli özelliği, bildiği açıkların sayısı değil — düşünme biçimidir. Güvenilmez verinin nereye aktığını görmek. "Ya bu başarısız olursa?" diye sormak. Bir şeye yalnızca "geçerli görünüyor" diye güvenmemek. Katmanlar inşa etmek. Görebilmek. Ve yanıldığında doğru olanı yapmak.
Bu kitabı buraya kadar okuduysanız, artık bu düşünme biçimine sahipsiniz. Kalan tek şey, onu her gün — her satır kodda, her tasarım kararında, her incelemede — uygulamaktır. Çünkü güvenlik, bir bölümde öğrenilen bir konu değil; her bölümde, her seferinde yeniden uygulanan bir alışkanlıktır.
İyi savunmalar dileriz.
7. Kaynakça (Genel)
Bu kitap boyunca atıf yapılan başlıca standart ve kaynaklar: - OWASP — Top 10 (2021), API Security Top 10 (2023), ASVS, WSTG, ve tüm Cheat Sheet Serisi. - MITRE — CWE (Common Weakness Enumeration) ve CVE/ATT&CK veritabanları. - NIST — SP 800-61 (Olay Müdahalesi), SP 800-92 (Log Yönetimi), SP 800-190 (Container), SP 800-161 (Tedarik Zinciri), SSDF (SP 800-218). - IETF RFC'leri — HTTP, TLS, JWT/JWS (7519/7515/8725), OAuth 2.0/PKCE (6749/7636/9700), OpenID Connect. - NVD ve satıcı danışmaları — bu kitaptaki tüm CVE'lerin birincil kaynağı. - PHP Manual ve framework dokümantasyonları (Laravel, Symfony, WordPress). - Bağımsız araştırmacı yayınları ve güvenlik firmalarının analizleri (her bölümün Kaynakça'sında ayrıntılı).
— PHP Güvenliği El Kitabı, son._