SQL Enjeksiyonu: Hazır İfadeler Neden Tek Gerçek Çözüm?
Arama kutusuna tek tırnak yazan bir ziyaretçi, sitenizde veritabanı hatası görüyor. Bu masum görünen hata mesajı, aslında ciddi bir açığın ilanıdır: kullanıcı girdisi doğrudan sorgunun içine giriyor demektir. Ve aynı yoldan tüm veritabanınız okunabilir.
Bu yazı, enjeksiyon açığını ve doğru korunmayı ele alıyor.
Sorunun Kaynağı
- Sorgu metin olarak birleştirilir.
- Kullanıcı girdisi araya konur.
- Veritabanı hepsini komut sanır.
Üçüncü adım tüm açığın özüdür: veritabanı, kendisine gelen metnin neresinin komut neresinin veri olduğunu bilemez — birleştirme yöntemiyle gönderilen bir sorguda kullanıcının yazdığı metin de komutun parçası hâline gelir.
Bu nedenle sorun kaçış karakterleriyle değil, yapıyla çözülür.
Veri ile komut ayrılmalıdır.
Hazır ifadeler tam olarak bunu yapar.
Hazır İfadeler
- Sorgu şablonu önce gönderilir.
- Değerler ayrıca iletilir.
- Veritabanı ikisini karıştırmaz.
Üçüncü madde neden güvenli olduğunu açıklar: değerler sorgu metninden ayrı gönderildiği için içlerinde ne yazarsa yazsın komut olarak yorumlanamaz — kullanıcı bir tırnak veya tam bir komut yazsa bile o metin yalnızca aranacak değerdir.
Bu koruma yapısaldır, sezgisel değildir.
Kaçış işlevlerine güvenmek ise hataya açıktır.
Bir yerde unutmak yeterlidir.
Yetersiz Çözümler
| Yöntem | Sorun |
|---|---|
| Tırnak temizleme | Sayısal alanlarda işe yaramaz |
| Kara liste kelimeler | Atlatılabilir |
| Kaçış işlevi | Unutulabilir |
| Hazır ifade | Yapısal koruma |
Birinci satır çok yaygın bir yanılgıyı düzeltir: tırnak temizlemek sayısal alanlarda hiçbir koruma sağlamaz — tırnak kullanılmadan yazılan bir sayısal koşulda saldırgan hiç tırnağa ihtiyaç duymaz.
Bu, en sık istismar edilen durumdur.
İkinci satır ise sürekli güncellenmesi gereken bir listedir.
Kara liste yaklaşımı hiçbir güvenlik alanında yeterli olmamıştır.
Hazır İfadelerin Sınırı
- Değerler güvenle bağlanabilir.
- Tablo ve sütun adları bağlanamaz.
- Sıralama yönü de bağlanamaz.
İkinci madde önemli bir boşluğa dikkat çeker: hazır ifadeler yalnızca değerleri korur — sütun adı veya sıralama yönü kullanıcıdan geliyorsa bunlar sorguya metin olarak eklenmek zorundadır ve açık orada oluşur.
Çözüm, izin verilen değerler listesi kullanmaktır.
Kullanıcının gönderdiği sütun adı bu listede yoksa reddedilir.
Doğrudan sorguya konmaz.
Bu, sıralanabilir tablolarda sık karşılaşılan bir durumdur.
En Az Yetki İlkesi
- Uygulama kullanıcısı sınırlı olmalı.
- Yapı değiştirme yetkisi gerekmez.
- Zarar sınırlanır.
Üçüncü madde ikinci savunma hattını kurar: bir enjeksiyon açığı bulunsa bile uygulama kullanıcısının tablo silme yetkisi yoksa saldırgan veritabanını yok edemez — okuma zararı kalır ama yıkım engellenir.
Uygulama hesabı yalnızca gerekli işlemleri yapabilmelidir.
Yönetim işlemleri ayrı bir hesapla yürütülmelidir.
Bu ayrım kurulum aşamasında yapılmalıdır.
Hata Mesajları
| Ortam | Gösterilecek |
|---|---|
| Geliştirme | Tam hata |
| Üretim | Genel mesaj |
İkinci satır saldırganın işini zorlaştırır: ayrıntılı veritabanı hataları saldırgana tablo ve sütun adlarını, hatta sorgunun yapısını verir — üretimde bu mesajlar kullanıcıya değil yalnızca günlüğe yazılmalıdır.
Kullanıcıya genel bir hata gösterilir.
Geliştirici günlükten ayrıntıya ulaşır.
Bu, teşhis yeteneğini kaybetmeden bilgi sızıntısını keser.
Görünmeyen Enjeksiyon
- Hata gösterilmese de açık kapanmaz.
- Doğru yanlış farkından bilgi çıkarılır.
- Yanıt süresinden bile bilgi alınır.
Üçüncü madde tekniğin ne kadar ileri gidebileceğini gösterir: saldırgan sorguya bekleme ekleyerek yanıt süresinden bilgi çıkarabilir — hata mesajı gizlemek açığı kapatmaz, yalnızca istismarı yavaşlatır.
Bu nedenle hata gizleme bir çözüm değildir.
Asıl koruma hazır ifadelerdedir.
İkinci madde ise sayfa içeriğindeki küçük farkları kullanır.
Mevcut Kodu Denetlemek
- Sorgu birleştirmelerini arayın.
- Değişken içeren sorgu satırlarına bakın.
- Eski kodu önceliklendirin.
Üçüncü madde pratik bir öncelik verir: yıllar önce yazılmış modüller hazır ifade kullanılmadan önce yazılmış olabilir — yeni kod güvenliyken eski bir yönetim ekranı hâlâ birleştirme kullanıyor olabilir.
Bu tarama metin arama araçlarıyla hızlı yapılır.
Her bulunan satır tek tek değerlendirilmelidir.
Kalan tek bir satır bile yeterlidir.
Veritabanı kullanıcı yetkilerini ve hata ayarlarını yapılandırabilmek panel erişimi gerektirir; web hosting altyapısı ile veritabanı güvenlik ayarlarınızı kendiniz yönetebilirsiniz.
Sonuç
Enjeksiyon açığı bir kodlama detayı değil yapısal bir sorundur: veritabanı, gelen metnin neresinin komut neresinin veri olduğunu bilemez. Hazır ifadeler bu ayrımı yaptığı için tek gerçek çözümdür. Sınırını bilin — sütun adı veya sıralama yönü bağlanamaz, bunlar için izin listesi kullanın. Uygulama kullanıcısına en az yetkiyi verin ve üretimde ayrıntılı hataları gizleyin.
Sıkça Sorulan Sorular (SSS)
Tırnak temizlemek yetmez mi?
Yetmez. Sayısal alanlarda hiçbir koruma sağlamaz çünkü tırnak kullanılmadan yazılan bir sayısal koşulda saldırganın tırnağa ihtiyacı yoktur. Kara liste yaklaşımları da atlatılabilir; koruma yapısal olmalıdır.
Hazır ifadeler neden güvenli?
Değerler sorgu metninden ayrı gönderilir; içlerinde ne yazarsa yazsın komut olarak yorumlanamaz. Kullanıcı bir tırnak veya tam bir komut yazsa bile o metin yalnızca aranacak değerdir. Bu koruma yapısaldır, sezgisel değildir.
Sütun adını kullanıcıdan alabilir miyim?
Doğrudan sorguya koymayın. Hazır ifadeler yalnızca değerleri korur; sütun adı ve sıralama yönü metin olarak eklenmek zorundadır ve açık orada oluşur. İzin verilen değerler listesi kullanın, listede yoksa reddedin.
Hata mesajlarını gizlemek yeterli mi?
Değil. Saldırgan doğru-yanlış farkından veya sorguya bekleme ekleyip yanıt süresinden bilgi çıkarabilir. Hata gizlemek açığı kapatmaz, yalnızca istismarı yavaşlatır; asıl koruma hazır ifadelerdedir.
