SQL Injection 2026: Modern Saldırı Teknikleri ve Savunma

Pentest yaptığımız her 10 uygulamadan 3'ünde en az bir klasik SQLi buluyoruz. Özellikle PHP'de yazılmış legacy uygulamalar, arama formları, admin panelleri ve raporlama ekranları. 'SELECT * FROM users WHERE id=' . $_GET['id'] — 2026'da hâlâ yaşayan pattern.

Çoğu modern framework (Laravel, Django, Rails) ORM kullanır ve SQLi'den büyük ölçüde korur. Ama raw query yazan, string concatenation ile sorgu kuran, veya dinamik tablo adı kullanan kod parçaları istisna. SAST araçları (SonarQube, Semgrep) bu pattern'leri yakalar.

Modern uygulamalarda hata mesajı göstermeyen endpoint'ler var. Response'da SQL hatası görünmüyor ama DB sorgusu payload tetikliyor. Time-based blind yaklaşım: payload'a SLEEP(5) ekliyorsunuz, sunucu 5 saniye geç yanıt verirse SQLi confirmed.

Payload örneği: `' OR IF(1=1, SLEEP(5), 0)--`. Sqlmap'in `--technique=T` opsiyonu bu saldırı tipini otomatikleştirir. Savunma: parametrized query + prepared statement yeterli. Time-based exploitation yavaş ama durdurulamaz; prepared statement olmadan zafiyet kaçınılmaz.

Saldırgan payload'ı bir yerde (örn: profile update) enjekte eder, sistem bunu sanitize etmeden veritabanına kaydeder. Daha sonra başka bir endpoint (örn: admin panel user list) veritabanından bu veriyi alıp başka bir sorguda kullanır → o sorgu SQLi tetikler.

Savunma: her DB yazma ve okuma operasyonunda bağımsız escape/prepared statement. Sadece input'ta değil, kullanım noktasında da savunma. ORM'ler genelde bu konuda güvenli ama raw query karışmışsa kontrol edin.

NoSQL DB'ler SQL injection'a karşı bağışık değil. MongoDB'de `{$ne: null}` payload'ı ile kimlik doğrulama bypass mümkün: `db.users.find({username: req.body.username, password: req.body.password})` — body'de password olarak `{$ne: null}` gönderirseniz tüm user'lar eşleşir.

Savunma: body parser'ı string'e zorlayın (express-mongo-sanitize middleware), input type validation. Redis komutlarında user input'u asla doğrudan kullanmayın. Cassandra'da prepared statement şart.

ORM koruması mutlak değil. Laravel'da `DB::raw()`, Prisma'da `$queryRaw`, Django'da `extra()` veya `RawSQL()` — bunlar güvenli kullanılmazsa SQLi açar. Geliştiriciler ORM kullanıyoruz zannettikleri için guard'ı düşürür.

Kod inceleme pratiği: her raw query çağrısını audit edin. Input parametre olarak geçiyor mu, yoksa string concatenation mı? Staticly veya dynamically mi oluşturuluyor? Şüphe varsa parametrized versiyonuna çevirin.

1. Kod seviyesi: prepared statement + ORM + input validation. 2. ORM/Query builder: parametrized query zorunlu, raw query istisna. 3. WAF seviyesi: Cloudflare WAF, AWS WAF, ModSecurity — SQLi pattern'lerini durdurur (100% değil ama bariyerde kalır). 4. DB seviyesi: least privilege kullanıcı, read/write ayrımı, audit log.

5. Monitoring: failed query pattern'leri alarm versin, olağandışı sayıda SQL hatası incident tetiklesin. Defense in depth yaklaşımı — tek katman değil, çok katman ile tam savunma.