SQL Injection Nedir? Web Zafiyetleri Serisi #1

Bugünden itibaren Siberatay’da yeni bir seriye başlıyoruz: Web Zafiyetleri. Her yazıda OWASP Top 10’da yer alan bir web güvenlik açığını, nasıl oluştuğunu, gerçek dünyada nasıl hasar bıraktığını ve nasıl önlenebileceğini detaylıca ele alacağız. Serinin ilk konusu, yıllardır listenin başından hiç düşmeyen, sayısız veri ihlaline imza atmış klasik: SQL Injection.

SQL Injection Nedir?

SQL Injection (SQLi), bir web uygulamasının kullanıcıdan aldığı veriyi, veritabanına gönderdiği SQL sorgusuna güvenlik kontrolünden geçirmeden eklemesi sonucu ortaya çıkan bir zafiyet türü. Saldırgan, normalde bir isim veya şifre girmesi beklenen bir alana özel karakterler ve SQL komutları yerleştirerek, uygulamanın veritabanıyla konuşma şeklini kendi lehine değiştirebiliyor.

Sonuç olarak saldırgan, yetkisi olmayan verileri okuyabiliyor, değiştirebiliyor, silebiliyor; hatta bazı durumlarda veritabanı sunucusu üzerinden işletim sistemine kadar erişim sağlayabiliyor.

SQL Injection Nasıl Oluşur?

Sorunun kökü, kullanıcıdan gelen verinin SQL sorgusuna doğrudan, string birleştirme (concatenation) yoluyla eklenmesi. Örnek bir giriş formu düşünelim; arka planda çalışan sorgu şöyle yazılmış olsun:

$query = "SELECT * FROM users WHERE username = '" . $username . "' AND password = '" . $password . "'";

Kullanıcı adı alanına normal bir isim yerine şunu yazarsa:

' OR '1'='1

Sorgu arka planda şu hale gelir:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''

“1’=’1” ifadesi her zaman doğru olduğu için, sorgu şifre kontrolünü etkisiz hale getirir ve saldırgan hiçbir şifre bilmeden sisteme giriş yapabilir. Bu, SQL Injection’ın en temel ve en çok bilinen örneği; gerçek saldırılar genelde çok daha karmaşık ve hedefe özel sorgular içerir.

SQL Injection Türleri

Klasik (In-band) SQL Injection

Saldırganın hem sorguyu gönderdiği hem de sonucu doğrudan aynı kanaldan (örneğin sayfa içeriğinde) gördüğü en basit tür. Hata mesajları veya sayfa çıktısı üzerinden veri sızdırılır.

Blind (Kör) SQL Injection

Uygulama herhangi bir hata mesajı veya doğrudan veri göstermiyorsa saldırgan “kör” çalışmak zorunda kalır. İki alt türü var:

• Boolean-based: Saldırgan doğru/yanlış sorular sorar (“kullanıcı adı ‘a’ harfiyle mi başlıyor?”) ve sayfanın davranışındaki (görünen içerik, yönlendirme) farka bakarak cevabı anlar.
• Time-based: Sayfa davranışında görünür bir fark yoksa, saldırgan veritabanına “eğer bu doğruysa 5 saniye bekle” komutu gönderir ve cevabı yanıt süresinden çıkarır.

Out-of-band SQL Injection

Sonucun ne sayfa içinde göründüğü ne de zamanlamadan anlaşılabildiği durumlarda kullanılır. Veritabanı, sonucu DNS veya HTTP isteği gibi tamamen farklı bir kanaldan saldırganın kontrolündeki bir sunucuya gönderecek şekilde yönlendirilir.

Second-Order SQL Injection

Zararlı veri hemen çalıştırılmaz; önce veritabanına normal bir veri gibi kaydedilir, daha sonra başka bir işlem bu veriyi güvenli olduğunu varsayarak tekrar bir sorguda kullandığında tetiklenir. Bu yüzden tespiti diğer türlere göre daha zordur.

Gerçek Dünyadan Bir Örnek: TalkTalk Veri İhlali

2015’te İngiliz telekom şirketi TalkTalk, klasik bir SQL Injection saldırısıyla 157 bin müşterisinin kişisel verilerinin, 15 binden fazlasının da banka hesap bilgilerinin çalınmasına engel olamadı. Saldırgan, sqlmap adlı açık kaynaklı bir aracı kullanarak şirketin 2009’da satın aldığı, unutulmuş ve güncellenmemiş eski bir web sayfasındaki SQLi açığını buldu.

İşin ilginç yanı, aynı sistemin daha önce iki kez benzer şekilde saldırıya uğramış olması ama şirketin bunu fark edip önlem almamış olmasıydı. İngiltere’nin veri koruma otoritesi ICO, TalkTalk’a “en temel güvenlik önlemlerini bile almamak” gerekçesiyle 400 bin sterlin ceza kesti; toplam maliyet şirkete 77 milyon sterline mal oldu.

Bu örnek aslında SQL Injection’ın teknik karmaşıklığından çok, temel hijyen eksikliğinden kaynaklanan bir risk olduğunu gösteriyor: unutulmuş bir sayfa, güncellenmemiş bir veritabanı ve göz ardı edilen erken uyarılar.

SQL Injection Nasıl Tespit Edilir?

Bir web uygulamasının SQLi’ye karşı savunmasız olup olmadığını anlamanın birkaç yolu var:

• Manuel test: Form alanlarına tek tırnak (‘) gibi özel karakterler girip uygulamanın hata verip vermediğine bakmak, ilk ve en basit kontrol.
• Otomatik tarama: Daha önce ele aldığımız OWASP ZAP gibi araçlar, bir web uygulamasını otomatik tarayarak SQLi şüphesi taşıyan noktaları işaretleyebilir.
• sqlmap: Şüpheli bir nokta bulunduğunda, bu açığın gerçekten istismar edilebilir olup olmadığını doğrulamak için kullanılan, sektörde en yaygın açık kaynaklı SQLi test aracı.
• Kod incelemesi: Statik kod analizi, sorguların parametrik olup olmadığını (yani string birleştirme kullanılıp kullanılmadığını) doğrudan kaynak koddan tespit edebilir.

SQL Injection’dan Nasıl Korunulur?

• Parametreli sorgular (Prepared Statements) kullanın: En etkili ve endüstri standardı çözüm budur. Kullanıcı verisi asla sorgunun bir parçası olarak değil, ayrı bir parametre olarak veritabanına gönderilir.
• ORM kütüphaneleri kullanın: Doğru yapılandırıldığında, ORM araçları (Eloquent, Hibernate, SQLAlchemy gibi) çoğu zaman parametreli sorguları varsayılan olarak uygular.
• Girdi doğrulama (input validation) uygulayın: Beklenmeyen karakter ve formatları en baştan reddedin — ama bunu tek başına bir savunma olarak değil, ek bir katman olarak düşünün.
• En az yetki prensibini uygulayın: Uygulamanın veritabanı hesabı, sadece ihtiyacı olan işlemleri yapabilecek kadar yetkiye sahip olmalı; tüm tabloları silebilecek bir hesapla bağlanmamalı.
• WAF (Web Application Firewall) kullanın: Bilinen SQLi kalıplarını yakalayıp engelleyerek ek bir koruma katmanı sağlar — ama kod seviyesindeki düzeltmenin yerini tutmaz.
• Eski ve unutulmuş sayfaları düzenli denetleyin: TalkTalk örneğinde olduğu gibi, riskin çoğu zaman aktif kullanılan değil, unutulmuş sistemlerden geldiğini unutmayın.

Sık Sorulan Sorular

SQL Injection hâlâ güncel bir tehdit mi?
Evet. Onlarca yıllık bir zafiyet olmasına rağmen OWASP Top 10 listesinde hâlâ üst sıralarda; çünkü eski kod tabanları ve özensiz geliştirme pratikleri hâlâ yaygın.

NoSQL veritabanları bu riske karşı bağışık mı?
Hayır. MongoDB gibi NoSQL veritabanları da benzer bir mantıkla çalışan “NoSQL Injection” saldırılarına karşı savunmasız olabilir.

Küçük bir web sitesi de hedef olur mu?
Kesinlikle. Çoğu SQLi saldırısı belirli bir hedefe değil, otomatik taramalarla internet genelinde savunmasız sistemlere karşı gerçekleştirilir.

Sonuç

SQL Injection, siber güvenliğin en eski açıklarından biri olmasına rağmen hâlâ en çok hasar veren zafiyetlerden biri olmayı sürdürüyor — çünkü çözümü basit olsa da (parametreli sorgular), gerçek dünyada gözden kaçırılan tek bir eski sayfa bile bir şirketi TalkTalk’un yaşadığı krize sürükleyebiliyor. Web Zafiyetleri serisinin bir sonraki yazısında XSS’i (Cross-Site Scripting) ele alacağız. Kurumunuzun web uygulamalarını SQL Injection ve benzeri açıklara karşı profesyonel bir ekiple test ettirmek isterseniz, Siberatay olarak yanınızdayız.