Injection zafiyetleri genellikle kullanıcıdan alınan, kontrol edilmeyen ya da önlem alınmayan verilerin komut olarak çalıştırılması ya da sorguya dahil edilmesi yüzünden oluşan zafiyetlerdir. İstatistiklere göre, şirketlerin % 28’i bu zafiyete maruz kalmaktadır.
Bu güvenlik açığı aşağıdaki saldırı vektörlerine bölünmüştür:
- SQL, LDAP, XPath sorguları aracılığıyla enjeksiyon
- İşletim Sistemlerindeki komutlarla enjeksiyon
- XML ayrıştırma yoluyla enjeksiyon
- SMTP başlıkları aracılığıyla enjeksiyon
Saldırgan bu vektörleri (farklı bir veri göndererek sistemde komut çalıştırabilir) kullanarak hem bir hesaba hem de erişmemesi gereken bu kaynağın tüm istemci veri tabanına erişim sağlayabilir. SQL veri tabanı türüne bağlı olarak farklı söz dizimi kullanarak veri tabanıyla çalışmak için yalnızca özel karakterler ve ek operatörler kullanarak hak yükseltme zafiyetini kullanmış olur. Sistemde ki etkinliğini artırır, hatta bütün organizasyona sızabilir. Bu zafiyet kullanıcıdan gelen verinin filtrelenmemesi veya kötü kodlardan temizlenmemesi sonucu ortaya çıkar.
Örnekle açıklayacak olursak:
Örnek olarak verileri şöyle girelim:
-Kullanıcı alanına, şekilde gördüğümüz gibi kırmızı bir okla işaretlenmiş olan $username değişkeninin yerine Hilmi değerini girelim.
-Geçiş alanına, $password değişkeninin yerini alacak mavi bir okla işaretlenmiş 1234 değerini girelim.
Bu SQL sorgusu başlatıldıktan sonra veritabanında bu kullanıcının sırasıyla tüm bilgileriyle birlikte bulunacağı bir arama yapılacak, yetkilendirme sayfasında olumlu bir yanıt alıp başarılı bir şekilde yetkilendireceğiz.
Şimdi bir saldırganın bu durumda neler yapabileceğine bakalım:
Burada saldırgan bir hamle yaparak kullanıcı yöneticisini hedef alır. Neye giriş yaptığına daha yakından bakalım:
– Kullanıcı alanına, görebildiğimiz gibi kırmızı bir okla işaretlenmiş olan $username değişkeninin yerini alacak admin değeri girdi.
– Şifre alanına $parola değişkeninin yerini alacak (mavi bir okla işaretlenmiş) ‘OR 1 = 1 — değerini girdi,
$password değişkenine bu tür veriler girildiğinde ne olduğuna bir bakalım; Kullanıcı adı kısmına tek tırnak işareti yardımı ile ‘admin’ değeri girildi. Verilen değişkeni kapatarak AND operatöründen sonra şifreyi boş bırakıyoruz (yukarıdaki resimde görülebilir). Sonra ‘OR 1 =1 –‘ değerimizden OR kelimesine gidiyoruz, bu, değişkenimizi önceki alıntı ile kapattığımız için SQL sorgusunda zaten işlevini yürütecek olan OR operatörünü çağırdığımızı söylüyor. OR 1 = 1—ifadesinde 1 = 1 TRUE olduğu için bize gerçek bir değer döndürdüğünü söylüyor.
Şifre alanına ‘OR 1 = 1 — değerini girdikten sonra SQL sorgumuzun nasıl dönüştürüldüğüne aşağıdaki resme bakalım:
Umarız yukarıda ki resme bakılarak şimdi ne olduğu açıkça görülmüştür… Buna göre SQL ek bir koşul aldı, yani bu sorgu, doğru şifre girilmemiş olsa bile kullanıcı yöneticisi ile kullanıcı için bir dize döndürecek. Sorguya OR 1 = 1 değeri eklenerek, bu her zaman doğru (TRUE) olarak değerlendirilir (çünkü 1 her zaman 1’e eşittir). OR TRUE gerçek kullanıcı tarafından girileceği için başka ne olursa olsun, otomatik olarak doğru sonucu alırsınız. Bu kullanıcı, parolayı bilmese bile artık yönetici olarak yetkilendirilecektir. Böyle bir zafiyet varsa, o zaman aşağıdaki resimdeki gibi bir durumda meydana gelebilir…
Şifre alanına ‘; DROP TABLE users– böyle bir değer girilip sonra sunucuya gönderin, kullanıcının uygulamamıza girdiği şeyi filtrelemezsek o zaman genellikle kullanıcı verilerimizi veritabanımızda kullanabilir. (Drop Table daima hedef tablonun içerdiği indeksleri, kuralları, tetikleri ve kısıtları kaldırır.)
Arama yaparken de bu gibi bir durumu düşünebiliriz. Sistemdeki bir kullanıcıyı arayarak bu örneği ele alalım:
Gördüğümüz gibi, buradaki SQL sorgusu, veritabanımızın kullanıcı tablosundan hangi kullanıcının çekilmesi gerektiğini söyleyen $id değişkenini giriliyor. Buna göre bu ID ile bulunan kullanıcının adını ve soy adını bize verecektir.
Bir ID değeri girip ve ne olacağını görelim:
Ve böylece alanımıza id=1 girdikten sonra, admin adında ve adminoglu soyadında bir kullanıcı var olduğunu görürüz. Görünüşe göre bu yanlış olabilir. Ancak saldırgan bu alana özel karakterler girmeye karar verirse ve eğer sistemimizin kullanıcısının girdiği şeyi filtrelemezsek büyük problemler olacağı aşikârdır. Örneğin % özel karakterini girelim ve ne olacağını görelim:
Yukarıdaki resimden de tahmin edebileceğiniz gibi, girdiğimiz % özel karakteri var olan her şeyi listeleme yaptığı için burada tüm kullanıcılar gösterildi. Bir SQL sorgusu LIKE operatörü çağrılırken % işaretinin bir sütunda belirtilen bir kelimeyi aramak için bir WHERE deyiminde kullanıldığını ve “sıfır, bir veya birden çok karakteri” temsil ettiğini hatırlayalım.
Ve şimdi bir sonraki örnekte, uygulamanın kendisi tarafından yürütülen mevcut sorguya, şifrenin sonuncusu yerine kullanıcının adı ve soyadına ek olarak görüntülenmesini istediğimiz sorgumuza ekleyeceğimiz, dizeleri birleştiren UNION operatörünü kullanalım. Buna göre çıkan sonucu karşımızda görüyoruz. Tabloda sıradan bir sorgulama ve ona veri çıkışı yapıldıktan sonra UNION‘dan sonraki sorgu ile ilgili veriler görünecektir, yani Select username, password From users bize kullanıcıların adı ve şifrelerini getirecektir.
Böyle bir güvenlik açığı varsa, dosya sisteminden çeşitli şeyler yüklemek için LOAD_FILE komutunu kullanmayı bile deneyebilirsiniz. Buda bize dosya içeriğinin okunup metin olarak döndürülmesini sağlar. Aşağıdaki sorgu örneğinde olduğu gibi:
Bu saldırı türünde aşağıda yazılan ve daha bir çok farklı parametler ile deneme-yanılma yoluyla yapıldığını unutmayalım.
”Or’=’Or”
anything’ OR ‘x’=’x
1’or’1’=’1
‘ or 1=1 or ”=’
” or 1=1 or “”=”
‘ OR ”=’
” OR ”=”
‘OR”=’
hey’ or 1=1–
”Or 1 = 1′
‘ or 1=1–
or 1=1–
” or 1=1–
or 1=1–……..
Owasp bu tip zafiyetlerin tespit edilmesinin en iyi yöntemlerinin kaynak kod analizi ve sızma testlerini zamanında yaptırmayı tavsiye ediyor.
