Makale Başlıkları
Kısaca
SQL Injection (SQLi), saldırganın form, URL ya da API üzerinden gönderdiği kullanıcı girdisinin veritabanı sorgusunun bir parçası olarak çalıştırılması sonucu ortaya çıkan bir güvenlik açığıdır. Başarılı bir saldırı, tüm veritabanının okunmasından yönetici hesabının ele geçirilmesine kadar giden ağır sonuçlar doğurabilir. Yıllardır bilinen bir açık olmasına rağmen 2026’da hâlâ en sık raporlanan zafiyetlerden biridir.
- Temel çözüm: sorguyu ve veriyi ayıran parametreli sorgular (prepared statement) kullanmak.
- Tek katman yeterli değildir; girdi doğrulama, en az yetki ilkesi ve WAF birlikte çalışmalıdır.
- ORM kullanmak da otomatik koruma değildir; ham (raw) sorgular ve yanlış birleştirme aynı riski taşır.
Bir web uygulaması geliştirdiğinizde, kullanıcıdan aldığınız her veri potansiyel bir saldırı vektörüdür. Arama kutusuna yazılan bir kelime, giriş formuna girilen bir e-posta ya da URL’nin sonundaki bir kimlik numarası… Bunların hepsi, dikkatsizce yazılmış bir kod satırında veritabanına doğrudan geçtiğinde SQL Injection için kapıyı aralar. Bu yazıda SQLi’nin tam olarak nasıl çalıştığını, hangi türlerinin bulunduğunu ve 2026’da hâlâ geçerli olan somut korunma yöntemlerini örneklerle ele alacağız.
SQL Injection Nedir?
SQL Injection, kısaca SQLi, bir uygulamanın kullanıcı girdisini veritabanı sorgusuna güvenli olmayan bir şekilde eklemesi sonucu oluşan bir enjeksiyon zafiyetidir. Saldırgan, beklenen veri yerine SQL komutu parçaları göndererek sorgunun mantığını değiştirir. Sonuçta veritabanı, geliştiricinin yazdığı sorguyu değil, saldırganın kurguladığı sorguyu çalıştırır.
Bu açık neden bu kadar tehlikelidir? Çünkü veritabanı çoğu uygulamanın kalbidir. Kullanıcı adları, parola özetleri, sipariş kayıtları, ödeme bilgileri, kişisel veriler; hepsi orada durur. SQLi ile bir saldırgan bu verileri okuyabilir, değiştirebilir, silebilir ve bazı durumlarda veritabanı sunucusu üzerinden işletim sistemine kadar erişim sağlayabilir.
OWASP, 2025 Top 10 listesinde “Injection” kategorisini bir miktar aşağı çekmiş olsa da SQL Injection her yıl binlerce yeni CVE kaydında karşımıza çıkmaya devam ediyor. Yani “artık eski bir sorun” demek büyük bir yanılgı olur; sadece görünürlüğü azaldı, tehlikesi değil.
Basit Bir Örnekle Nasıl Çalışır?
Diyelim ki bir giriş formunuz var ve arka planda şöyle bir sorgu kuruyorsunuz (kötü örnek):
SELECT * FROM users WHERE username = ‘$kullanici’ AND password = ‘$parola’
Kullanıcı, kullanıcı adı alanına normal bir isim yerine ‘ OR ‘1’=’1 yazarsa sorgu şuna dönüşür:
SELECT * FROM users WHERE username = ” OR ‘1’=’1′ AND password = ”
Artık koşul her zaman doğru döner ve saldırgan parola bilmeden oturum açabilir. İşin özü budur: kullanıcının verisi, sorgunun komut kısmına karışmıştır. Doğru mimaride veri ile komut asla birbirine karışmaz.
SQL Injection Türleri
SQLi tek bir teknik değildir; saldırganın veriye nasıl ulaştığına göre farklı sınıflara ayrılır. Aşağıdaki tablo en yaygın türleri özetliyor.
| Tür | Nasıl Çalışır? | Tipik Belirti |
|---|---|---|
| Error-Based (Hata Tabanlı) | Veritabanı hata mesajlarını zorlayarak yapı ve içerik sızdırır. | Sayfada görünen SQL hata metinleri |
| Union-Based (Birleşim Tabanlı) | UNION operatörüyle başka tablolardan veri çekip yanıta ekler. | Beklenmedik satırların ekranda görünmesi |
| Blind Boolean (Kör Mantıksal) | Doğru/yanlış koşullara göre sayfa davranışındaki farkı okur. | Aynı sayfanın farklı içerikler döndürmesi |
| Blind Time-Based (Zaman Tabanlı) | SLEEP gibi gecikme komutlarıyla yanıt süresinden sonuç çıkarır. | Belirli isteklerde uzayan yanıt süresi |
| Out-of-Band | Veriyi DNS/HTTP gibi farklı bir kanaldan dışarı taşır. | Beklenmedik dış ağ istekleri |
Error-Based ve Union-Based
Bu ikisi “in-band” yani aynı kanal üzerinden çalışan tekniklerdir; saldırgan sonucu doğrudan yanıt sayfasında görür. Error-based saldırıda amaç, veritabanını bir hata üretmeye zorlamaktır; çünkü ayrıntılı hata mesajları çoğu zaman tablo adlarını, sütun tiplerini, hatta sürüm bilgisini ele verir. Union-based saldırıda ise saldırgan, mevcut SELECT sorgusuna kendi SELECT ifadesini ekleyerek başka tablolardaki verileri normal çıktının içine sızdırır.
Blind (Kör) SQL Injection
Uygulama hata mesajı ya da veri döndürmüyorsa saldırgan pes etmez; dolaylı ipuçlarına yönelir. Boolean tabanlı kör saldırıda, gönderilen koşul doğruysa sayfa bir türlü, yanlışsa başka türlü davranır ve saldırgan bu farkı karakter karakter okuyarak veriyi tahmin eder. Zaman tabanlı kör saldırıda ise sayfa hiç değişmese bile, saldırgan sorguya bir gecikme komutu ekler: yanıt geç geliyorsa koşul doğrudur. Bu yöntemler yavaştır ama otomatik araçlarla bütün bir veritabanı bu şekilde çıkarılabilir.
Nasıl Korunulur?
İyi haber şu: SQL Injection, doğru pratiklerle neredeyse tamamen önlenebilen bir açıktır. Kötü haber şu: tek bir sihirli ayar yoktur, katmanlı savunma gerekir. Aşağıda öncelik sırasına göre en etkili yöntemleri sıraladık.
1. Parametreli Sorgular (Prepared Statements) Kullanın
Bu, birincil ve en etkili savunmadır. Parametreli sorguda önce SQL komutunun iskeleti tanımlanır, kullanıcı verisi ise ayrı bir parametre olarak sonradan gönderilir. Böylece veritabanı, gelen veriyi ne olursa olsun veri olarak işler, asla komut olarak yorumlamaz. Yukarıdaki ‘ OR ‘1’=’1 saldırısı, parametreli sorguda basitçe geçersiz bir kullanıcı adı olarak değerlendirilir ve hiçbir işe yaramaz.
PHP tarafında PDO veya MySQLi’nin hazırlıklı ifadeleri, Java’da PreparedStatement, .NET’te SqlParameter, Python’da ise sürücünün parametre bağlama (binding) yöntemi bunun karşılığıdır. Kural nettir: kullanıcı girdisini asla sorgu metnine string olarak birleştirmeyin.
2. ORM’e Kör Güvenmeyin
Laravel Eloquent, Doctrine, Hibernate ya da Django ORM gibi katmanlar sorgularınızı çoğunlukla otomatik parametreleştirir. Ancak “raw query”, “whereRaw” ya da ham SQL ile string birleştirdiğiniz her nokta, ORM’in korumasını devre dışı bırakır. ORM kullanmak koruma garantisi değil, sadece varsayılan olarak güvenli bir başlangıçtır.
3. Girdi Doğrulama (Input Validation)
Beklenen veri tipini ve biçimini katı şekilde doğrulayın. Bir sayı bekliyorsanız gerçekten sayı olduğundan emin olun; bir e-posta bekliyorsanız biçimini kontrol edin. Özellikle sıralama alanı (ORDER BY) ya da tablo/sütun adı gibi parametreleştirilemeyen kısımlarda, kullanıcı girdisini yalnızca önceden tanımlı bir “izin listesi” (allow-list) ile eşleştirin.
4. En Az Yetki İlkesi
Uygulamanızın kullandığı veritabanı hesabı, işini yapmak için gereken minimum yetkiye sahip olmalıdır. Bir okuma uygulaması DROP TABLE ya da GRANT yetkisi taşımamalıdır. Böylece bir açık istismar edilse bile hasar sınırlı kalır.
5. Web Application Firewall (WAF)
WAF, bilinen SQLi kalıplarını istek katmanında yakalayarak ek bir savunma hattı sunar. WAF tek başına yeterli bir çözüm değildir; asıl işi zaman kazandırmak ve otomatik saldırıları filtrelemektir. Alastyr sunucularında Imunify360 tabanlı çift katmanlı WAF, CageFS izolasyonu ve honeypot/tehdit istihbaratı ile birlikte çalışır; şüpheli enjeksiyon denemeleri daha uygulamaya ulaşmadan filtrelenebilir. Bunun üstüne, ağ katmanında Voxility tabanlı 1 Tbps üzeri L3-L4 anti-DDoS koruması da uygulamanızı hacimsel saldırılara karşı ayakta tutar.
6. Hata Mesajlarını Gizleyin ve Güncel Kalın
Üretim ortamında ayrıntılı veritabanı hata mesajlarını asla kullanıcıya göstermeyin; bunlar error-based saldırıların yakıtıdır. Ayrıca veritabanı motoru, PHP sürümü ve kütüphaneleri güncel tutun. Alastyr’ın PHP sürüm seçici özelliği, uygulamanızı güvenli ve desteklenen bir sürümde çalıştırmayı kolaylaştırır.
Korunma Yöntemlerinin Karşılaştırması
| Yöntem | Etki Düzeyi | Not |
|---|---|---|
| Parametreli sorgular | Çok yüksek | Birincil savunma, mutlaka uygulanmalı |
| Girdi doğrulama (allow-list) | Yüksek | Parametreleştirilemeyen alanlar için kritik |
| En az yetki ilkesi | Orta-Yüksek | Hasarı sınırlar, açığı kapatmaz |
| WAF | Orta | Ek katman, tek başına yetmez |
| Hata mesajı gizleme | Orta | Bilgi sızıntısını azaltır |
Doğru Barındırma Altyapısı Neden Önemli?
SQL Injection’a karşı asıl sorumluluk uygulama kodundadır; hiçbir sunucu, güvensiz yazılmış bir sorguyu tümüyle telafi edemez. Ancak sağlam bir barındırma altyapısı, saldırganın işini ciddi biçimde zorlaştıran katmanları hazır sunar. İzole edilmiş hesaplar, güncel PHP sürümleri, uygulama seviyesinde WAF ve düzenli yedekleme; bir açık istismar edilse bile toparlanmanızı kolaylaştırır.
Alastyr, 2002’den beri %100 Türk sermayesiyle, İzmir’deki kendine ait N+1 yedekli veri merkezinde hizmet veriyor. CloudLinux + CageFS izolasyonu her hesabı diğerlerinden ayırır; günlük yedekleme ve %99,9 çalışma süresi ise olası bir olayda kayıpsız geri dönmenizi sağlar. Uygulamanızı güvenli bir zeminde çalıştırmak için web hosting paketlerimizi, izole ve tam kontrol isteyen projeler için VPS sunucu ve bulut sunucu çözümlerimizi inceleyebilirsiniz. WordPress projeleriniz için özel olarak yapılandırılmış WordPress hosting da güçlü bir başlangıç noktasıdır.
Uygulamanızı Güvenli Bir Altyapıda Barındırın
Imunify360 tabanlı çift WAF, CageFS izolasyonu, günlük yedekleme ve %99,9 çalışma süresi ile Alastyr’da güvenli hosting sizi bekliyor.
Sıkça Sorulan Sorular
SQL Injection nedir kısaca?
SQL Injection, kullanıcıdan alınan girdinin veritabanı sorgusuna güvensiz şekilde eklenmesiyle, saldırganın sorgunun mantığını değiştirebildiği bir güvenlik açığıdır. Saldırgan bu yolla veri okuyabilir, değiştirebilir veya silebilir.
SQL Injection’a karşı en etkili korunma yöntemi nedir?
En etkili yöntem parametreli sorgular yani prepared statement kullanmaktır. Bu yöntem, SQL komutunu ve kullanıcı verisini birbirinden ayırarak girdinin asla komut olarak çalıştırılmamasını sağlar.
ORM kullanmak SQL Injection’ı tamamen önler mi?
Hayır. ORM’ler sorguları çoğunlukla otomatik parametreleştirir, ancak ham (raw) sorgular ya da string birleştirmeyle yazılan ifadeler bu korumayı devre dışı bırakır. ORM güvenli bir başlangıçtır, garanti değildir.
Blind SQL Injection nasıl anlaşılır?
Blind SQLi, uygulama hata veya veri döndürmediğinde sayfanın davranış farkından ya da yanıt süresindeki gecikmeden anlaşılır. Boolean tabanlı türde sayfa farklı içerik döndürür, zaman tabanlı türde ise yanıt belirgin şekilde gecikir.
WAF tek başına SQL Injection’ı durdurur mu?
Hayır. WAF bilinen saldırı kalıplarını filtreleyerek önemli bir ek katman sağlar, fakat tek başına yeterli değildir. Asıl çözüm koddaki parametreli sorgular ve girdi doğrulamasıdır; WAF bunları tamamlar.
Hata mesajlarını gizlemek neden önemli?
Ayrıntılı veritabanı hata mesajları; tablo adları, sütun tipleri ve sürüm bilgisi gibi ipuçlarını ele verir. Error-based saldırılar tam olarak bu bilgiyi kullanır. Üretim ortamında hata mesajları kullanıcıya gösterilmemelidir.
En az yetki ilkesi SQL Injection’da ne işe yarar?
Uygulamanın veritabanı hesabına yalnızca gerekli yetkileri vermek, bir açık istismar edilse bile verilebilecek zararı sınırlar. Örneğin salt okuma yapan bir hesabın tablo silme yetkisi olmaması hasarı ciddi biçimde azaltır.
SQL Injection 2026’da hâlâ tehlikeli mi?
Evet. OWASP listesinde sıralaması değişmiş olsa da SQL Injection her yıl binlerce yeni CVE kaydında görülmeye ve büyük veri ihlallerinde rol oynamaya devam ediyor. Görünürlüğü azaldı, tehlikesi değil.
