Merhabalar,
Bugünkü konuda Portswigger firmasının kendini geliştirmek isteyenler için oluşturmuş olduğu Web Security Academy içerisinde bulunan CSRF where token validation depends on token being present adlı labın çözümünü anlatacağım.
İlgili lab linki: Lab: CSRF where token validation depends on token being present | Web Security Academy
Daha önce çözdüğümüz diğer lablar gibi bunda da isim üzerinden çıkarımlar yapabiliriz. Token doğrulamasının, token'ın varlığına bağlı olması durumu. Aslında her lab küçük farklılıklar ile temelde aynı durum, yalnızca bypass yöntemlerimiz değişiyor. Bir önceki konuyu okumayanlar buradan ulaşabilirler -> Web Security Academy | CSRF - Lab 2
Bir önceki labda olduğu gibi CSRF açığının web uygulamasındaki kullanıcıların email değiştirme fonksiyonunda ortaya çıktığını biliyoruz. Bu yüzden doğrudan web uygulamasına eriştikten sonra login olarak devam edebiliriz.
Her zaman olduğu gibi güvenlik testlerimizi gerçekleştirmek adına örnek bir mail giriyoruz ve giden requesti yakalayıp incelemeye başlıyoruz.
Öncelikle başlangıç noktamızı referans almamız gerçekleştireceğimiz testler için mühim, çünkü başarılı olup olmadığımızı anlayabilmemiz için uygulamanın normalde nasıl çalıştığını ve tepki verdiğini bilmeliyiz. Gelen bu talebi ilettiğimizde uygulama 302 Found Redirect veriyor.
Referans noktamızı belirlediğimize göre bir önceki konuda yaptığımız gibi request metodunu değiştirerek denemeye çalıştığımızda 404 döndüğünü görüyoruz.
Aynı şekilde verilen csrf değerini değiştirmeye çalıştığımız zaman doğrulama yapmakta ve gene response olarak 404 dönmektedir.
Bu lab farklı olarak body'de giden csrf parametresini silmeyi deneyebiliriz. Böylece back-end sistemi her zaman bir csrf parametresinin gelip gelmediğini bekliyormu yoksa yalnızca gelmesi durumunda bir doğrulmamamı (validation) gerçekleştiriyor anlayabiliriz.
Yukarıdaki resimde görüldüğü üzere body içerisindeki csrf parametresini tamamen silmemiz durumunda uygulama csrf parametresinin var olup olmadığını sorgulamıyor ve mail değiştirme işlemimiz normalde olduğu gibi başarılı bir şekilde 302 Found Redirect veriyor. Burp Suite Pro ile CSRF PoC oluşturduğumuz zaman kodumuz şu şekilde olacaktır.
Daha önceki konularda gösterdiğim gibi exploit server kısmına gidiyoruz. Sunucuya kodumuzu upload etmek için Store seçiyor ve daha sonra seneryomuzdaki ilgili victim'a kendi upload ettiğimiz siteye yönlendiriyoruz.
İşlemleri benim gibi uyguladığınız taktirde sorunsuz bir şekilde labı başarı ile çözdüğümüzü görüyoruz.
Okuduğunuz için teşekkür ederim, işinize yaradıysa ne mutlu bana. Anlamadığınız veya takıldığınız bir yer olursa sormaktan çekinmeyin, elimden geldiğince yardımcı olmaya çalışırım.
Bugünkü konuda Portswigger firmasının kendini geliştirmek isteyenler için oluşturmuş olduğu Web Security Academy içerisinde bulunan CSRF where token validation depends on token being present adlı labın çözümünü anlatacağım.
İlgili lab linki: Lab: CSRF where token validation depends on token being present | Web Security Academy
Daha önce çözdüğümüz diğer lablar gibi bunda da isim üzerinden çıkarımlar yapabiliriz. Token doğrulamasının, token'ın varlığına bağlı olması durumu. Aslında her lab küçük farklılıklar ile temelde aynı durum, yalnızca bypass yöntemlerimiz değişiyor. Bir önceki konuyu okumayanlar buradan ulaşabilirler -> Web Security Academy | CSRF - Lab 2
Bir önceki labda olduğu gibi CSRF açığının web uygulamasındaki kullanıcıların email değiştirme fonksiyonunda ortaya çıktığını biliyoruz. Bu yüzden doğrudan web uygulamasına eriştikten sonra login olarak devam edebiliriz.
Her zaman olduğu gibi güvenlik testlerimizi gerçekleştirmek adına örnek bir mail giriyoruz ve giden requesti yakalayıp incelemeye başlıyoruz.
Öncelikle başlangıç noktamızı referans almamız gerçekleştireceğimiz testler için mühim, çünkü başarılı olup olmadığımızı anlayabilmemiz için uygulamanın normalde nasıl çalıştığını ve tepki verdiğini bilmeliyiz. Gelen bu talebi ilettiğimizde uygulama 302 Found Redirect veriyor.
Referans noktamızı belirlediğimize göre bir önceki konuda yaptığımız gibi request metodunu değiştirerek denemeye çalıştığımızda 404 döndüğünü görüyoruz.
Aynı şekilde verilen csrf değerini değiştirmeye çalıştığımız zaman doğrulama yapmakta ve gene response olarak 404 dönmektedir.
Bu lab farklı olarak body'de giden csrf parametresini silmeyi deneyebiliriz. Böylece back-end sistemi her zaman bir csrf parametresinin gelip gelmediğini bekliyormu yoksa yalnızca gelmesi durumunda bir doğrulmamamı (validation) gerçekleştiriyor anlayabiliriz.
Yukarıdaki resimde görüldüğü üzere body içerisindeki csrf parametresini tamamen silmemiz durumunda uygulama csrf parametresinin var olup olmadığını sorgulamıyor ve mail değiştirme işlemimiz normalde olduğu gibi başarılı bir şekilde 302 Found Redirect veriyor. Burp Suite Pro ile CSRF PoC oluşturduğumuz zaman kodumuz şu şekilde olacaktır.
HTML:
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://SIZIN-LAB-ID.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="fahrettin@altay.tht" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>Daha önceki konularda gösterdiğim gibi exploit server kısmına gidiyoruz. Sunucuya kodumuzu upload etmek için Store seçiyor ve daha sonra seneryomuzdaki ilgili victim'a kendi upload ettiğimiz siteye yönlendiriyoruz.
İşlemleri benim gibi uyguladığınız taktirde sorunsuz bir şekilde labı başarı ile çözdüğümüzü görüyoruz.
Okuduğunuz için teşekkür ederim, işinize yaradıysa ne mutlu bana. Anlamadığınız veya takıldığınız bir yer olursa sormaktan çekinmeyin, elimden geldiğince yardımcı olmaya çalışırım.
