SQL Injection Nedir ve Nasıl Önlenir?
Nisan 16, 2026
Ağ Güvenliği,OWASP,Siber Güvenlik,Siber Savunma
SQL Injection, saldırganın web uygulamasının girdi alanlarına (formlar, URL parametreleri, HTTP başlıkları) kötü niyetli SQL kodu enjekte ederek, arka plandaki veritabanını manipüle etme veya yetkisiz veri erişimi sağlama saldırısıdır. Bu zafiyet, uygulamanın kullanıcı girdisini “güvenilir veri” olarak kabul edip, doğrudan SQL sorgusuna eklemesi sonucu oluşur. Normalde uygulama, veritabanından sadece belirli kayıtları çekerken; enjekte edilen kod sayesinde saldırgan `WHERE` koşulunu bypass edebilir, tüm tabloyu listeleyebilir (`UNION SELECT`), veritabanı şemasını öğrenebilir veya hatta sunucu üzerinde komut çalıştırabilir. SQLi, OWASP Top 10 listesinde yıllardır yer alan ve “Injection” kategorisinin en klasik örneği olan kritik bir zafiyettir; çünkü veritabanı genellikle uygulamanın en hassas varlığıdır (müşteri bilgileri, finansal veriler, kimlik doğrulama bilgileri).
Classic, Blind ve Out-of-Band SQL Injection türleri arasındaki teknik farklar nelerdir?
Classic (In-band) SQLi: Saldırgan, enjekte ettiği sorgunun sonucunu doğrudan web sayfasında görür. Örneğin, hata mesajları veritabanı yapısını ele verir veya `UNION` operatörü ile başka tablolardan veri çekilip ekrana basılır. Bu tür, tespit edilmesi ve istismarı en kolay olandır.
Blind SQLi: Uygulama hata mesajlarını göstermez veya sonuçları ekrana basmaz; ancak saldırgan, uygulamanın verdiği tepkilere (True/False) veya yanıt süresine dayanarak veri çıkarımı yapar. Boolean-based blind’de, “Eğer admin kullanıcısının şifresinin ilk harfi ‘A’ ise sayfayı normal yükle, değilse boş dön” mantığıyla karakter karakter veri tahmin edilir. Time-based blind’da ise `SLEEP()` veya `WAITFOR DELAY` fonksiyonları kullanılarak, sorgunun ne kadar sürede döndüğüne bakılarak veri sızdırılır.
Out-of-Band (OOB) SQLi: Uygulama ile saldırgan arasında doğrudan iletişim kanalı yoksa veya diğer yöntemler başarısız olursa kullanılır. Saldırgan, veritabanının dış kaynaklara (DNS sunucusu, HTTP isteği) bağlantı kurmasını sağlayarak veriyi bu kanallar üzerinden sızdırır. Bu yöntem, genellikle gelişmiş güvenlik kontrollerini aşmak için kullanılan sofistike bir tekniktir.
Tespit Yöntemleri, Statik/Dinamik Analiz ve Güvenlik Testleri
SAST araçları (SonarQube, Checkmarx, Fortify, Semgrep), kaynak kodu derlemeden önce analiz ederek tehlikeli pattern’leri arar. Temel tespit mekanizması, “kaynak-havuz” (taint analysis) akış izlemesidir: Araç, kullanıcı girdisinin geldiği noktayı (source: `request.getParameter()`, `$_GET[]`) ve bu verinin SQL sorgusuna ulaştığı noktayı (sink: `executeQuery()`, `cursor.execute()`) takip eder. Aradaki akışta veri sanitizasyonu veya parametreleştirme yoksa, araç bunu zafiyet olarak flag’ler. SAST ayrıca, tehlikeli fonksiyon çağrılarını (örn. Java’da `Statement.executeQuery(String sql)` yerine `PreparedStatement` kullanılmaması) ve string birleştirme operatörlerinin (`+`, `.`) SQL bağlamında kullanımını da kural tabanlı olarak tarar. SAST’in avantajı, erken aşamada (shift-left) bulgu sağlamasıdır; ancak false positive oranı yüksektir ve bağlamsal analizi sınırlıdır.
DAST araçları (OWASP ZAP, Burp Suite Enterprise, Acunetix) çalışan uygulamaya dışarıdan saldırı simülasyonu yaparak SQLi tespit eder. Araç, form alanlarına ve URL parametrelerine özel payload’lar enjekte eder: `’ OR ‘1’=’1`, `’ AND SLEEP(5)–`, `’ UNION SELECT NULL–` gibi. Uygulamanın yanıtını analiz eder: HTTP 500 hatası, veritabanı hata mesajı içeren içerik, yanıt süresindeki ani artış (time-based) veya sayfada beklenmedik veri değişimi. DAST, kod erişimi gerektirmediğinden black-box testlerde etkilidir ve gerçek çalışma ortamındaki davranışı ölçer. Ancak, DAST tüm kod yollarını gezemez (özellikle JavaScript ile dinamik yüklenen kısımlar) ve üretim ortamında veri bozulmasına neden olabilir; bu nedenle test ortamlarında veya dikkatli kurgulanmış production testlerinde kullanılmalıdır. Manuel penetrasyon testleri ise, otomatik araçların kaçırdığı logic-based SQLi veya WAF bypass senaryolarını insan zekası ile keşfederek tespiti derinleştirir.
Kod Seviyesinde Önleme Teknikleri ve En İyi Uygulamalar
Parametreli sorgular SQLi’yi engellerken, giriş doğrulama “garbage in, garbage out” sorununu çözer ve uygulamanın bütünlüğünü korur. Whitelisting (beyaz liste), yalnızca beklenen formatdaki veriyi kabul eder; her şeyi reddeder. Örneğin, yaş alanı için sadece rakamlara (`^[0-9]+$`), ülke kodu için ISO standartlarına, tarih için YYYY-MM-DD formatına izin verilir. Blacklisting (kara liste – yasaklı karakterleri engelleme) ise asla güvenilir değildir; saldırganlar encoding teknikleriyle bu filtreleri aşabilir. Validasyon hem client-side (UX için) hem server-side (güvenlik için) yapılmalıdır. Server-side validasyon, regex pattern’leri, tip kontrolü (integer, date) ve uzunluk sınırlamaları ile kurgulanır. Bu katman, SQLi dışında XSS, Command Injection gibi diğer injection saldırılarına karşı da ilk savunma hattıdır.
Mimari Savunma, Derinlemesine Koruma ve Operasyonel Kontroller
Veritabanı veya uygulama katmanından dönen detaylı hata mesajları, saldırgan için harita niteliğindedir. “Unclosed quotation mark after the character string…” veya “Table ‘users’ doesn’t exist” gibi mesajlar, veritabanı türünü, tablo isimlerini ve sorgu yapısını ele verir. Bu bilgi, saldırganın payload’larını hassas şekilde ayarlamasına olanak tanır. Çözüm, genel amaçlı, kullanıcı dostu hata sayfaları kullanmaktır: “Bir hata oluştu, lütfen daha sonra tekrar deneyiniz.” Detaylı hata log’ları sadece sunucu tarafında (server-side logs) tutulmalı ve yetkisiz erişime karşı korunmalıdır. Framework’lerin (Spring Boot, ASP.NET Core, Django) production modunda stack trace gizleme özellikleri aktif edilmelidir. Bu basit ama kritik kontrol, blind SQLi dışındaki saldırı vektörlerinin çoğunu kör eder.
Tags :
#SQLInjection #SQLi #SiberSavunma #WebGüvenliği #PreparedStatements #OWASPTop10 #VeritabanıGüvenliği #CyberSecurity2026 #AppSec #DatabaseSecurity
Share This :