Enjeksiyon Açıkları

Enjeksiyon açıkları, özellikle SQL enjeksiyon, web uygulamalarında ortak bir açıktır. Çok fazla tipte
enjeksiyon tipi vardır: SQL, LDAP, Xpath, XSLT, HTML, XML, OS komutları ile enjeksiyon ve daha
fazlası Ve 2009’da Yeni Enjesiyon Açıkları Çıkmış Tabi bunlar için Geniş Bir Çalışma Yapmak Lazım..

Enjeksiyon, kullanıcı kaynaklı veri içerisinde bir komut veya sorgunun bir bölümünün yorumlayıcıya
gönderilmesiyle gerçekleştirilir. Saldırganlar, ustalıkla planlanmış komutlar aracılığıyla, yorumlayıcıya
çalışabilir komutlar göndererek özel veri alanlarına erişim sağlarlar. Enjeksiyon açıkları, uygulama
üzerinden saldırganların isteğine bağlı olarak, oluşturma, okuma, güncelleştirme veya silme izinlerinden
herhangi birini verir. En kötü durum senaryosu, bu açıklardan yararlanan saldırganın tamamen uygulama
ve önemli sistem bileşenleri ile güvenlik duvarı katmanına erişebilmesidir.



Kulacıların Yaptığı Hatalardan Çıkan Zayıflıklar..
Eğer kullanıcı, onaylanmış veya kodlanmış verinin dışındaki bir veriyi yorumlayıcıya gönderiyorsa,
uygulama saldırıya açıktır. Örnek için, aşağıdaki kullanıcı kaynaklı dinamik sorguları kontrol ediniz:

PHP:
$sql = "SELECT * FROM table WHERE id = ’" . $_REQUEST[’id’] . "’";
Java:
String query = "SELECT user_id FROM user_data WHERE user_name = ’" +
req.getParameter("userID") + "’ and user_password = ’" + req.getParameter("pwd") +"’";




Burada amaç, kullanıcı verisi değiştirilmeden, uygulama aracılığıyla yorumlayıcıya komut veya sorgu
gönderilip gönderilmediğini kontrol etmektir.

Otomatik Yapılan Yaklaşımlar: Çoğu zayıflık tarama aracı enjeksiyon problemlerini tarar, Özellikle de
SQL Enjeksiyonunu. Statik analiz araçları, güvenli olmayan yorumlayıcı API’lerini taramak için oldukça
kullanışlıdır, fakat sıklıkla doğrulanmış veya kodlanmış koruma yöntemlerine karşı zayıflıkları
yakalayamazlar. Eğer uygulama 501 veya 500 dahili sunucu hatası veya detaylı veritabanı hataları
veriyorsa, otomatik araçlar ile önlem alınabilir, fakat kod hala risk altında olabilir. Otomatik araçlar
LDAP/XML enjeksiyonları ile /XPAth Enjeksiyonlarını saptayabilir.
Elle Yapılan Yaklaşımlar: Bu yorumlayıcıya gönderilen kodlar ile çok etkili ve tam bir kontrol sağlar. Bu
işlemin eleştirilecek yanı ise Güvenli API’lerin kullanımının, kodlanmış ve doğrulanmış bölgeler için kontrol
edilmelidir. Bu test işlemi son derece fazla zaman alacaktır ve düşük kapsamlı olacaktır, çünkü
uygulamaların büyüklüğü nedeniyle saldırı yüzeyi çok geniş olacaktır.



Security

Yorumlayıcıların kullanımından kaçınılmalıdır. Eğer yorumlayıcıya istek gönderecekseniz, enjeksiyondan
kaçınmanın anahtar yöntemi API’lerin kullanımıdır, Örneğin güçlü sorgu ve ilişkili nesne haritalama
kütüphaneleri (ORM) kullanılabilir.
Bu arayüzler, bütün verileri gözden geçirir veya bu geçişleri gerektirmeyebilir. Önemli olan arayüzlerin
güvenliğine karşın, problem saldırıları saptamak için belirli bir metodun olmamasıdır.
Yorumlayıcıların kullanımı tehlikelidir, öyle ki bu kullanımın önemi, ek dikkat gerektirir:
● Girilen verilerin doğrulanması: Bunun için, öncelikle gelen verilerin uzunluğu, tipi, sözdizimi ve
yerine göre kullanım kurallarını kontrol edildikten sonra verinin görüntülenebileceği veya kayıt
edilebileceği, standart bir doğrulama mekanizması kullanılır. Bunun için "Bilginin iyi niyetli olduğu
kabul edildi" doğrulama stratejisi kullanılmalıdır. Potansiyel kötü niyetli veriler reddedilerek,
sistemden sterilize edilmelidir. Unutulmaması gereken bir nokta hata mesajlarının içeriği
saldırganın işine yarayacak bilgi içermemelidir.
● API’lerde güçlü sorgu parametre tipleri kullanılmalıdır. Depolanmış prosedürler çağrıldığında,
işaretçilerin yerine güçlü tipteki sorgular koyulmalıdır.
● En düşük ayrıcalık verilmeli. Veritabanına ve diğer arka plan uygulamalarına bağlanıldığında en
düşük imtiyaz ile bağlanılmalıdır.
● Detaylı hata mesajlarından kaçınılmalı. Saldırganın kullanabileceği detaylı hata mesajlarından
kaçınılmalıdır.
● Kayıt edilmiş prosedürler kullanılmalıdır. Çünkü genellikle SQL enjeksiyonda bu yöntem
güvenlidir. Bunun yanında, dikkatli bir şekilde enjeksiyon yapılabilir (Örneğin exec() kullanılarak
veya kayıtlı prosedürleri içeren argümanlar birbirine bağlanması ile...)
● Dinamik sorgu arayüzlerini kullanmayın. (Örneğin mysql_query() veya benzerleri...)
● Basit kaçış fonksiyonlarını kullanmayın. Örneğin PHP’nin addslashes() veya yerine koyma
fonksiyonu str_replace("’", "’’"). Bu fonksiyonlar saldırganlar için zayıflık oluşturacaktır. PHP için,
MySQL kullanılıyorsa mysql_real_escape_string() kullanılır veya tercihan PDO kullanılabilir,
böylece escape gerektirmez.
● Basit escape mekanizması kullanıldığı zaman , basit escape fonksiyonları, escape tablo
isimleri olmamalıdır. Tablo isimleri SQL’e uygun isimlerde olmalı ve bu kullanıcı kaynaklı veri
girişleri ile ilgili olmamalıdır.
● Varsayılan hata çıktılarını izlenmesi : Çoğunlukla sisteme gelen verilerin kodu çözümlenmeli ve
ardından kullanılan dahili yazılım ile gösterilmeden önce kontrol edilmelidir. Elbette ki
uygulamanız iki kez girilen benzer veri girişlerinin kodu çözümlenemeyebilecektir. Bu şekilde
tehlikeli veri girişleri ile hatalar kullanılarak, kontrol işlemini gerçekleştiren beyaz liste şemaları
atlatılabilir.
Kullanılan dil için belirli öneriler:
● Java EE- Güçlü tipte PreparedStatement kullanılmalı veya ORM’lerdeki Hibernate veya spring...