1. GİRİŞ

SQL Injection (SQLi), uygulama katmanındaki girdilerin yeterince doğrulanmaması veya güvenli şekilde ele alınmaması nedeniyle saldırganların SQL sorgularını manipüle ederek veri tabanına yetkisiz erişim sağlaması tekniğidir. Yirmi yılı aşkın süredir internetin en yaygın ve etkili saldırı türlerinden biri olmaya devam etmektedir. Günümüzün bulut‑native, mikroservis ve API‑odaklı mimarilerinde bile SQLi, doğru korunmadığında ciddi veri ihlallerine, iş sürekliliği sorunlarına ve regülasyon ihlallerine yol açar.

Bu konu neden bugün önemli?

• Veri merkezli uygulamalar artıyor; hassas veriye erişim sağlayan herhangi bir zafiyet kabul edilemez sonuçlar doğurur.
• Complex stack'lerde (ORM, mikroservisler, serverless) yanlış konfigurasyon ve developer hataları SQLi riskini yeniden gündeme getiriyor.
• Regülasyon baskısı (GDPR, KVKK, PCI) veri sızıntılarının ceza ve uyum maliyetlerini yükseltiyor.

Kimler için önemli?

• Backend geliştiricileri ve full‑stack mühendisleri — güvenli veri erişimi kodlama sorumluluğu.
• Veri mühendisleri ve DBA'lar — veri tabanı güvenliği ve konfigürasyon.
• DevOps / SRE/Platform ekipleri — erişim, network segmentation ve runtime kontrollerinin sağlanması.
• Güvenlik mühendisleri — tespit, response ve risk değerlendirmesi.

Hangi problemleri çözüyor?

• Yetkisiz veri okuma / değiştirme / silme riskini azaltmak.
• Uygulama katmanında injection'a karşı koruma sağlayıp veri bütünlüğünü teminat altına almak.
• Uyumluluk gereksinimlerini karşılayarak denetim kanıtı sunmak.

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

• SQL Injection (SQLi): Veri tabanı sorgularına dış girdilerin doğrudan eklenmesiyle uygulama mantığının bozulması veya query davranışının değiştirilmesi saldırısı.
• Parameterized Query / Prepared Statement: Girdi ve sorgu planının ayrıştırıldığı, injection riskini azaltan sorgu yaklaşımı.
• ORM (Object‑Relational Mapping): Veri tabanına erişim soyutlayan kütüphaneler; doğru kullanılmadığında yanlış güvenlik hissi oluşturabilir.
• Blind SQLi: Veri tabanı yanıtı doğrudan gösterilmeyen ortamlarda bile sorgularla veri çıkarmaya izin veren teknikler.

2.2 Türler ve sınıflandırma

• In‑band SQLi: Saldırganın aynı kanaldan, uygulama yanıtı üzerinden veri eksfiltre ettiği tür (ör. error‑based, union‑based).
• Inferential / Blind SQLi: Doğrudan yanıt alınamıyorsa zaman veya boolean bazlı tekniklerle veri çıkarılır.
• Out‑of‑band SQLi: Veri tabanı doğrudan saldırgan kontrollü kanala veri gönderdiğinde (DNS exfiltration, HTTP callback) gerçekleşir; genellikle DNS/HTTP tabanlı exfiltration ile olur.
• Stored vs Reflected: Stored (persistent) injection, zararlı yükün veri tabanında depolanıp daha sonra kullanıcılara serv edildiği örnekleri içerir; reflected ise anlık istekte gerçekleşir.

3. NASIL ÇALIŞIR? — TEKNİK MEKANİK VE VERİ AKIŞI

3.1 Temel mekanik

SQL injection bir uygulamanın veri tabanına gönderdiği sorgunun bir parçasını dış girdinin değiştirmesiyle meydana gelir. Örnek olarak basit bir kimlik doğrulama sorgusunu düşünün: SELECT * FROM users WHERE username = '" + input + "' AND password = '" + input2 + "'. Eğer input değerleri temizlenmezse saldırgan "' OR '1'='1" gibi bir payload ile sorguyu manipüle edip koşulu her zaman true yapabilir.

3.2 Veri akışı ve zayıf noktalar

Gelen istek (HTTP) → Web uygulaması katmanı (input handling) → Query builder/ORM → Veri tabanı katmanı. Zayıflık noktaları şunlardır:

• İstemci tarafı doğrulamasıyla yetinmek (server tarafında doğrulama yok)
• String‐concatenation ile query oluşturmak
• Yanlış kullanılan ORM raw query fonksiyonları
• Hata mesajlarının ve stack trace'lerin doğrudan kullanıcıya gösterilmesi (error‑based SQLi için veri sağlar)

3.3 Örnek senaryolar

• Login bypass: "' OR '1'='1" payload'ı ile kimlik doğrulama atlanır — bu in‑band attack örneğidir.
• Data exfiltration: Sorgu sonucu hassas veri (örn. PII) döndürülür veya zaman bazlı blind tekniklerle karakter karakter çıkarılır.
• Privilege escalation: Veri tabanına zarar verici SQL komutları (ör. DROP, UPDATE) gönderilerek yetki artırımı ve veri tahribatı yapılabilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Tarihsel ve bilinen vakalar

SQL injection yüzünden gerçekleşen veri ihlalleri sektör tarafından iyi bilinir: büyük perakendeciler, sağlık sağlayıcıları ve kamu kurumları geçmişte bu zafiyetleri nedeniyle zarar görmüştür. SQLi genellikle third‑party uygulamalar veya yanlış yapılandırılmış admin paneli gibi beklenmedik noktalardan ortaya çıkar.

4.2 Sektörlere göre örnek uygulama etkileri

• E‑ticaret: Müşteri verisi, ödeme bilgisi veya sipariş geçmişi ele geçirilebilir; reputasyon ve finansal kayıp söz konusu olur.
• Finans: Transaction manipülasyonu, balance alteration, reconciliation bozuklukları gibi kritik etkiler olabilir.
• Sağlık: PHI sızıntısı, regülasyon cezaları ve hasta güvenliği riski doğar.
• Kamu: Vatandaş verisi ve kritik sistemlerde işler durabilir; ulusal güvenlik riskleri bile ortaya çıkabilir.

5. AVANTAJLAR VE SINIRLAMALAR (COROLLARY: NEDEN ÖNLEMEYE ODAKLANMALI?)

Avantajlar (önleme odaklı bakış)

• Doğru koruma uygulandığında veri güvenliği ve uygulama sağlamlığı artar.
• Parametrelenmiş sorgular, ORM güvenlik katmanları ve WAF kombinasyonu yüksek güvenlik sağlar ve sürdürülebilir yönetim sunar.

Sınırlamalar

• Bazı legacy uygulamaların refactor edilmesi pahalıdır; migration maliyetleri yüksek olabilir.
• Automated scanner'lar false positive/negative üretebilir; manuel analiz ve threat modeling gereklidir.
• Blind SQLi ve out‑of‑band teknikler tespit ve tetkik açısından zorluk çıkarır.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

SQLi'ye karşı çeşitli yaklaşımlar vardır; aşağıdaki tablo yaygın stratejileri karşılaştırır.

7. EN İYİ PRATİKLER

Production kullanımı — kritik önlemler

• Parametrelenmiş sorgular (prepared statements) veya ORM parametre binding kullanın; sorgu ile veri ayrımını kesinlikle sağlayın.
• Input validation ve output encoding'ı context‑aware uygulayın; SQL bağlamında farklı, HTML bağlamında farklı encoding gerekir.
• Least privilege: veri tabanı kullanıcıları only necessary permissions ile oluşturulmalı (örn. uygulama hesabı SELECT/INSERT/UPDATE gerekli tablolarla sınırlı olmalı).
• Hata mesajlarını sanitize edin; stack trace veya SQL hata ayıracı üretmeyin (error‑based SQLi riskini azaltır).
• Prepared statement'ları loglarken query plan ve parameter ayrımına dikkat edin; hassas parametreleri mask'leyin.

Performans ve operasyon

• SAST/DAST araçlarını CI pipeline'ına ekleyin; PR seviyesinde otomatik taramalar çalıştırın.
• Dependency scanning ve DB driver güncellemelerini düzenli yapın; DB client ve connector'ların güvenlik güncellemeleri takip edilmeli.
• WAF ve runtime filters ile bilinen pattern'leri engelleyin ancak bu araçlara aşırı güvenmeyin.

Güvenlik

• Database activity monitoring (DAM) ve anomaly detection ile anormal sorgu desenlerini tespit edin.
• Audit logging: kritik veri erişimlerini, admin query'lerini ve schema değişikliklerini immutable şekilde kaydedin.
• Red team ve pentest ile injection vektörlerini düzenli olarak test edin; özellikle blind ve out‑of‑band senaryoları değerlendirin.

8. SIK YAPILAN HATALAR

• Client‑side validation'a güvenip server‑side doğrulamayı atlamak.
• ORM'ın "bana güven" hissine kapılıp raw query kullanımını kontrolsüz bırakmak.
• Hata mesajlarını ayrıntılı bırakmak — SQL hata mesajları saldırgana bilgi verir.
• Least privilege ilkesini uygulamamak — uygulama için geniş yetkiler veren DB kullanıcıları.
• CI/CD'de SAST/DAST'i ihmal etmek veya sadece uyarı düzeyinde bırakmak; remediation süreçlerini kurmamak.

9. GELECEK TRENDLER

AI destekli tespit ve önceliklendirme

AI ve ML, telemetri, sorgu pattern'leri ve geçmiş incident verilerini kullanarak injection risklerini önceden tahmin edebilecek. Özellikle runtime anomaly detection sistemleri, blind logical exfiltration'ı erken tespit edebilir ve otomatik koruma tetikleyebilir.

Runtime query policy enforcement

Veri tabanı proxy'leri (query broker) veya RASP katmanları, outgoing query'leri analiz ederek anormal veya tehlikeli pattern'leri bloklayabilir. Policy‑as‑code ile belirlenen kurallar, runtime'da uygulanabilir.

Better developer ergonomics ve secure defaults

Frameworkler ve ORMs'lar secure‑by‑default yaklaşımlarını güçlendiriyor; built‑in parameter binding, safer raw query APIs ve otomatik escaping daha yaygın olacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. SQL Injection'ı tamamen ortadan kaldırmak mümkün mü?

   Teorik olarak doğru süreçler, parameterization ve en az ayrıcalıkla risk büyük ölçüde minimize edilebilir; fakat legacy sistemler, insan hatası ve supply chain riskleri nedeniyle "sıfır risk" pratikte ulaşılamaz. Ama hedef kabul edilebilir risk seviyesine düşürmektir.

2. 2. ORM kullanmak SQLi riskinden korur mu?

   ORM'lar doğru kullanıldığında önemli ölçüde koruma sağlar. Ancak raw query veya string interpolation kullanımıyla ORM'ların sağladığı güvenlik atlanabilir. ORM'ın güvenli kullanım kılavuzlarına uyulmalıdır.

3. 3. Blind SQLi nasıl tespit edilir?

   Time‑based veya boolean‑based testlerle; ayrıca anomaly detection sistemleri ile anormal sorgu yanıt süreleri veya trafiği izlenerek tespit edilebilir.

4. 4. WAF SQLi'yi tamamen engeller mi?

   WAFlar birçok bilinen pattern'i engeller fakat sophisticated payload'lar, encoded/obfuscated veriler veya yeni varyantlar tarafından bypass edilebilir. WAF bir katman olarak faydalıdır fakat tek başına yeterli değildir.

5. 5. SQLi testi için hangi araçlar kullanılmalı?

   SQLMap, Burp Suite (intruder), OWASP ZAP ve özel DAST araçları yaygın olarak kullanılır. CI entegrasyonu için SCA, SAST ve DAST kombinasyonu tercih edilir.

6. 6. Database kullanıcı izinleri nasıl sınırlandırılmalı?

   Her uygulama için ayrı DB hesabı, sadece gerekli tablolar/işlemler için izin, prosedür kullanımı yerine column/table bazlı izinler uygulama önerilir.

7. 7. SQLi için RBAC yerine ABAC kullanılmalı mı?

   ABAC (attribute‑based) daha granular ve dinamik politikalar sağlar; karmaşık senaryolarda ABAC daha uygun olabilir. Ancak temel olarak RBAC ile başlayıp ihtiyaç oldukça ABAC'e geçiş mantıklıdır.

8. 8. SQLi bulgularını nasıl önceliklendirmeliyim?

   Risk scoring: likelihood × impact. Hassas veri içeren tablolar, üretim ortamı ve privilege escalation potansiyeli yüksek bulgulara öncelik verin.

Anahtar Kavramlar

• Parameterized Query: Girdi ve sorgunun ayrı tutulduğu, injection riskini azaltan yöntem.
• Blind SQLi: Yanıtın doğrudan görünmediği ortamlarda kullanılan exfiltration teknikleri.
• Out‑of‑band: Verinin uygulama kanalı dışında (DNS/HTTP callback) gönderildiği saldırılar.
• WAF: Web Application Firewall — application layer'da filter ve kurallar sağlar.
• DB Activity Monitoring: Veri tabanı üzerindeki anormal aktiviteleri izleyen sistemler.

Öğrenme Yol Haritası

1. 0–1 ay: SQL temel kavramları, parametrik sorgular, temel injection örnekleri (öğretici sandbox'larda) öğrenin.
2. 1–3 ay: OWASP Top 10 içindeki injection maddesini çalışın, SQLMap ve DAST araçları ile testler yapın; küçük uygulamalarda pentest pratiği kazanın.
3. 3–6 ay: CI/CD entegrasyonları, SAST/DAST ve otomatik remediation süreçleri kurun; DB hardening ve least privilege uygulamaları üzerinde çalışın.
4. 6–12 ay: Advanced exploitation (blind/out‑of‑band), DB activity monitoring, red team tatbikatları ve runtime query policy uygulamaları ile uzmanlaşın.