SQL Injection Saldırılarını Tespit Etme

 

SQL Injection Nedir(SQLi)?

SQL Injection (SQLi), kötü amaçlı SQL ifadelerinin yürütülmesini mümkün kılan bir enjeksiyon saldırısı türüdür. Bu ifadeler, bir web uygulamasının arkasındaki veritabanı sunucusunu denetler. Saldırganlar, uygulama güvenlik önlemlerini atlamak için SQL Injection güvenlik açıklarını kullanabilir. Bir web sayfasının veya web uygulamasının kimlik doğrulaması ve yetkilendirmesi etrafında dolaşabilir ve tüm SQL veritabanının içeriğini alabilirler. Ayrıca veritabanına kayıt eklemek, değiştirmek ve silmek için SQL Injection kullanabilirler.

SQL Injection Türleri:

1. In-band SQLi (Klasik SQLi) : Aynı kanal üzerinden bir SQL sorgusu gönderilmiş ve cevaplanmışsa bunlara In-band SQLi deriz. Diğer SQLi kategorilerine kıyasla saldırganların bunlardan yararlanmaları 

daha kolaydır.

2. Inferential SQLi (Blind SQLi): Görünmeyen bir yanıt alan SQL sorgularına Çıkarımsal SQLi denir. Cevap görülemediği için Blind SQLi olarak adlandırılırlar.

3. Out-of-band SQLi : Bir SQL sorgusuna verilen cevap farklı bir kanal üzerinden iletilirse, bu tip SQLi'ye Out-of-band SQLi denir. Örneğin, saldırgan SQL sorgularına DNS üzerinden yanıt alıyorsa buna bant dışı SQLi denir.

 SQL Injection Nasıl Çalışır?

Günümüzde standart web uygulamaları en yaygın olarak bir kullanıcıdan veri alır ve bu verileri belirli içeriği görüntülemek için kullanır. Oturum açma sayfası, çoğu SQL Enjeksiyon saldırısının gerçekleştiği yerdir. SQL enjeksiyonlarının nasıl çalıştığını bir örnek üzerinden inceleyelim.

Bir kullanıcının genellikle giriş sayfasında kullanıcı adını ve şifresini girmesi beklenir. Diğer tarafta, web uygulaması aşağıdaki gibi bir SQL sorgusu oluşturmak için bu kullanıcı adı ve şifre bilgilerini kullanacaktır:

SELECT * FROM users WHERE username = ' USERNAME ' AND password = ' USER_PASSWORD 

Bu SQL sorgusunun anlamı “ USERNAME ve şifresi USER_PASSWORD olan users tablosundan kullanıcı ile ilgili tüm bilgileri bana getir ” dir. Web uygulaması eşleşen bir kullanıcı bulursa kullanıcının kimliğini doğrular, sorgu yapıldıktan sonra bir kullanıcı bulamazsa oturum açma başarısız olur.

Diyelim ki kullanıcı adınız “ john ” ve şifreniz “ super secret password ”. Bu bilgileri girip login butonuna tıkladığınızda aşağıda gördüğünüz SQL sorgusu sorgulanacak ve SQL sorgusu sonrasında bir eşleşme bulunduğu için girebileceksiniz.

SELECT * FROM users WHERE username = ' john ' AND password = ' supersecretpassword '

Peki ya bu sistemi tasarlandığı gibi kullanmasaydık ve kullanıcı adı alanına kesme işareti (') koysaydık? SQL sorgusu aşağıdaki gibi olacak ve sorgu hatalı olduğu için hata veritabanından çıkarılacaktır.

SELECT * FROM users WHERE username = ' john ' AND password = ' supersecretpassword '

Saldırgan bir hata mesajı almaktan memnun olacaktır. Saldırgan hem hata mesajındaki bilgileri kendi avantajına değiştirebilir hem de doğru yolda olduğunu gösterir. Saldırgan, kullanıcı adı alanına aşağıdaki gibi bir yük girerse ne olur?

' OR 1=1 – -

Saldırgan yükü gönderdiğinde, web uygulaması aşağıdaki SQL sorgusunu yürütecektir:

SELECT * FROM users WHERE username = ‘’ OR 1=1 – - AND password = 'supersecretpassword'

SQL'de “-- -” den sonra gelen karakterler yorum satırı olarak algılanacaktır. Yani yukarıdaki sorguya bakarsak “-- -” den sonra gelen sorgular bir şey ifade etmez. SQL sorgusunu incelemeye devam etmeden önce işleri basitleştirmek için bu kısmı kaldıralım.

SELECT * FROM users WHERE username = ‘’ OR 1=1

Şimdi yukarıdaki sorgu şuna benziyor: “ kullanıcı adı boşsa veya 1=1 ”. Kullanıcı adı alanının boş bırakılıp bırakılmaması çok önemli değil çünkü 1 her zaman 1'e eşittir. Bu nedenle bu sorgu her zaman doğru olacak ve büyük ihtimalle veritabanındaki ilk satırı çağıracaktır. Saldırgan, eşleşme olduğu için web uygulamasına başarılı bir şekilde girebilecektir.

Bu örnek tipik bir SQL enjeksiyon saldırısıdır. Elbette SQL enjeksiyon saldırıları bu örnekle sınırlı değil, saldırgan xp_cmdshell gibi SQL komutları yardımıyla sistemde komutları çalıştırmak için SQL'i kullanabilir.

Saldırganlar SQL Injection Saldırılarından Nasıl Yararlanır?

SQL Injection saldırılarının neden bu kadar kritik öneme sahip olduğunu anlamak için, SQL Injection saldırısının neden olabileceğine bir göz atalım.

• Kimlik doğrulama atlama
• Komut yürütme
• Hassas verileri sızdırma
• Veritabanı girişlerini oluşturma/silme/güncelleme

 SQL Injection Nasıl Önlenir?

• Bir çerçeve (frame) kullanın: elbette sadece bir çerçeve kullanmak, bir SQL Enjeksiyon saldırısını önlemek için yeterli olmayacaktır. Çerçevenin dokümantasyona uygun olarak kullanılması son derece önemlidir.
• Çerçevenizi (frame) güncel tutun: Kullandığınız çerçeve ile ilgili güvenlik güncellemelerini takip ederek web uygulamanızın güvenliğini sağlayın.
• Bir kullanıcıdan alınan verileri her zaman sterilize edin: Bir kullanıcıdan alınan verilere asla güvenmeyin. Bunun da ötesinde, yalnızca form verilerini sterilize etmekle kalmaz, aynı şeyi diğer verilerle (Başlıklar, URL'ler vb.)
• Ham SQL sorguları kullanmaktan kaçının: Ham SQL sorguları yazma alışkanlığınız olabilir, ancak bir çerçevenin sağladığı avantajlardan yararlanmayı seçmeli ve sağladığı güvenlikten de yararlanmalısınız.

                    

SQL İnjection Saldırılarını Tespit Etme

Saldırganların SQL Injection saldırısı ile neler yapabileceğini önceki bölümde tartışmıştık. Yukarıda belirtilen SQL Injection sonuçlarının her biri bir kurum için büyük kayıplara neden olabilir, bu nedenle SOC Analistleri olarak bu saldırıları tespit edebilmemiz ve bunlara karşı önlem alabilmemiz gerekir.

Peki SQL Injection saldırılarını nasıl tespit edebiliriz?

Bu sorunun birden fazla cevabı var. Bunlar:

• Bir web isteğini incelerken kullanıcıdan gelen tüm alanları kontrol edin: SQL Injection saldırıları form alanlarıyla sınırlı olmadığı için User-Agent gibi HTTP İstek Başlıklarını da kontrol etmelisiniz.
• SQL anahtar sözcüklerini arayın: Kullanıcılardan alınan verilerde INSERT, SELECT, WHERE gibi sözcükleri arayın.
• Özel karakterleri kontrol edin: Kullanıcıdan alınan veriler içerisinde SQL'de kullanılan kesme işareti ('), tire (-) veya parantez veya SQL saldırılarında sıklıkla kullanılan özel karakterler olup olmadığına bakın.
• Sık kullanılan SQL Injection yükleri hakkında bilgi edinin: SQL yükleri web uygulamasına göre değişse de, saldırganlar SQL Injection güvenlik açıklarını kontrol etmek için hala bazı ortak yükler kullanır. Bu yüklere aşina iseniz, SQL Injection yüklerini kolayca tespit edebilirsiniz.

Otomatik SQL Injection Araçlarını Algılama

Saldırganlar, SQL Injection güvenlik açıklarını tespit etmek için birçok otomatikleştirilmiş cihaz kullanır. En iyi bilinenlerden biri Sqlmap'tir. Belirli bir araca odaklanmak yerine daha geniş resme bakalım.

SQL Injection cihazlarını tespit etmek için aşağıda listelenen yöntemleri kullanabilirsiniz:

1. User-Agent'a bakın: Otomatik tarayıcı cihazlarının adları ve sürümleri genellikle kaydedilir. Bu otomatik cihazları algılamak için user agent bakabilirsiniz.
2. İsteklerin sıklığını kontrol edin: Otomatik cihazlar, yükleri mümkün olduğu kadar çabuk test edebilmek için, tahmini olarak saniyede çok sayıda istek gönderecek şekilde tasarlanmıştır. Normal bir kullanıcı saniyede 1 istek gönderebilir, böylece isteklerin otomatik bir cihaz tarafından yapılıp yapılmadığını saniyedeki istek sayısına bakarak anlayabilirsiniz.
3. Yükün içeriğine bakın: Otomatik cihazlar genellikle kendi adlarını yüklerine kaydeder. Örneğin, otomatikleştirilmiş bir cihaz tarafından gönderilen bir SQL Enjeksiyon yükü şöyle görünebilir: sqlmap' OR 1=1 
4. Yük karmaşık mı: Bu algılama yöntemi her zaman işe yaramayabilir, ancak deneyimlerime dayanarak, otomatik cihazların daha karmaşık yükler gönderdiğini söyleyebilirim.

Algılama Örneği

SQL Injection saldırısının kurbanı olan bir web uygulamasının erişim günlğklerine (access logs) sahibiz.

Erişim günlüğünün (access log) ne olduğunu daha önce duymamış olabilirsiniz. Kısacası bunlar web sunucusunun erişim günlükleridir (access logs). Bu günlükler genellikle kaynak IP adresini, tarihi, istenen URL'yi, HTTP yöntemini, kullanıcı aracısını ve HTTP Yanıt kodunu içerir. Bu günlükler(logs) araştırmalarda çok faydalıdır.

(SQL Injection Erişim Günlükleri)

Elimizde bir erişim kaydı var. Şimdi ne yapıyoruz?

Öncelikle talep edilen sayfalara baktığımızda oldukça okunaklı olan “info.php” gibi sayfaların yanı sıra karmaşık ve % gibi sembolleri olan sayfalara da istekte bulunulduğunu görüyoruz. Bu tür sayfalara yapılan isteklerin kötü niyetli olduğunu söyleyemeyiz ama defalarca ve defalarca yapılması şüphelidir.

Öncelikle % sembollerinin ne anlama geldiğinden bahsedelim. Özel karakterler içeren bir sayfa talep ettiğimizde bu istekler doğrudan web sunucusuna aktarılmaz. Bunun yerine, tarayıcılarımız özel karakterlerin bir URL kodlamasını (Yüzde Kodlama) gerçekleştirir ve her özel karakteri % ile başlayan ve 2 onaltılık karakter içeren bir karakter dizisiyle değiştirir. Yani yukarıdaki % sembolünü içeren sayfalar özel karakterler içeren sayfalardır.

Artık % sembollerinin ne anlama geldiğini anladığımıza göre, erişim günlüklerini tekrar gözden geçirelim. Taleplere baktığımızda % sembollerinin yanında “UNION”, “SELECT”, “AND”, “CHR” gibi okunabilir kelimelerin olduğunu rahatlıkla görebiliriz. Bunlar SQL'e ait spesifik kelimeler olduğu için bir SQL Injection saldırısı ile karşı karşıya olduğumuzu belirleyebiliriz.

Gözümüze sokmamak için, incelemeyi biraz daha kolaylaştıralım :) "Online URL Decoder" anahtar kelimelerini kullanarak arama yaparak URL kodunu sizin yerinize otomatik olarak yapacak web uygulamalarını bulabilirsiniz. Bu erişim kayıtlarını daha kolay okuyabilmek için bu web uygulamalarından yardım alacağım, böylece ne gözlerimi ne de sizin gözlerinizi yormuş olacağım.

Küçük bir not ekleyeyim. Bir 3. taraf web uygulamasına kritik bilgiler içeren erişim günlükleri gibi bir şey yüklemek akıllıca değildir. Yüklediğim erişim logları bu eğitim için özel olarak hazırlandı, bu yüzden yapmamda bir sorun yok. Ancak profesyonel yaşamınızda bu tür hatalar yapmamalısınız.

URL kod çözme işlemini yaptığımızda bunun bir SQL Injection saldırısı olduğunu daha net görebiliriz. Öyleyse şimdi ne yapmalıyız? Evet, bunun bir SQL Injection saldırısı olduğunu doğruladık ama onu orada mı bırakacağız?

Tabii ki değil. Şimdi bu erişim günlüklerinden alabildiğimiz diğer bilgileri bulacağız.

Öncelikle talep tarihlerine bakalım. Tüm SQL Injection yükleri “19/Feb/2022 11:09:24” tarihinde gönderildi. 1 saniyede 50'den fazla istek yapıldığını görebiliyoruz. Bu kadar kısa sürede bu kadar çok talebin yapılmış olması bize bunun otomatikleştirilmiş bir saldırı olduğunu gösteriyor. Ek olarak, daha önce de belirttiğimiz gibi, saldırganlar manuel testler yaparken önce kolay yükleri test etmeyi seçerler. Ancak erişim loglarına baktığımızda, yüklerin çok karmaşık olduğunu görüyoruz. Bu, saldırının çok iyi otomatikleştirilebileceğini gösteriyor.

Bir SQL Injection saldırısının gerçekleştirildiğini ve otomatik bir cihazla gerçekleştirildiğini doğruladık. Böylece analizimizi sonlandırabiliriz, değil mi?

Yapılacak bir adım daha kaldı. Saldırının başarılı olup olmadığını belirlememiz gerekiyor. Bir SQL Injection saldırısının başarılı olup olmadığını cevaba bakarak anlayabilirsiniz ancak profesyonel kariyerinizde cevaba neredeyse hiç erişemeyeceksiniz. Saldırı aynı sayfada ve “id” değişkeni üzerinden gerçekleştirildiği için tüm yanıtların aşağı yukarı aynı boyutta olacağını varsayabiliriz. Tepkinin boyutuna bakarak saldırının başarısını tahmin edebiliriz.

Örnek olması için geliştirilen temel web sunucusu ne yazık ki güvenilir bir yanıt boyutu sağlayamıyor. Bu nedenle, bu örneğe bakarak saldırının başarılı olup olmadığını tahmin edemeyiz. Ancak doğru yapılandırılmış web sunucuları ile erişim günlüklerinde yanıt boyutunu bulabiliriz. Yanıt boyutlarında kayda değer bir fark olup olmadığını belirlemek için bu alanı inceleyebilirsiniz. Belirgin bir fark varsa, saldırının başarılı olduğunu tahmin edebilirsiniz. Ancak bu durumda, bu uyarıyı daha üst düzey bir analiste iletmek en iyisi olacaktır.

Ne biliyoruz: 

1. Web uygulamasının ana sayfasındaki “id” parametresine SQL Injection saldırısı yapılmıştır.
2. İstekler şu IP adresinden geldi: 192.168.31.174.
3. Saniyede 50'den fazla istek olduğundan, bu saldırı otomatik bir güvenlik açığı tarama aracı tarafından gerçekleştirildi.
4. Yüklerin karmaşık yapısı 3. maddedeki iddiayı desteklemektedir.
5. Yanıt boyutu hakkında herhangi bir bilgimiz olmadığı için yanıtın başarılı olup olmadığını belirleyemiyoruz.

Soru 1

('SQL Injection - Web Attacks' Dosyasını Araştırın) SQL Injection saldırısını gerçekleştiren saldırganın IP adresi nedir?

Cevap: 192.168.31.167

Sorunun cevabını bulabilmek için yukarıdaki dosyayı indirmemiz gerekiyor. Ardından soruda bize SQL Injection saldırısını gerçekleştiren saldırganın IP adresini soruyor bizde indirdiğimiz dosyaya bakarak saldırganın IP adresini buluyoruz.

Soru 2

SQL Injection - Web Attacks' Dosyasını Araştırın) SQL Injection saldırısı başarılı oldu mu? (Yes/No)

Cevap: Yes

Soru 3

('SQL Injection - Web Attacks' Dosyasını Araştırın) SQL Injection saldırısının türü nedir?

Cevap:  Classic

İndirdiğimiz dosyayı incelediğimiz zaman SQL sorgusunun aynı kanal üzerinden gönderilmiş ve cevaplanmış olduğunu görüyoruz. Bu yüzden cevabımız Classic SQL injection saldırısı oluyor.

Diğer SQLi kategorilerine kıyasla saldırganların bunlardan yararlanmaları daha kolaydır.

Bugün LetsDefend platformunda bulunan SQL İnjection odasını çözdük. Umarım sizler için faydalı bir yazı olmuştur. Bir sonraki yazıda görüşmek dileğiyle hoşçakalın.