# Kod İçindeki Kritik Güvenlik Açıkları: CWE ve OWASP Perspektifi

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/kaynak-kod-analizi/koddaki-kritik-guvenlik-aciklari-cwe-owasp

![Kod İçindeki Kritik Güvenlik Açıkları: CWE ve OWASP Perspektifi](/images/bilgi-merkezi/covers/cover-kod-05.webp)

Bir yazılımın kaynak kodunda bulunan her hata güvenlik açığı değildir.

Bazı hatalar uygulamanın çökmesine neden olur.

Bazıları performansı etkiler.

Bazıları kullanıcı deneyimini bozar.

Bazıları ise saldırganın sisteme erişmesine, yetkisini yükseltmesine, başka kullanıcılara ait verilere ulaşmasına veya doğrudan sunucu üzerinde komut çalıştırmasına yol açabilir.

İşte kaynak kod güvenliği açısından asıl odaklanılması gereken alan burasıdır.

Modern yazılım güvenliğinde amaç yalnızca “kod hatası” bulmak değildir.

Asıl amaç:

**saldırgan tarafından kullanılabilecek kod zayıflıklarını mümkün olduğunca erken tespit etmektir.**

Bu zayıflıkların ortak bir dil içerisinde tanımlanabilmesi için farklı referans modelleri kullanılır.

Bunların başında:

#### CWE – Common Weakness Enumeration

ve

#### OWASP – Open Worldwide Application Security Project

gelir.

CWE, yazılım güvenliği zayıflıklarını sınıflandırmak için kapsamlı bir yapı sunar.

OWASP ise özellikle web ve uygulama güvenliği alanında en kritik risk kategorilerinin anlaşılmasına yardımcı olur.

Bu iki yapı birlikte değerlendirildiğinde yalnızca “hangi açık var?” sorusuna değil;

**“Bu açık neden oluştu, hangi zayıflık sınıfına giriyor ve nasıl tekrar engellenebilir?”**

sorusuna da cevap verilebilir.

Bu bölümde kaynak kod içerisinde karşılaşılan en kritik güvenlik açıklarını teknik mantıklarıyla birlikte ele alacağız.

### \1. CWE Nedir?

CWE, yani **Common Weakness Enumeration**, yazılım ve donanım güvenliği zayıflıklarını ortak bir sınıflandırma altında toplamayı amaçlayan bir yapıdır.

Buradaki önemli kelime “weakness”, yani zayıflıktır.

CWE doğrudan belirli bir üründeki tekil güvenlik açığını ifade etmez.

Bunun yerine güvenlik açığının kök nedenini veya zayıflık türünü sınıflandırır.

Örneğin bir uygulamada SQL Injection bulunabilir.

Bu tekil zafiyet bir güvenlik açığıdır.

Ancak bu açığın altında yatan temel zayıflık, kullanıcı kontrollü verinin SQL sorgusunun yapısına güvenli olmayan şekilde dahil edilmesidir.

CWE bu tür kök nedenleri standardize eder.

Bu standardizasyon özellikle büyük kurumlar için önemlidir.

Çünkü binlerce bulgu içerisinde tekrar eden güvenlik problemleri analiz edilebilir.

Örneğin bir kurum şu sonuçları görebilir:

- Authentication hataları sık tekrar ediyor.
- Authorization problemleri belirli ekiplerde yoğunlaşıyor.
- Injection zafiyetleri belirli framework'lerde daha fazla görülüyor.
- Hard-coded secret problemi belirli repository gruplarında tekrar ediyor.

Bu bilgi doğrudan Secure Coding eğitimlerine ve geliştirme standartlarına girdi sağlayabilir.

### \2. CVE ile CWE Arasındaki Fark Nedir?

CWE ile CVE sıkça karıştırılır.

Ancak ikisi farklı amaçlara hizmet eder.

**CVE – Common Vulnerabilities and Exposures**, belirli bir ürün veya yazılım içerisindeki bilinen güvenlik açığını tanımlamak için kullanılır.

CWE ise o açığın hangi tür yazılım zayıflığından kaynaklandığını açıklar.

Basit bir örnekle:

Bir ürünün belirli sürümünde SQL Injection açığı bulunabilir.

Bu açığa bir CVE numarası atanabilir.

Ancak ilgili problemin yazılım zayıflığı kategorisi CWE altında Injection veya SQL Injection türünde sınıflandırılır.

Kısaca:

**CVE = Belirli güvenlik açığı**

**CWE = Güvenlik açığının zayıflık türü**

Bu ayrım kaynak kod analizi açısından oldukça önemlidir.

Çünkü SAST çoğu zaman bir CVE aramaz.

Kaynak kod içerisindeki **CWE türü zayıflıkları** arar.

### \3. OWASP Top 10 Nedir?

OWASP Top 10, web uygulamalarında en kritik güvenlik risklerini görünür hale getiren en bilinen güvenlik referanslarından biridir.

OWASP Top 10 özellikle yöneticiler, geliştiriciler ve güvenlik ekipleri arasında ortak dil oluşmasına yardımcı olur.

Ancak önemli bir nokta vardır:

**OWASP Top 10 bir kaynak kod kontrol listesi değildir.**

Ayrıca bir uygulamanın yalnızca OWASP Top 10 açısından test edilmesi uygulamanın tamamen güvenli olduğu anlamına gelmez.

OWASP Top 10 geniş risk kategorilerini ifade eder.

CWE ise çok daha detaylı zayıflık türlerini sınıflandırabilir.

Bu nedenle profesyonel kaynak kod güvenliği çalışmalarında:

**OWASP + CWE + Secure Coding Standardı + Uygulama İş Mantığı**

birlikte değerlendirilmelidir.

### \4. Injection Nedir?

Injection, saldırgan tarafından kontrol edilen verinin uygulama tarafından komut veya sorgunun bir parçası gibi yorumlanması sonucunda ortaya çıkan güvenlik açığı sınıfıdır.

Bu sınıfa birçok farklı saldırı türü girebilir.

Örneğin:

- SQL Injection
- Command Injection
- LDAP Injection
- NoSQL Injection
- XPath Injection
- Template Injection

Injection problemlerinin ortak noktası şudur:

**Veri ile komut birbirinden güvenli şekilde ayrılmamıştır.**

Bu nedenle saldırgan gönderdiği girdinin yalnızca veri olarak işlenmesini değil, uygulamanın davranışını değiştirmesini sağlayabilir.

Injection açıkları kaynak kod analizinde en kritik kontrol alanlarından biridir.

### \5. SQL Injection Nasıl Oluşur?

SQL Injection, kullanıcı kontrollü verinin SQL sorgusuna güvenli olmayan şekilde dahil edilmesi sonucunda ortaya çıkar.

Örneğin geliştirici kullanıcı adını almak için şu mantığı kullanabilir:

SELECT * FROM users WHERE username = ' + userInput + '

Normal kullanıcı şu değeri gönderir:

ramazan

Sorgu şu hale gelir:

SELECT * FROM users WHERE username = 'ramazan'

Ancak saldırgan SQL syntax'ını değiştirecek özel karakterler gönderebilir.

Eğer uygulama girdiyi doğrudan sorguya ekliyorsa saldırgan sorgunun yapısını değiştirebilir.

Bu saldırının etkisi;

- veri okuma,
- veri değiştirme,
- authentication bypass,
- veri silme,
- bazı ortamlarda ileri sistem erişimi

gibi ciddi sonuçlara kadar ilerleyebilir.

SQL Injection probleminin temel kök nedeni çoğu zaman şudur:

**String concatenation ile dinamik SQL oluşturulması.**

### \6. SQL Injection Nasıl Engellenir?

SQL Injection'ın temel çözümü kullanıcı girdisini filtrelemekten çok, veri ile SQL komutunu birbirinden ayırmaktır.

Bu nedenle **Parameterized Query** veya **Prepared Statement** kullanımı kritik öneme sahiptir.

Güvenli yaklaşım şu mantıktadır:

SELECT * FROM users WHERE username = ?

Kullanıcı girdisi sorgunun yapısına eklenmez.

Ayrı parametre olarak veritabanı motoruna iletilir.

Böylece veritabanı kullanıcı girdisini SQL syntax'ı değil veri olarak yorumlar.

Ayrıca;

- ORM kullanımı,
- Least Privilege database account,
- input validation,
- güvenli hata yönetimi

gibi ek kontroller uygulanabilir.

Ancak ORM kullanmak otomatik olarak SQL Injection olmayacağı anlamına gelmez.

Raw query veya unsafe query fonksiyonları yanlış kullanılırsa risk yeniden oluşabilir.

### \7. Command Injection Nedir?

Command Injection, kullanıcı kontrollü verinin işletim sistemi komutunun bir parçası haline gelmesi sonucunda ortaya çıkan kritik güvenlik açığıdır.

Örneğin bir uygulamada kullanıcının IP adresi girmesi ve sistemin ping testi yapması istenebilir.

Geliştirici şu mantığı kullanabilir:

ping + userInput

Bu durumda saldırgan komut birleştirme karakterleri kullanarak farklı işletim sistemi komutlarını çalıştırmaya çalışabilir.

Başarılı Command Injection saldırısı;

- dosya okuma,
- dosya değiştirme,
- yeni process çalıştırma,
- ağ üzerinde keşif,
- credential erişimi,
- sunucunun tamamen ele geçirilmesi

gibi sonuçlara yol açabilir.

Bu nedenle Command Injection genellikle yüksek veya kritik riskli güvenlik açığı olarak değerlendirilir.

### \8. Command Injection Nasıl Engellenir?

En güvenli yaklaşım kullanıcı girdisini doğrudan işletim sistemi shell komutuna aktarmamaktır.

Mümkünse işletim sistemi komutu yerine güvenli programlama kütüphaneleri kullanılmalıdır.

Örneğin ping işlemi için doğrudan shell çağırmak yerine network library kullanılabilir.

Eğer dış process çağırılması zorunluysa:

- allowlist input validation,
- sabit parametre setleri,
- shell yorumlamasının kapatılması,
- least privilege service account

gibi kontroller uygulanmalıdır.

Temel prensip şudur:

**Kullanıcı girdisi komut syntax'ının bir parçası olmamalıdır.**

### \9. Cross-Site Scripting – XSS Nedir?

Cross-Site Scripting, kullanıcı kontrollü verinin güvenli şekilde işlenmeden web sayfasına aktarılması sonucunda saldırganın başka kullanıcıların tarayıcılarında script çalıştırabilmesine yol açan güvenlik açığıdır.

XSS özellikle web uygulamalarında sık karşılaşılan problemlerden biridir.

Başarılı bir XSS saldırısı;

- kullanıcı oturumlarının hedeflenmesi,
- sayfa içeriğinin değiştirilmesi,
- sahte form oluşturulması,
- kullanıcı adına işlem yapılması,
- hassas verilerin çalınması

gibi sonuçlara yol açabilir.

XSS'nin temel problemi çoğu zaman şudur:

**Güvenilmeyen veri ile HTML/JavaScript çıktısı güvenli şekilde ayrılmamıştır.**

### \10. Stored XSS Nedir?

Stored XSS saldırısında zararlı veri önce uygulama içerisinde saklanır.

Örneğin saldırgan forum yorumuna zararlı içerik ekleyebilir.

Bu içerik veritabanında tutulur.

Daha sonra başka kullanıcılar ilgili sayfayı açtığında zararlı script tarayıcılarında çalışır.

Bu nedenle Stored XSS bazen Reflected XSS'e göre daha yüksek etkiye sahip olabilir.

Çünkü saldırgan tek tek kullanıcıları özel bağlantıya yönlendirmek zorunda kalmayabilir.

Zararlı içerik uygulamanın normal işleyişi içerisinde birçok kullanıcıya ulaştırılabilir.

### \11. Reflected XSS Nedir?

Reflected XSS saldırısında zararlı veri uygulamada kalıcı olarak saklanmaz.

Kullanıcının gönderdiği değer aynı HTTP response içerisinde güvenli şekilde encode edilmeden geri döndürülür.

Örneğin arama sayfası şu metni gösterebilir:

**“X için arama sonuçları”**

Eğer X değeri kullanıcı tarafından kontrol ediliyor ve doğrudan HTML içerisine yazılıyorsa saldırgan özel hazırlanmış link oluşturabilir.

Kullanıcı bu linki açtığında zararlı script çalışabilir.

### \12. DOM-Based XSS Nedir?

DOM-Based XSS daha çok istemci tarafındaki JavaScript kodunda ortaya çıkar.

Burada server response güvenli olabilir.

Ancak frontend JavaScript kullanıcı kontrollü veriyi DOM içerisine güvenli olmayan şekilde aktarabilir.

Örneğin:

URL fragment değerinin doğrudan innerHTML benzeri riskli fonksiyonlara aktarılması problem oluşturabilir.

Bu nedenle modern kaynak kod analizi yalnızca backend kodlarına değil frontend JavaScript ve TypeScript kodlarına da uygulanmalıdır.

### \13. XSS Nasıl Engellenir?

XSS'in temel önlemi **context-aware output encoding** yaklaşımıdır.

Yani veri hangi bağlamda kullanılacaksa ona uygun şekilde encode edilmelidir.

HTML içeriği,

HTML attribute,

JavaScript,

CSS,

URL

farklı bağlamlardır.

Ayrıca modern framework'lerin otomatik output encoding özellikleri kullanılmalı ve gereksiz şekilde devre dışı bırakılmamalıdır.

Content Security Policy gibi tarayıcı güvenlik mekanizmaları da ek savunma katmanı sağlayabilir.

Ancak CSP, güvenli kodlamanın yerine geçmez.

### \14. Broken Access Control Nedir?

Broken Access Control, kullanıcıların normalde erişmemesi gereken veri veya fonksiyonlara ulaşabilmesine neden olan yetkilendirme problemidir.

Modern uygulamalardaki en kritik risklerden biridir.

Örneğin kullanıcı şu endpoint üzerinden kendi faturasını görüntülüyor olabilir:

GET /api/invoice/1201

Saldırgan bu değeri:

GET /api/invoice/1202

olarak değiştirdiğinde başka müşterinin faturası görüntüleniyorsa access control problemi bulunmaktadır.

Uygulama kullanıcının login olduğunu kontrol etmiş olabilir.

Ancak ilgili faturaya erişim yetkisinin bulunup bulunmadığını kontrol etmemiştir.

Bu nedenle authentication tek başına yeterli değildir.

Her kritik işlemde authorization kontrolü gerekir.

### \15. IDOR Nedir?

IDOR, yani **Insecure Direct Object Reference**, uygulamanın doğrudan nesne identifier'larına erişim sağladığı ancak gerekli authorization kontrolünü yapmadığı durumlarda ortaya çıkabilir.

Örneğin:

/customer/1001

/customer/1002

gibi tahmin edilebilir ID yapıları bulunabilir.

Ancak burada önemli bir nokta vardır:

Problem ID'nin tahmin edilebilir olması değildir.

Asıl problem:

**Backend tarafında authorization kontrolünün bulunmamasıdır.**

UUID kullanmak saldırıyı zorlaştırabilir ancak gerçek güvenlik çözümü değildir.

Yetkilendirme her istekte server-side olarak doğrulanmalıdır.

### \16. BOLA Nedir?

API güvenliği alanında özellikle **BOLA – Broken Object Level Authorization** kavramı kullanılır.

BOLA, API'nin nesne seviyesinde gerekli yetkilendirme kontrolünü gerçekleştirmemesi anlamına gelir.

Örneğin kullanıcı kendi banka hesabına ait API isteği gönderiyor olabilir.

JSON içerisinde:

accountId: 5412

bulunabilir.

Saldırgan accountId değerini başka bir hesaba ait ID ile değiştirdiğinde sistem yine işlem yapıyorsa BOLA problemi vardır.

API tabanlı sistemlerde bu tür problemler kritik öneme sahiptir.

### \17. Broken Function Level Authorization

Yetkilendirme yalnızca veri nesnesi seviyesinde değil fonksiyon seviyesinde de uygulanmalıdır.

Örneğin standart kullanıcı şu endpoint'i çağırmamalıdır:

/api/admin/deleteUser

Frontend arayüzünde admin butonunun gizlenmesi güvenlik kontrolü değildir.

Saldırgan endpoint'i doğrudan çağırabilir.

Bu nedenle backend her istekte rol ve yetki kontrolü yapmalıdır.

### \18. Server-Side Request Forgery – SSRF Nedir?

SSRF, saldırganın sunucunun başka sistemlere network isteği göndermesini sağlaması sonucunda ortaya çıkar.

Örneğin uygulamada kullanıcıdan URL alan bir özellik bulunabilir:

**“Bu URL'deki resmi indir.”**

Backend kullanıcı tarafından verilen URL'ye request gönderiyorsa saldırgan farklı hedefler belirlemeye çalışabilir.

Örneğin:

- localhost
- internal server
- private IP
- management interface
- cloud metadata endpoint

gibi sistemler hedeflenebilir.

Bu durumda saldırgan doğrudan erişemediği sistemlere uygulama sunucusu üzerinden erişim sağlamaya çalışır.

### \19. SSRF Neden Bulut Ortamlarında Kritiktir?

Bulut ortamlarında uygulama sunucuları bazen metadata servislerine erişebilir.

Bu servisler instance yapılandırmaları veya credential benzeri kritik bilgiler sağlayabilir.

SSRF açığı sayesinde saldırgan bu endpoint'lere istek göndertebilirse ciddi güvenlik riski ortaya çıkabilir.

Bu nedenle cloud-native uygulamalarda SSRF özel olarak değerlendirilmelidir.

### \20. SSRF Nasıl Engellenir?

SSRF önlemlerinde yalnızca URL içerisindeki belirli kelimeleri engellemek yeterli değildir.

Daha güçlü yaklaşım:

- izin verilen domainlerin allowlist ile belirlenmesi,
- internal IP aralıklarının engellenmesi,
- DNS resolution sonrasında IP kontrolü yapılması,
- redirect zincirlerinin kontrol edilmesi,
- uygulama sunucusunun network erişiminin sınırlandırılması

gibi kontrolleri birlikte kullanmaktır.

Burada kod güvenliği ve network segmentasyonu birlikte çalışır.

### \21. Path Traversal Nedir?

Path Traversal, kullanıcı kontrollü verinin dosya yolu oluşturulmasında güvenli olmayan şekilde kullanılması sonucunda saldırganın izin verilen dizinin dışındaki dosyalara erişebilmesine yol açan güvenlik problemidir.

Örneğin uygulama:

/files/report.pdf

dosyasını gösterebilir.

Ancak kullanıcı filename parametresini kontrol edebiliyorsa saldırgan dizin geçiş karakterleri kullanarak farklı dosyalara erişmeye çalışabilir.

Bu saldırı bazı sistemlerde hassas configuration dosyalarının veya credential bilgilerinin okunmasına yol açabilir.

### \22. Path Traversal Nasıl Engellenir?

Güvenli yaklaşım kullanıcıdan tam dosya yolu almamaktır.

Bunun yerine önceden tanımlanmış identifier ile server-side mapping kullanılabilir.

Eğer kullanıcı girdisi kullanılması gerekiyorsa:

- canonical path doğrulaması,
- allowlist dosya adları,
- belirli base directory dışına çıkışın engellenmesi,
- erişim izinlerinin sınırlandırılması

uygulanmalıdır.

### \23. Unrestricted File Upload Nedir?

Dosya yükleme mekanizmaları doğru tasarlanmadığında saldırgan tarafından kötüye kullanılabilir.

Örneğin uygulama sadece .jpg uzantısını kontrol ediyor olabilir.

Saldırgan farklı tekniklerle çalıştırılabilir dosya yüklemeyi deneyebilir.

Risk kullanılan teknolojiye bağlı olarak;

- zararlı dosya barındırma,
- stored XSS,
- malware dağıtımı,
- disk tüketimi,
- bazı durumlarda remote code execution

gibi sonuçlara ulaşabilir.

Dosya upload güvenliğinde birden fazla kontrol birlikte kullanılmalıdır.

### \24. Güvenli Dosya Yükleme Kontrolleri

Dosya yükleme sırasında yalnızca uzantı kontrolü yeterli değildir.

Kontrol edilmesi gereken başlıca alanlar:

- izin verilen dosya türleri,
- gerçek içerik,
- MIME type,
- dosya büyüklüğü,
- dosya adı,
- storage path,
- execution permission,
- erişim yöntemi

olmalıdır.

Dosyaların mümkün olduğunca web root dışında tutulması ve uygulama tarafından doğrudan çalıştırılmaması önemlidir.

### \25. Insecure Deserialization Nedir?

Serialization bir nesnenin saklanabilir veya aktarılabilir formata dönüştürülmesini ifade eder.

Deserialization ise bunun tersidir.

Eğer uygulama güvenilmeyen kaynaktan gelen veriyi kontrolsüz şekilde deserialize ederse saldırgan beklenmeyen nesneler veya kod yolları oluşturabilir.

Belirli teknoloji ve framework'lerde bu durum Remote Code Execution seviyesine kadar ilerleyebilir.

Bu nedenle güvenilmeyen verilerin deserialize edilmesi son derece dikkatli ele alınmalıdır.

### \26. Güvensiz Deserialization Nasıl Engellenir?

Mümkün olduğunca güvenilmeyen kaynaktan gelen native serialized object formatları kullanılmamalıdır.

Basit veri formatları tercih edilebilir.

Ayrıca:

- allowlist type validation,
- imza doğrulaması,
- bütünlük kontrolleri,
- güvenli serializer ayarları

uygulanmalıdır.

En önemli prensip:

**Kullanıcı tarafından kontrol edilen verinin hangi nesnelere dönüşebileceği sınırlandırılmalıdır.**

### \27. Prototype Pollution Nedir?

Prototype Pollution özellikle JavaScript ekosisteminde görülebilen bir güvenlik problemidir.

JavaScript'teki prototype inheritance mekanizmasının yanlış kullanımı veya kontrolsüz object merge işlemleri sonucunda saldırgan global object davranışlarını etkileyebilir.

Örneğin kullanıcı kontrollü JSON verisi güvenli olmayan deep merge fonksiyonuna aktarılırsa saldırgan belirli özel property'leri manipüle etmeye çalışabilir.

Prototype Pollution;

- authorization bypass,
- application logic manipulation,
- bazı durumlarda XSS veya daha ileri saldırılar

ile zincirlenebilir.

### \28. XML External Entity – XXE Nedir?

XXE, XML parser'ın dış entity'leri güvenli olmayan şekilde işlemesi sonucunda ortaya çıkabilir.

Saldırgan özel hazırlanmış XML kullanarak sunucunun lokal dosyaları okumasına veya dış network kaynaklarına erişmesine neden olabilir.

Bazı senaryolarda XXE ile SSRF benzeri etkiler oluşabilir.

Modern XML parser'larda güvenli yapılandırma kullanılması kritik öneme sahiptir.

### \29. XXE Nasıl Engellenir?

Temel yaklaşım kullanılmıyorsa external entity desteğinin tamamen kapatılmasıdır.

Ayrıca:

- DTD işlemenin devre dışı bırakılması,
- güvenli parser kullanılması,
- framework güvenlik yapılandırmalarının uygulanması

gerekir.

Bu problem özellikle eski veya özel yapılandırılmış XML işleme sistemlerinde önemlidir.

### \30. Open Redirect Nedir?

Open Redirect, uygulamanın kullanıcı kontrollü bir URL'ye doğrulama yapmadan yönlendirme gerçekleştirmesidir.

Örneğin login sonrası:

/login?returnUrl=https://example.com

benzeri yapı kullanılabilir.

Saldırgan return URL değerini kendi zararlı sitesine değiştirebilirse uygulamanın güvenilir domainini phishing amacıyla kullanabilir.

Open Redirect tek başına her zaman kritik olmayabilir.

Ancak OAuth akışları veya authentication sistemleriyle birleştiğinde daha yüksek güvenlik riskine dönüşebilir.

### \31. Hard-Coded Credentials

Kaynak kod içerisinde parola, API key veya token tutulması sık karşılaşılan kod güvenliği problemlerinden biridir.

Örneğin:

db_password = "Secret123"

gibi bilgi doğrudan kaynak koda yazılabilir.

Repository ele geçirildiğinde saldırgan doğrudan credential'a ulaşabilir.

Daha önemlisi bilgi daha sonra koddan silinse bile Git geçmişinde kalabilir.

Bu nedenle Secret Scanning modern kod güvenliği programlarında ayrı bir katman olarak kullanılmalıdır.

### \32. Secret Yönetimi Nasıl Yapılmalıdır?

Hassas bilgiler mümkün olduğunca kaynak kod dışında tutulmalıdır.

Örneğin:

- Environment Variables
- Secrets Manager
- Vault
- Cloud Secret Store

gibi sistemler kullanılabilir.

Ayrıca credential rotation uygulanmalıdır.

Bir secret'ın repository'ye yanlışlıkla gönderildiği tespit edilirse sadece koddan silmek yeterli değildir.

İlgili credential **compromised kabul edilmeli ve değiştirilmelidir.**

### \33. Güvensiz Kriptografi Kullanımı

Kriptografi güçlü bir güvenlik mekanizmasıdır.

Ancak yanlış kullanıldığında sahte güvenlik hissi yaratabilir.

Örneğin:

- eski algoritma kullanılması,
- zayıf key length,
- sabit initialization vector,
- hard-coded encryption key,
- zayıf random number generator

gibi problemler ortaya çıkabilir.

Geliştiriciler kendi şifreleme algoritmalarını geliştirmemelidir.

Standart ve güvenilir kriptografik kütüphaneler kullanılmalıdır.

### \34. Parolalar Şifrelenmeli mi?

Parolalar klasik anlamda reversible encryption ile saklanmamalıdır.

Bunun yerine parola saklama amacıyla tasarlanmış güvenli password hashing algoritmaları kullanılmalıdır.

Amaç sistem yöneticisinin bile kullanıcının parolasını geri çözememesidir.

Parola doğrulaması hash üzerinden yapılmalıdır.

Ayrıca uygun salt ve algoritma parametreleri kullanılmalıdır.

### \35. Weak Randomness Nedir?

Güvenlik açısından kritik değerlerin tahmin edilebilir random number generator ile oluşturulması ciddi problem yaratabilir.

Örneğin:

- password reset token,
- session ID,
- API token,
- doğrulama kodu

gibi değerler kriptografik olarak güvenli random kaynaklarla üretilmelidir.

Normal uygulama random fonksiyonları her zaman güvenlik amacıyla uygun değildir.

Saldırgan gelecekte üretilecek değerleri tahmin edebiliyorsa authentication mekanizmaları bypass edilebilir.

### \36. Sensitive Data Exposure

Hassas verilerin gereğinden fazla tutulması veya korunmaması önemli risk oluşturur.

Örneğin:

- parola,
- kredi kartı verisi,
- kişisel veri,
- sağlık bilgisi,
- authentication token,
- private key

gibi bilgiler log, database veya response içerisinde gereksiz şekilde bulunabilir.

Güvenli yazılım geliştirmede temel prensiplerden biri:

**İhtiyacın olmayan hassas veriyi toplama ve saklama.**

şeklinde olmalıdır.

### \37. Hassas Verilerin Loglanması

Loglar güvenlik için gereklidir.

Ancak yanlış loglama ciddi veri ihlaline yol açabilir.

Örneğin API request body tamamen loglanıyorsa kullanıcı parolası veya access token loglara düşebilir.

Daha sonra log sistemine erişen biri bu bilgileri görebilir.

Bu nedenle logging standardı oluşturulmalı ve hassas alanlar maskelenmelidir.

### \38. Excessive Data Exposure

Özellikle API sistemlerinde backend bazen frontend'in ihtiyaç duyduğundan çok daha fazla veri döndürür.

Frontend yalnızca gerekli alanları gösterir.

Ancak saldırgan raw API response'u inceleyebilir.

Örneğin frontend:

ad,

soyad

gösteriyor olabilir.

API response içerisinde ise:

TC kimlik numarası,

telefon,

internal customer ID,

risk skoru

gibi ek bilgiler bulunabilir.

Frontend'de alanın gizlenmesi güvenlik kontrolü değildir.

Backend yalnızca gerçekten gerekli veriyi döndürmelidir.

### \39. Mass Assignment

Modern framework'lerde JSON veya form verisinin otomatik olarak model nesnesine bağlanması geliştirmeyi hızlandırır.

Ancak güvenli olmayan kullanım risk oluşturabilir.

Kullanıcının yalnızca:

name

ve

email

alanlarını değiştirmesi gerekirken backend bütün model alanlarını kabul ediyorsa saldırgan:

role=admin

gibi beklenmeyen property ekleyebilir.

Bu nedenle kullanıcı tarafından değiştirilebilir alanların açık şekilde allowlist ile belirlenmesi önerilir.

### \40. Security Misconfiguration Kod Seviyesinde Oluşabilir mi?

Evet.

Security Misconfiguration yalnızca sunucu ayarlarından ibaret değildir.

Kaynak kod içerisinde de güvenli olmayan default configuration bulunabilir.

Örneğin:

- debug mode açık olması,
- detaylı error message,
- CORS *,
- default admin credential,
- authentication kontrolünün development flag ile devre dışı bırakılması

gibi sorunlar kod repository'si içerisinde bulunabilir.

Bu nedenle SAST yanında configuration scanning de önemlidir.

### \41. Debug Kodları Production Ortamına Neden Gitmemelidir?

Geliştirme sırasında debug endpoint'leri oluşturulabilir.

Örneğin:

/debug/users

veya:

/test/loginAsAdmin

gibi fonksiyonlar geliştiriciye kolaylık sağlayabilir.

Ancak production release sırasında kaldırılmazsa kritik güvenlik açığı oluşabilir.

Bu nedenle CI/CD süreçlerinde environment-specific kontroller önemlidir.

### \42. Improper Error Handling

Hata yönetimi yalnızca kullanıcı deneyimi değildir.

Aynı zamanda güvenlik konusudur.

Detaylı exception bilgileri saldırgana uygulama hakkında değerli bilgiler verebilir.

Örneğin:

- database table adı,
- internal path,
- library version,
- source code location,
- query structure

gibi bilgiler açığa çıkabilir.

Kullanıcıya genel hata mesajı gösterilirken detaylar güvenli server loglarında tutulmalıdır.

### \43. Authentication Problemleri

Authentication mekanizmalarında birçok farklı kod güvenliği problemi oluşabilir.

Örneğin:

- zayıf password policy,
- brute force kontrolünün olmaması,
- tahmin edilebilir reset token,
- MFA bypass,
- session fixation,
- token validation hatası

gibi problemler kritik güvenlik riskleri yaratabilir.

Kaynak kod analizi özellikle authentication lifecycle üzerinde derin inceleme gerektirir.

### \44. JWT Güvenlik Hataları

Modern API sistemlerinde JWT yaygın olarak kullanılmaktadır.

Ancak yanlış implementasyon risklidir.

Örneğin:

- token signature doğrulanmaması,
- yanlış algoritma kullanımı,
- expiration kontrolünün yapılmaması,
- hassas verilerin payload içerisine eklenmesi,
- uzun ömürlü token kullanımı

gibi problemler oluşabilir.

JWT içerisindeki payload'ın varsayılan olarak şifrelenmiş olmadığı unutulmamalıdır.

Base64 encoding güvenlik değildir.

### \45. Session Management Problemleri

Kullanıcı sisteme giriş yaptıktan sonra session güvenliği kritik hale gelir.

Örneğin:

- session ID tahmin edilebilir olabilir,
- logout sonrası session aktif kalabilir,
- session süresi gereğinden uzun olabilir,
- privilege change sonrası session yenilenmeyebilir.

Bu tür problemler SAST ile kısmen incelenebilir ancak DAST ve manuel pentest ile birlikte değerlendirilmesi daha güçlü sonuç verir.

### \46. Race Condition

Race Condition, birden fazla işlemin aynı kaynak üzerinde beklenmeyen sırada veya eşzamanlı çalışması sonucunda güvenlik problemi oluşturabilir.

Örneğin bir bakiye kontrolü:

- Bakiye yeterli mi?
- Ödemeyi yap.
- Bakiyeyi azalt.

şeklinde çalışıyor olabilir.

Saldırgan aynı anda birden fazla request gönderirse bakiye azaltılmadan önce birden fazla ödeme onaylanabilir.

Bu tür problemler özellikle finans ve e-ticaret sistemlerinde kritik olabilir.

### \47. Time-of-Check to Time-of-Use – TOCTOU

TOCTOU Race Condition'ın özel türlerinden biridir.

Sistem bir kaynağı önce kontrol eder.

Daha sonra kullanır.

Ancak kontrol ve kullanım arasında kaynak değişebilir.

Özellikle dosya sistemi işlemleri ve yetki kontrollerinde risk oluşturabilir.

Bu tür zafiyetler statik analiz açısından daha karmaşık olabilir ve uzman incelemesi gerektirebilir.

### \48. Güvenlik Açıkları Neden Zincirlenir?

Tek bir güvenlik açığı her zaman sistemi tamamen ele geçirmeye yetmeyebilir.

Ancak saldırganlar çoğunlukla birden fazla açığı birlikte kullanır.

Örneğin:

#### Bilgi İfşası

↓

#### Kullanıcı ID Keşfi

↓

#### Broken Access Control

↓

#### Hassas Veri Erişimi

gibi saldırı zinciri oluşabilir.

Başka senaryoda:

#### SSRF

↓

#### Internal Service Discovery

↓

#### Credential Access

↓

#### Privilege Escalation

gibi daha ileri saldırılar meydana gelebilir.

Bu nedenle güvenlik bulguları yalnızca bağımsız şekilde değil saldırı zinciri açısından da değerlendirilmelidir.

### \49. CWE Neden Kurumsal Güvenlik Ölçümünde Kullanılmalıdır?

Kaynak kod analizi çalışmasının gerçek değeri yalnızca tek bir proje raporunda kalmamalıdır.

CWE mapping sayesinde kurum zaman içerisinde güvenlik verisi biriktirebilir.

Örneğin yıl sonunda şu sonuç görülebilir:

#### %28 Authorization

#### %19 Input Validation

#### %17 Secret Management

#### %14 Cryptography

#### %22 Diğer

Bu veri çok değerlidir.

Çünkü kurumun hangi alanda sistematik problemi olduğunu gösterir.

Örneğin authorization sürekli ilk sıradaysa:

- Secure Coding standardı,
- framework tasarımı,
- eğitim programı,
- code review checklist'i

bu alana göre güncellenebilir.

### \50. Güvenlik Açığını Bulmaktan Kök Nedeni Bulmaya

Olgun Application Security programının temel farkı burada ortaya çıkar.

Başlangıç seviyesindeki program şu soruyu sorar:

#### Kaç güvenlik açığımız var?

Daha olgun program ise şunu sorar:

#### Neden sürekli aynı güvenlik açıklarını üretiyoruz?

Örneğin sürekli SQL Injection bulunuyorsa sadece mevcut bulguların kapatılması yeterli değildir.

Geliştiricilerin neden string concatenation kullandığı araştırılmalıdır.

Standart database helper library oluşturulabilir.

Secure Coding eğitimi verilebilir.

SAST Quality Gate uygulanabilir.

Böylece tek tek güvenlik açığı kapatmak yerine problemin kök nedeni ortadan kaldırılır.

### \51. OWASP ASVS Neden Önemlidir?

OWASP Top 10 güvenlik risklerini anlamak için güçlü bir başlangıç noktasıdır.

Ancak kurumsal güvenlik doğrulaması için daha sistematik yapı gerekebilir.

Bu noktada **OWASP ASVS – Application Security Verification Standard** önem kazanır.

ASVS;

- authentication,
- session management,
- access control,
- validation,
- cryptography,
- logging,
- API güvenliği

gibi alanlarda detaylı güvenlik gereksinimleri sağlar.

Kaynak kod analizi ve manuel güvenlik testlerinde ASVS referans olarak kullanılabilir.

Bu sayede değerlendirme yalnızca zafiyet aramaktan çıkarak güvenlik kontrollerinin doğrulanmasına dönüşür.

### \52. Güçlü Bir Kod Güvenliği Programının Temeli

Kaynak kod içerisindeki kritik güvenlik açıklarını azaltmak için tek bir teknoloji yeterli değildir.

Güçlü bir yapı şu bileşenlerden oluşabilir:

#### Secure Coding

Güvenlik problemlerinin oluşmasını engellemeye çalışır.

#### SAST

Kod içerisindeki zayıflıkları otomatik tespit eder.

#### SCA

Üçüncü taraf bileşenleri analiz eder.

#### Secret Scanning

Hassas credential bilgilerini tespit eder.

#### Manual Code Review

Business Logic ve karmaşık güvenlik problemlerini inceler.

#### DAST

Çalışan uygulamayı test eder.

#### Pentest

Gerçek saldırgan davranışını simüle eder.

Bu katmanların birlikte çalışması modern Application Security programının temelini oluşturur.

### SecureSys CWE ve OWASP Tabanlı Kaynak Kod Güvenliği Yaklaşımı

SecureSys olarak kaynak kod analizi çalışmalarında güvenlik bulgularını yalnızca araçların verdiği teknik isimlerle değerlendirmiyoruz.

Bulgunun;

**kök nedeni, CWE kategorisi, OWASP ilişkisi, istismar edilebilirliği, erişilebilirliği ve iş etkisi**

birlikte ele alınmalıdır.

Projenin kapsamına göre kaynak kod analizlerinde;

- Injection riskleri,
- Authentication problemleri,
- Authorization hataları,
- Business Logic zafiyetleri,
- Hassas veri kullanımı,
- Kriptografi,
- File Handling,
- SSRF,
- Secret Management,
- API güvenliği

gibi alanlar değerlendirilebilir.

SAST çıktıları uzman doğrulamasından geçirilebilir.

Kritik kod bölümleri manuel incelenebilir.

Çalışan uygulama üzerinde sızma testiyle bulguların gerçek saldırı yüzeyindeki etkisi değerlendirilebilir.

Böylece kaynak kod analizi yalnızca:

**“Kodda hangi açık var?”**

sorusuna cevap vermez.

Aynı zamanda:

**“Bu açık neden oluştu ve tekrar oluşmasını nasıl engelleyebiliriz?”**

sorusuna da cevap verir.

Gerçek kod güvenliği olgunluğu da tam olarak burada başlar.

### Sık Sorulan Sorular

#### CWE nedir?

CWE, Common Weakness Enumeration ifadesinin kısaltmasıdır. Yazılım ve donanım güvenliği zayıflıklarını ortak kategoriler altında sınıflandırmak için kullanılır.

#### CWE ile CVE arasındaki fark nedir?

CVE belirli bir ürün veya yazılımdaki tekil güvenlik açığını ifade eder. CWE ise güvenlik açığının altında yatan zayıflık türünü sınıflandırır.

#### OWASP Top 10 nedir?

OWASP Top 10, web uygulamalarında en önemli güvenlik risk kategorilerini görünür hale getiren referans çalışmadır.

#### SQL Injection neden oluşur?

Kullanıcı kontrollü verilerin güvenli olmayan şekilde SQL sorgularının yapısına dahil edilmesi sonucunda oluşur.

#### Broken Access Control nedir?

Kullanıcının yetkisi olmayan veri veya fonksiyonlara erişebilmesine yol açan authorization problemidir.

#### IDOR nedir?

Uygulamanın nesne identifier'larını kullanırken yeterli yetkilendirme kontrolü yapmaması nedeniyle başka nesnelere erişim sağlanabilmesidir.

#### SSRF nedir?

Saldırganın uygulama sunucusunu kullanarak sunucunun erişebildiği başka network kaynaklarına istek göndermesini sağlayan güvenlik açığıdır.

#### Hard-coded credential nedir?

Parola, API key veya token gibi hassas bilgilerin doğrudan kaynak kod içerisinde tutulmasıdır.

#### SAST bütün bu açıkları bulabilir mi?

Bazılarını oldukça başarılı şekilde tespit edebilir. Ancak Business Logic, karmaşık authorization, runtime ve saldırı zinciri problemleri için manuel analiz ve pentest gerekebilir.

#### OWASP Top 10 kontrolü kaynak kod güvenliği için yeterli midir?

Hayır. OWASP Top 10 önemli bir başlangıç noktasıdır ancak profesyonel kod güvenliği değerlendirmelerinde CWE, OWASP ASVS, Secure Coding standartları ve uygulamaya özgü riskler de değerlendirilmelidir.

### Sonuç: Güvenlik Açığının İsmini Değil, Kök Nedenini Anlamak Gerekir

Kaynak kod güvenliğinde gerçek olgunluk yalnızca SQL Injection, XSS veya SSRF gibi güvenlik açıklarını bulmaktan ibaret değildir.

Bir güvenlik açığı görüldüğünde asıl soru şu olmalıdır:

#### Bu açık neden oluştu?

Geliştirici yanlış API mı kullandı?

Secure Coding standardı eksik miydi?

Framework yanlış mı yapılandırıldı?

Authorization mimarisi hatalı mı tasarlandı?

Güvenlik kontrolü CI/CD içerisinde yok muydu?

Geliştiricinin güvenlik konusunda bilgi eksikliği mi vardı?

CWE gibi sınıflandırmalar tam olarak bu noktada değer kazanır.

Çünkü tekil zafiyetlerin arkasındaki tekrar eden zayıflıkları görmemizi sağlar.

OWASP ise saldırgan perspektifinden hangi risk alanlarının özellikle kritik olduğunu anlamamıza yardımcı olur.

Bu iki yaklaşım Secure Coding, SAST ve manuel güvenlik analizi ile birleştiğinde kurum yalnızca açık bulan değil;

**neden açık ürettiğini anlayan**

bir güvenlik yapısına dönüşebilir.

Sonuçta sürdürülebilir yazılım güvenliğinin amacı her release sonrasında daha fazla açık bulmak değildir.

**Her yeni release'te daha az güvenlik açığı üretmektir.**