Pip: Yavuz Filizlibay, SQL Injection’ın yirmi beş yıldır hayatta olduğunu hatırlatıyor — bu noktada artık bir güvenlik açığı değil, bir kurum kültürü gibi.
Mara: Bu bölümde SQL Injection’ın nasıl çalıştığını, klasik atak vektörlerini ve SQL Server 2025’in yeni regex fonksiyonlarıyla savunmanın nasıl katmanlandığını ele alacağız.
Pip: Hadi başlayalım o zaman — SQL Injection ve defense in depth tarafına geçelim.
SQL Injection: Klasik Ataklar ve Yeni Savunma Katmanları
Mara: Yazı, neden SQL Injection’dan başlandığını tek cümleyle açıklıyor: yirmi beş yıldır var, hâlâ OWASP Top 10’da ve hâlâ Türkiye’deki uygulamaların ciddi bir kısmında savunmasız kod görülüyor. Sorunun yaşı, çözülmüş olduğu anlamına gelmiyor.
Pip: Yazının omurgasını oluşturan cümle şu: “En güvenli SQL kodu, literal string concatenation içermeyen koddur.” Basit bir kural, ama yazıya göre bu tek kuralı korumak SQL Injection’ın yüzde doksanbeşini siliyor.
Mara: Tam olarak. String concatenation neden bu kadar tehlikeli, bunu somutlaştırmak için yazı authentication bypass örneğiyle açıyor. Kullanıcı adı alanına “admin’ OR ‘1’=’1” girildiğinde, oluşan SQL sorgusunda OR operatörü ve operatör önceliği birleşince şifre kontrolü devre dışı kalıyor ve admin satırı dönüyor.
Pip: Ve bu sadece başlangıç noktası. Yazı dört atak vektörünü sıralıyor: authentication bypass, UNION-based veri sızdırma, error-based şema keşfi ve time-based blind injection.
Mara: Time-based tarafı özellikle dikkat çekici. Hata mesajları tamamen bastırılmış olsa bile response süresi üzerinden binary search ile veri elde edilebiliyor. Yazının hesabıyla, bir parolayı karakter karakter çıkarmak yaklaşık otuz beş dakika alıyor; sqlmap gibi araçlar bunu paralel işlemle dakikalar düzeyine indiriyor.
Pip: Yani sessiz bir kanal. Kimse fark etmeden veri akıyor.
Mara: Savunma tarafında yazı beş katmanlı bir defense in depth modeli kuruyor: parameterized query, input validation, least privilege, stored procedure isolation ve audit ile monitoring. Her katman bağımsız çalışıyor; biri delinirse diğeri tutuyor.
Mara: SQL Server 2025 burada yeni bir araç sunuyor. REGEXP_LIKE, REGEXP_COUNT, REGEXP_REPLACE gibi ANSI standart regex fonksiyonları artık doğrudan T-SQL’de kullanılabiliyor. Bunların pratik anlamı şu: uygulama katmanında validation atlanmış olsa bile, prosedürün girişine bir format kapısı koyabiliyorsunuz.
Pip: Uygulama yazmış, validation unutmuş, ama veritabanı kapıda duruyor.
Mara: Yazı bunu somut bir örnekle gösteriyor: “admin’ OR ‘1’=’1′–” girdisi REGEXP_LIKE kapısına takılıyor, sorgu hiç çalışmıyor. Least privilege tarafında ise uygulama kullanıcısının tabloya doğrudan SELECT, INSERT veya UPDATE yetkisi almadığı, yalnızca tanımlı prosedürlere EXECUTE hakkı verildiği bir model kuruluyor.
Mara: Bir de araç notu var: SSMS’in yerleşik SQL Vulnerability Assessment özelliği SSMS 19.1’den itibaren kaldırılmış. Yazı bunun yerine hem Microsoft Defender for SQL’i hem de sistem katalog görünümleriyle çalışan yerel bir T-SQL tarama scriptini öneriyor. xp_cmdshell’in kapalı olması da bu taramanın parçası; çünkü açık bir xp_cmdshell, başarılı bir injection’ı işletim sistemi komutuna dönüştürebiliyor.
Pip: Sonraki haftaya bırakılan konu ise Always Encrypted — verilerin sunucuda hiç düz hâlinin görünmediği model, defense in depth’in bir üst katmanı.
Mara: Özünde mesaj şu: parameterized query, least privilege ve input validation yirmi beş yıllık çözümler — SQL Server 2025’in regex fonksiyonları bu katmanlara server tarafında yeni bir araç ekliyor.
Pip: Bir sonraki bölümde Always Encrypted ve Secure Enclaves var. Saldırgan veriyi ele geçirse bile elinde yalnızca şifreli metin kalıyor — görüşürüz.