Kategoriler
web-application

CWE-89 SQL Injection

CWE-89 SQL Injection


CWE-89 SQL Injection, bir SQL sorgusunda kullanılan özel öğelerin yanlış nötrleştirilmesinden kaynaklanan bir zayıflıktır. SQL enjeksiyonunun temel biçimi, SQL komutlarını oluşturmak için kullanılan değişkenlere saldırgan tarafından kontrol edilen verilerin doğrudan eklenmesini açıklar. Sonuç olarak, bir saldırgan dizeyi kalıcı olarak sonlandırarak, yeni komutlar ekleyerek vs. orijinal sorguyu kurcalayabilir.

CWE-89 SQL Injection Etkisi


Saldırgan, veritabanında depolanan bilgileri mevcut veritabanı kullanıcısının ayrıcalıklarıyla görüntüleyebilir, ekleyebilir, silebilir veya değiştirebilir. Web uygulaması durumunda, bu zayıflık genellikle bir web sitesinin tahrif edilmesine veya veritabanı hırsızlığına yol açar. Veritabanının güvenli olmayan yapılandırması, bir saldırganın dosyaları sistemdeki rastgele konumlara yazmasına (örneğin MySQL’de SELECT … INTO OUTFILE yapı oluşturma) ve bu da sistemin tehlikeye atılmasına neden olabilir.


Modern SQL enjeksiyonları kötü amaçlı yazılımları yaymak için kullanılıyor. Bunun yanı sıra masum web sitelerini, şüphesiz ziyaretçilere kötü amaçlı yazılım sunan sitelere dönüştürmek için kullanılabilir.


CWE-89 SQL Injection Saldırı Düzenleri


Bir saldırgan, kullanıcı girdisine göre SQL komutları oluşturan yazılımdaki bu zayıflıktan yararlanır. CAPEC sınıflandırmasına göre aşağıdaki saldırı modelleri vardır:
CAPEC-7: Kör SQL Enjeksiyonu
CAPEC-66: SQL Enjeksiyonu
CAPEC-108: SQL Enjeksiyonu ile Komut Satırı Yürütme
CAPEC-109: Nesne İlişkisel Haritalama Enjeksiyonu
CAPEC-110: SOAP Parametre Tamperleme ile SQL Enjeksiyonu


CAPEC-470: Veritabanından İşletim Sistemi Üzerindeki Kontrolü Genişletme

WASC Tehdit Sınıflandırması, SQL enjeksiyon zayıflığını WASC-19 kapsamında bir saldırı tekniği olarak tanımlar.
Etkilenen Yazılım
Bilgileri depolamak veya okumak için arka uç veritabanı kullanan yazılımlar, bu zayıflığa karşı potansiyel olarak savunmasızdır. Tüm modern içerik yönetim sistemleri dinamik içeriği depolamak için veritabanını kullandığından, zayıflık birçok web uygulaması için yaygındır. SQL enjeksiyonu, veritabanı motorlarındaki saklı prosedürler veya işlevler içinde de mümkündür.


Önem Derecesi ve CVSS Puanlaması


SQL enjeksiyonu, uygulamanın gizliliğini, bütünlüğünü ve kullanılabilirliğini etkiler, C: H / I: H / A: H olarak puanlanmalıdır . Genel olarak erişilebilen komut dosyalarındaki SQL enjeksiyon güvenlik açıkları için ortak CVSS puanı:
9.8 [CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: U / C: H / I: H / A: H ] – Kritik önem derecesi.


CWE-89 SQL Injection Etkisi Azaltıcılar


Girdi verilerinin nötrleştirilmesi, SQL enjeksiyon saldırılarına karşı ana savunma yaklaşımı olarak kabul edilir. Bu, giriş verilerini uygulama içindeki SQL sorgularında kullanmadan önce veya WAF veya IDS / IPS sistemi gibi güvenlik yazılımları aracılığıyla temizleyerek başarılmalıdır.


Geliştirme sırasında ortaya çıkan yaygın hataları göstermeye çalışacağız ve bunlardan nasıl kaçınılacağına dair tavsiyeler vereceğiz. SQL enjeksiyonu, güvenilmeyen kaynaktan gelen veriler uygulamaya aktarıldığında veya dinamik sorgular oluşturmak için güvenilmeyen veriler kullanıldığında gerçekleştiğinden, bu girdinin nötrleştirilmesinin gerçekleştirilmesi açıktır. Ancak bu, uygulamayı korumak için yeterli olmayabilir.


Örnek 1:


Güvenlik açığından etkilenen komut dosyası, HTTP GET parametresinden bilgi alır ve bunu sorgu oluşturmak için kullanır:
$ id = $ _GET [ ‘id’ ] ;
$ res = mysqli_query ( “SEÇ * id = ‘”. $ id . “‘” ) ;
Bu durumda bir saldırgan, özel olarak hazırlanmış bir dizeyi id parametresine geçirebilir ve sorguyu istendiği gibi değiştirebilir:
http://[host]/?id=’ veya ‘a’=’a
Dolayısıyla, veritabanına yapılan asıl sorgu şu şekilde görünür:
SEÇ * id = ” veya ‘a’ = ‘ a ‘
Görüldüğü gibi, id parametresindeki tek tırnak, sorguya ek satırlar eklemeyi mümkün kılar. Buradaki mantıksal çözüm, bu sembolden kaçmak olacaktır. PHP durumunda, mysqli_real_escape_string()veya gibi yerel işlevlerle yapılması mümkündür addslashes(). Bu işlevler özel karakterlerden kaçınır ve girişi uygulama için güvenli hale getirir:
$ id = mysqli_real_escape_string ( $ _GET [ “id” ] ) ;

Örnek 2:


Bu örnekte, temelde aynı komut dosyasına ve aynı sorguya sahibiz:
$ id = $ _GET [ ‘id’ ] ;
$ res = mysqli_query ( “SEÇ * id = $ id ” ) ;
Tek fark, $ id değişkeninin etrafında tek bir tırnak işareti olmamasıdır. Bu güvenlik açığından yararlanmak için bir saldırgan aşağıdaki sorguyu gönderebilir:
http://[host]/?id=0 or 1=1
Dolayısıyla, veritabanına yapılan asıl sorgu şu şekilde görünür:
SEÇ * id = 0 veya 1 = 1
Buradaki yaygın hata, mysqli_real_escape_string()işlevi “id” parametresinde kullanmaktır. Dizede tırnak işareti veya başka herhangi bir özel simge yoktur. Bu nedenle bu işlev herhangi bir veriden kaçmaz ve SQL enjeksiyonu gerçekleşir. Bu durumda intval, girdi dizgisinin beklenen değişken türüne karşılık geldiğinden emin olmak için işlev kullanılmalıdır