8 Eylül 2016 Perşembe

Web Uygulaması Güvenliği - Cross Site Scripting

Cross site scripting, saldırganın hedef web sitesini ziyaret eden tarayıcılar üzerinde komut çalıştırdığı saldırılara verilen isimdir. Saldırganlar cross-site-scripting saldırıları ile web sayfasını ziyaret eden müşterilerin hesap bilgilerini hatta bilgisayarlarını ele geçirebilir, sayfayı ziyaret eden tarayıcıları başka bir sayfaya yönlendirebilir veya sayfanın görünümünü değiştirebilir. Cross site scripting zafiyetleri başka zafiyetler ile birleştiğinde çok daha tehlikeli hale gelmektedir.

Resim https://www.incapsula.com/web-application-security/cross-site-scripting-xss-attacks.html'den alınmıştır.

Cross Site Scripting üç kategoriye ayrılır :
  1. Reflected XSS 
  2. Dom Based XSS 
  3. Stored XSS 
XSS çoğunlukla web uygulamaların hatalı ya da eksik yapılandırılması ile oluşur. Web uygulaması kendisine gönderilen veriyi filtrelemeden kabul etmesiyle meydana gelir. En zararlı XSS türü Stored XSS’tir, çünkü uygulamaya gönderilen komut kaynak kodda kalıcı olarak yer eder. 

Stored XSS, web formlarında sıkça karşımıza çıktığından bugün bir Stored XSS zafiyetini istismar edeceğim. Bunun için hedef olarak DVWA (Damn Vulnerable Web Application)'ı kullanacağım. DVWA kurmakla uğraşmamak isteyenler üzerinde bir çok zafiyet barındıran Metasploitable 2 sanal makinesini Rapid7'ın kendi sitesinden indirebilirler. 

https://information.rapid7.com/metasploitable-download.html

Yapmanız gereken tek şey metasploitable sanal makinesini bir sanallaştırma programına tanıtıp, çalıştırmak olacaktır. Makinenin internet ayarını 'host-only' yapmanızı tavsiye ederim çünkü internete açıldığı takdirde başkaları tarafından da hacklenebilir. 

Eğer Metasploitable'ın yani, kurban makinenizin IP adresini öğrenmek isterseniz terminale ifconfig yazmanız yeterli olacaktır.

Metasploitable'ın default yönetici kullanıcı adı 'msfadmin' ve parolası ise aynı şekilde 'msfadmin'dir.

Herhangi bir tarayıcı ile port 80 üzerinden Metasploitable'ın IP adresini ziyaret ettiğinizde DVWA seçeneğine tıklayarak wbe uygulamasını görüntüleyebilirsiniz. Önce uygulamaya giriş yapmanız gerekir.


DVWA default kullanıcı adı 'admin' parolası ise 'password' dür.

Giriş yaptıktan sonra 'DVWA Security' sayfasına gidip security ayarını 'low' olarak ayarlarsanız uygulama güvenlik önlemlerini tamamen kaldıracaktır. 'Medium' ayarında bazı güvenlik önlemleri alınmış olacak, 'High' ayarında ise uygulama bütün güvenlik önlemlerini alacaktır. 
'XSS Stored' sayfasına gidecek olursanız Stored XSS açığı barındıran bir POST formu ile karşılaşacaksınız.

İstismar

Bahsettiğim POST formunun kaynak kodu:

Bir POST formunda XSS açığı var mı/yok mu' yu kontrol etmenin en sık kullanılan yolu aşağıdaki gibi bir komut ile tarayıcıya pop-up penceresi açmaktır.


Web uygulamasına gönderilen komut, uygulamayı ziyaret eden tarayıcı üzerinde komut çalıştırmış ve kullanıcıya bir mesaj göstermiştir.

Stored XSS'de gönderilen komut, sayfa her ziyaret edildiğinde tekrar çalıştırılır ve aynı pop-up ile karşılaşırız. Eğer bu bir Reflected XSS açığı olsaydı, bu mesaj sadece bir tarayıcıya bir kez gösterilecekti. Komutun tekrar çalıştırılması için aynı komutun tekrar forma girilmesi gerekecekti.

Gerçek ortamda saldırgan kullanıcıya pop-up penceresi göstermektense kullanıcının çerezlerini veya kullanıcı giriş bilgilerini çalabilir. Aslına bakarsanız, kullanıcının bilgisayarını tamamen ele geçirmek mümkündür. Aynı saldırıyı güvenlik ayarı 'High' da gerçekleştirecek olursak, sonuç aşağıdaki gibidir:


Uygulama arka tarafta XSS komutlarını tanımış ve onları tarayıcıların çalıştırmayacağı şekilde değiştirmiştir. Böylelikle komut içeren yorum kaynak koda yansımasına rağmen zararlı değildir.

Yanlış yapılandırılmış uygulamada(security=low) XSS komutu göndermekte kullanılabilecek html karakterine dair herhangi bir filtreleme yoktur.

if(isset($_POST['btnSign'])){ $message = trim($_POST['mtxMessage']); $name = trim($_POST['txtName']); // Mesaj girdisini temizle. $message = stripslashes($message); $message = mysql_real_escape_string($message); // Isim girdisini temizle. $name = mysql_real_escape_string($name); $query = "INSERT INTO guestbook (comment,name) VALUES ('$message','$name');"; $result = mysql_query($query) or die('' . mysql_error() . '' ); } ?>

Başarılı olan saldırıda name alanına girilen girdiler 'name' ve 'message' değişkenlerinin yerini aldılar ve XSS komutu tarayıcı tarafından olduğu gibi algılandı. Doğru yapılandırılan uygulamada (security=high), kaynak kod aşağıdaki gibidir. 
if(isset($_POST['btnSign'])){ $message = trim($_POST['mtxMessage']); $name = trim($_POST['txtName']); // Mesaj girdisini temizle. $message = stripslashes($message); $message = mysql_real_escape_string($message); $message = htmlspecialchars($message); // Isim girdisini temizle. $name = stripslashes($name); $name = mysql_real_escape_string($name); $name = htmlspecialchars($name); $query = "INSERT INTO guestbook (comment,name) VALUES ('$message','$name');"; $result = mysql_query($query) or die('' . mysql_error() . '' ); } ?>
Uygulama / > < ' ; ! - " = & { ( )} gibi XSS komutu göndermekte kullanılabilecek html karakterlerini filtrelemiş ve saldırı başarısız olmuştur. İki uygulamaya da aynı XSS saldırısı gerçekleştirildiğinde:

Yanlış yapılandırılmış uygulamanın kaynak kodunda XSS komutu olduğu gibi dururken,


Doğru yapılandırılmış uygulamanın kaynak kodunda XSS komutu filtrelenmiştir.


Tabii ki, her uygulama farklıdır ve bazen başka önlemler de almak gerekir. Yazılımda açık bulunmasa da riski minimuma indirmek için web uygulamasında 'X-XSS Protection' başlıklarının kullanılması gerekir.

Bir sonraki bölüm: Cross Site Request Forgery
on 08 Eylül by Berk Cem Göksel |   Edit