SQL Injection Nedir ve Nasıl Korunulur? Enjeksiyon Saldırıları Rehberi
Kısa cevap
SQL injection, saldırganın bir form ya da URL üzerinden gönderdiği verinin uygulamanın veritabanı sorgusuna komut olarak karışması sonucu ortaya çıkan bir açıktır. Bu yolla saldırgan veriyi okuyabilir, değiştirebilir ya da silebilir. Korunmanın temeli, kullanıcı verisini sorgu metnine gömmek yerine parametreli sorgu (prepared statement) kullanmaktır; girdi doğrulama, en az yetki ilkesi ve WAF bunu tamamlar.
SQL injection (SQL enjeksiyonu), web uygulamalarını hedef alan en eski ama hâlâ en yaygın ve en yıkıcı açıklardan biridir. Temel fikir basittir: uygulama, kullanıcıdan aldığı veriyi veritabanına gönderdiği komuta doğrudan yapıştırıyorsa, saldırgan o veriye komut karıştırarak veritabanına kendi isteklerini çalıştırabilir. Sonucu; tüm kullanıcı tablosunun çalınmasından, parolaların ifşasına, hatta veritabanının silinmesine kadar uzanabilir.
Bu yazıda SQL enjeksiyonunun ne olduğunu, mekanizmasını zararsız bir örnek üzerinden, türlerini ve en önemlisi nasıl korunulacağını anlatıyoruz. Amaç saldırı yapmayı öğretmek değil; geliştiricinin ve site sahibinin bu açığı nasıl kapatacağını göstermektir.
SQL Injection Nedir?
SQL injection, bir uygulamanın kullanıcıdan aldığı girdiyi güvenli biçimde ayırmadan veritabanı sorgusunun içine yerleştirmesi sonucu, saldırganın bu sorgunun mantığını değiştirebilmesidir. Uygulama, "veri" olarak beklediği bir alana gelen içeriği yanlışlıkla "komut" olarak yorumlar. Sorunun kökeni saldırganın zekiliği değil, uygulamanın veri ile komutu birbirinden ayırmamasıdır.
Bir benzetme yardımcı olur: bir sekretere "şu isimdeki dosyayı getir" dediğinizi düşünün. Sekreter isim olarak duyduğu her şeyi sorgusuz uyguluyorsa, biri "Ahmet'in dosyasını getir, sonra tüm dosyaları çöpe at" derse ve sekreter bunu tek bir talimat gibi işlerse felaket olur. SQL injection tam olarak budur: kullanıcının verdiği "isim", cümlenin geri kalanını değiştiren bir komuta dönüşür.
Nasıl Çalışır? (Zararsız Gösterim)
Enjeksiyon, kullanıcı girdisinin sorgu metnine string birleştirme ile eklendiği yerlerde ortaya çıkar; saldırgan girdiye, sorgunun mantığını kıracak karakterler ekleyerek çalıştırılan komutu değiştirir. Aşağıda, açığa yol açan tipik ve hatalı bir kod deseni var:
// HATALI: kullanıcı girdisi doğrudan sorguya yapıştırılıyor
$kullanici = $_GET['kullanici'];
$sorgu = "SELECT * FROM users WHERE username = '$kullanici'";
Kullanıcı normalde ahmet girdiğinde sorgu şöyle çalışır:
SELECT * FROM users WHERE username = 'ahmet'
Ancak saldırgan kullanici alanına ' OR '1'='1 gibi bir değer girerse, çalışan sorgu şuna dönüşür:
SELECT * FROM users WHERE username = '' OR '1'='1'
Burada '1'='1' her zaman doğru olduğu için sorgu, tek bir kullanıcı yerine tablodaki tüm satırları döndürür. Saldırgan tek bir tırnak işaretiyle sorgunun mantığını değiştirmiştir. Gerçek saldırılarda bu teknik; parola kontrolünü atlamak, başka tablolardan veri çekmek ya da yıkıcı komutlar çalıştırmak için genişletilir. Bu örneği yalnızca mekanizmayı anlamak için veriyoruz; kendi sitenizde bile veriyi bozacak yükler denemeyin.
SQL Injection Türleri
SQL enjeksiyonu, saldırganın sonucu nasıl gördüğüne göre farklı biçimlerde sınıflandırılır; her tür aynı kök soruna dayanır ama farklı tekniklerle sömürülür. Türü bilmek, hem saldırıyı tespit etmeyi hem de savunmayı planlamayı kolaylaştırır.
- Klasik (in-band) enjeksiyon: Saldırgan, sorgunun sonucunu doğrudan sayfada görür. En kolay tespit edilen ve sömürülen türdür. Yukarıdaki örnek bu kategoriye girer.
- Kör (blind) enjeksiyon: Uygulama sorgu sonucunu ya da hata mesajını göstermez, ancak saldırgan sayfanın davranışındaki farklardan (sayfa yükleniyor mu, ne kadar sürede yanıt geliyor) veriyi tahmin eder. Daha yavaştır ama aynı derecede tehlikelidir.
- Hata tabanlı (error-based) enjeksiyon: Uygulama veritabanı hata mesajlarını ekrana dökerse, saldırgan bu hatalardan veritabanı yapısı hakkında bilgi sızdırır. Bu yüzden üretim ortamında ayrıntılı hata mesajları asla gösterilmemelidir.
- Zaman tabanlı (time-based) enjeksiyon: Kör enjeksiyonun bir alt türüdür; saldırgan veritabanına kasıtlı gecikmeler ekleten sorgular gönderip yanıt süresine bakarak "evet/hayır" sorularını yanıtlar.
Ayrıca enjeksiyonun yalnızca form alanlarıyla sınırlı olmadığını vurgulamak isteriz. Kullanıcıdan gelen her veri parçası potansiyel bir giriş noktasıdır: URL parametreleri, çerezler, HTTP başlıkları, hatta bir dosya yüklemesindeki dosya adı bile uygulama tarafından bir sorguya karıştırılıyorsa risk taşır. Bu yüzden savunmayı "formları koruyalım" diye dar düşünmek yerine, veritabanına giden her sorgunun kullanıcı verisini nasıl işlediğine bakmak gerekir.
Türü ne olursa olsun kök neden aynıdır: veri ile komutun ayrılmaması. Dolayısıyla korunma yöntemleri de büyük ölçüde ortaktır.
Nasıl Korunulur?
SQL enjeksiyonundan korunmanın tek ve en etkili yolu, kullanıcı verisini sorgu metnine hiç karıştırmamaktır; bunu parametreli sorgular sağlar ve diğer önlemler bu temeli güçlendiren katmanlardır. Aşağıdaki savunmaları birlikte uygulamak, açığı pratikte ortadan kaldırır.
Parametreli Sorgu (Prepared Statement) Kullanın
En kritik önlem budur. Parametreli sorguda, sorgunun yapısı ile kullanıcı verisi birbirinden ayrı gönderilir; veritabanı, gelen değeri her zaman "veri" olarak işler, asla "komut" olarak yorumlamaz. Aşağıda güvenli hâli görebilirsiniz:
// GÜVENLİ: veri sorgudan ayrı gönderiliyor
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$_GET['kullanici']]);
Burada kullanıcı ' OR '1'='1 girse bile bu değer olduğu gibi bir metin olarak aranır; sorgunun mantığı değişmez. Parametreli sorgular ya da güvenilir bir ORM/sorgu katmanı kullanıldığında enjeksiyonun büyük çoğunluğu kaynağında engellenir. Kullanıcı girdisini string birleştirmeyle sorguya eklemekten kaçının; kural budur.
Bu yaklaşımın gücü, "her girdiyi tek tek temizleme" gibi kırılgan bir yönteme dayanmamasıdır. Girdi temizleme (kaçış karakterleri ekleme) yöntemine güvenen kod, bir noktayı unuttuğunda ya da beklenmedik bir kodlama biçimiyle karşılaştığında delinir. Parametreli sorgu ise sorunu tasarım seviyesinde çözer: veri ve komut baştan ayrı kanallardan gider, dolayısıyla temizlenecek bir şey kalmaz. Modern çerçevelerin ve ORM'lerin çoğu bunu varsayılan davranış hâline getirmiştir; yine de ham SQL yazdığınız her yerde parametreli kullanıp kullanmadığınızı gözden geçirin.
Girdi Doğrulama ve Beyaz Liste Uygulayın
Parametreli sorguları, girdi doğrulamayla destekleyin. Beklenen değerin türünü ve biçimini kontrol edin: sayı bekliyorsanız gelen değerin gerçekten sayı olduğunu doğrulayın, belirli seçeneklerden biri bekliyorsanız (örneğin sıralama yönü) bunu bir beyaz listeyle sınırlayın. Girdi doğrulama tek başına yeterli değildir ama savunmaya değerli bir katman ekler; özellikle tablo/kolon adı gibi parametreleştirilemeyen alanlarda beyaz liste zorunludur.
En Az Yetki İlkesini Uygulayın
Uygulamanın veritabanına bağlandığı hesaba yalnızca ihtiyaç duyduğu yetkileri verin. Bir web uygulaması genellikle veri okuyup yazması yeterken; tablo silme (DROP), kullanıcı oluşturma ya da yönetici yetkilerine ihtiyacı yoktur. Böylece bir enjeksiyon açığı sömürülse bile saldırganın verebileceği zarar, o hesabın yetkileriyle sınırlı kalır. Farklı uygulamalar için farklı ve kısıtlı veritabanı hesapları kullanmak, olası bir ihlalin etkisini ciddi biçimde daraltır.
WAF ile Ek Katman Ekleyin
Bir Web Uygulama Güvenlik Duvarı (WAF), bilinen enjeksiyon desenlerini içeren istekleri uygulamanıza ulaşmadan filtreleyebilir. WAF asla parametreli sorguların yerine geçmez; atlatılabilir ve yalnızca bir katmandır. Ancak henüz yamalanmamış bir açığa karşı zaman kazandırır ve otomatik saldırı botlarının büyük bölümünü daha ilk adımda eler. WAF'ı, kodda alınan önlemlerin üzerine konan tamamlayıcı bir kalkan olarak düşünün. Uygulama katmanının bütününü nasıl sertleştireceğinizi web sitesi güvenliği nasıl sağlanır yazımızda ele alıyoruz.
Hataları Gizleyin ve Logları İzleyin
Son bir katman olarak, üretim ortamında ayrıntılı veritabanı hata mesajlarını asla kullanıcıya göstermeyin. Hata tabanlı enjeksiyon tam da bu mesajlardan beslenir; saldırgan tetiklediği hatalardan tablo adlarını, kolon yapısını ve veritabanı sürümünü öğrenir. Kullanıcıya genel bir hata sayfası dönün, teknik detayı yalnızca sunucu loglarına yazın. Bu logları düzenli izlemek de değerlidir: kısa sürede çok sayıda sözdizimi hatası ya da olağandışı sorgu deseni, birinin sitenizde enjeksiyon denemesi yaptığının erken işaretidir. Bu erken uyarı, açık sömürülmeden önce müdahale etme şansı verir.
Sık Sorulan Sorular
SQL injection hâlâ güncel bir tehdit mi?
Evet, ne yazık ki hâlâ çok yaygındır. Modern çerçeveler parametreli sorguları kolaylaştırsa da, eski kod tabanları, özel yazılmış sorgular ve dikkatsiz geliştirme sonucu bu açık sürekli ortaya çıkmaya devam ediyor. Web uygulamalarındaki en kritik açık kategorilerinden biri olma özelliğini uzun yıllardır koruyor. Sahada denetlediğimiz sitelerde en sık rastladığımız kritik bulgular arasındadır.
Parametreli sorgu kullanırsam tamamen güvende olur muyum?
Parametreli sorgular, klasik SQL enjeksiyonunun neredeyse tamamını engeller ve en önemli önlemdir. Ancak tablo ya da kolon adı gibi parametreleştirilemeyen alanlar, dinamik olarak üretilen sorgular ve saklı yordamların içindeki hatalı birleştirmeler hâlâ risk taşıyabilir. Bu yüzden parametreli sorguyu girdi doğrulama, en az yetki ve WAF ile birlikte katmanlı kullanmak gerekir.
WAF SQL injection'ı tek başına durdurur mu?
Hayır. WAF bilinen saldırı desenlerini filtreler ve otomatik botların çoğunu eler, ancak deneyimli bir saldırgan tarafından atlatılabilir. WAF'ı asıl savunmanın (kodda parametreli sorgu) yerine değil, üzerine konan ek bir katman olarak görün. Güvenliği yalnızca WAF'a dayandıran siteler yanlış bir güven duygusu yaşar.
Sitemde SQL injection açığı olup olmadığını nasıl anlarım?
Bir belirti kontrolü olarak, kendi sitenizde bir URL parametresine tek tırnak eklediğinizde veritabanı hatası dönüyorsa risk var demektir. Ancak bu yüzeysel bir kontroldür; gerçek durumu görmek için kapsamlı bir zafiyet analizi ya da sızma testi gerekir. Web sitesi güvenlik testi nasıl yapılır yazımız kendi yapabileceğiniz temel kontrolleri anlatıyor. Emin olmak için profesyonel bir test en sağlıklı yoldur.
Bir enjeksiyon saldırısına uğradıysam ne yapmalıyım?
Öncelikle açığı kapatın (parametreli sorguya geçin), ardından etkiyi değerlendirin: hangi veriler sızmış olabilir, parolalar ele geçirilmiş mi? Sızmış olabilecek tüm kimlik bilgilerini sıfırlayın ve logları inceleyin. Bir ihlal şüphesi varsa hızlı ve doğru bir müdahale kritik önemdedir; sitemin hacklendiğini nasıl anlarım yazımızdaki belirtiler size yol gösterir. Kapsamlı bir temizlik ve doğrulama için uzman desteği almanızı öneririz.
SQL enjeksiyonu şüphesi taşıyorsanız ya da uygulamanızın bu tür açıklara karşı ne kadar dayanıklı olduğunu bağımsız biçimde ölçmek istiyorsanız yanınızdayız. Sızma testi hizmetimiz ile enjeksiyon dahil tüm kritik açıkları kanıta dayalı ortaya çıkarır, mevcut durumunuzu ücretsiz sunucu güvenlik kontrolü ile hızlıca değerlendiririz. Acil bir durumda 7/24 WhatsApp üzerinden bize ulaşın; ilk teşhis için hemen konuşalım.