SQLi (SQL enjeksiyonu)

Kısaca: Saldırganların güvensiz girdi alanları üzerinden bir veritabanı sorgusuna kendi SQL kodlarını enjekte ettiği saldırı tekniği — verileri okuyabilir, değiştirebilir veya silebilir.

Biraz daha ayrıntılı: Kullanıcı girdisi denetlenmeden doğrudan bir SQL sorgusuna eklendiğinde ortaya çıkar (parametreli sorgular yerine dize birleştirme). Klasik örnek: içine ' OR '1'='1 yazılan bir giriş alanı parola denetimini aşabilir. Standart savunma, kullanıcı girdisinin asla çalıştırılabilir SQL kodu olarak yorumlanamadığı parametreli sorgular/hazır ifadelerdir.

Ayrıntılı

Savunmasız bir giriş sorgusu saf biçimde şöyle görünebilir (dize birleştirme, kullanıcı girdisi doğrudan eklenmiş):

-- Savunmasız kod (ASLA böyle yazmayın):
query = "SELECT * FROM users WHERE username = '" + input + "' AND password = '" + pw + "'"
 
-- Girdi: username = admin' --
-- Ortaya çıkan sorgu:
SELECT * FROM users WHERE username = 'admin' --' AND password = '...'
-- Parola denetimi "--" (SQL yorumu) ile basitçe yorum satırı yapılır!

Bu tür manipülasyonlarla saldırgan yalnızca giriş denetimini aşmakla kalmaz, veritabanı bağlantısının yetkilerine bağlı olarak tüm tabloları okuyabilir (diğer tablolardan verileri çıktıya sokmak için UNION SELECT), verileri değiştirebilir veya silebilir, kötü durumlarda veritabanı sunucusunun kendisinde komut bile çalıştırabilir.

Güvenilir savunma yapısaldır, “tehlikeli karakterleri filtrelemek” değildir:

// Güvenli: parametreli sorgu - girdi ASLA SQL kodu olarak yorumlanmaz
db.query("SELECT * FROM users WHERE username = $1", [input])

Parametreli sorgularda (“prepared statements”) uygulama, sorgunun yapısını ve kullanıcı girdisini veritabanına ayrı ayrı gönderir — veritabanı böylece kullanıcı ne yazarsa yazsın hangi parçanın “kod” (sorgu yapısı), hangisinin salt “veri” (girdi) olduğunu her zaman bilir. Modern ORM’ler (Drizzle ORM’e bakın) varsayılan olarak dahili olarak parametreli sorgular kullanır; bu yüzden ORM doğru kullanıldığında SQL enjeksiyonu pratikte dışlanır — dize birleştirmeli ham SQL ise her dilde/çerçevede mümkün ve tehlikeli kalır.

Kör SQL enjeksiyonu

Savunmasız bir uygulama veritabanı hatalarını veya sorgu sonuçlarını her zaman doğrudan çıktılamaz — “kör SQL enjeksiyonunda” saldırgan doğrudan geri bildirim görmez ama uygulamanın davranışını gözle görülür biçimde etkileyen koşullar kurarak (örn. koşulun doğru ya da yanlış olmasına göre farklı yanıt süresi veya farklı sayfa) yine de bilgi çıkarabilir. Örnek: ' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin')='a — uygulama koşulsuz haliyle aynı yanıtı verirse tahmin doğrudur, yoksa değildir. Karakter karakter, görünür hata mesajı olmadan bile kuramsal olarak eksiksiz bir parola çıkarılabilir — klasik SQLi’den çok daha yavaş ama aynı derecede tehlikeli.

Ek koruma katmanları

Parametreli sorgular en önemli ama tek savunma hattı değildir. En az ayrıcalık ilkesi, başarılı bir enjeksiyonun bile zararını sınırlar: bir web uygulamasının bağlandığı veritabanı kullanıcısı yalnızca gerçekten gereken izinlere sahip olmalıdır (örn. salt okuma uç noktası için DROP TABLE yetkisi olmamalı). Bir web uygulaması güvenlik duvarı (WAF) bilinen enjeksiyon desenlerini gelen trafikte uygulamaya ulaşmadan tanıyıp engelleyebilir — ek güvenlik olarak, kodun kendisindeki güvenli veritabanı erişiminin yerine geçmez. Düzenli otomatik güvenlik taramaları (örn. kendi testlerinizin parçası olarak sqlmap gibi araçlarla) kazara eklenen enjeksiyon açıklarını gerçek bir saldırıdan önce erken bulmaya yardım eder.

Ayrıca bakınız: SQL, Sahte çerezler