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 request method adlı labın çözümünü anlatacağım.
İlgili lab linki: Lab: CSRF where token validation depends on request method | Web Security Academy
Bir önceki lab çözümünden farklı olarak lab ismine baktığımızda ne gibi bir içerikle karşılacağımızı kestirmek mümkün. Http request metoduna göre token doğrulaması. Bir önceki konumdan hatırlayacak olursak requestimiz POST metodu ile gitmişti. O zaman bu sefer diğer http metodlarını kullanmayı deneyebiliriz. Bir önceki konuyu okumayanlar buradan ulaşabilirler -> Web Security Academy | CSRF - Lab 1
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.
Bu labın bir öncekinden farkı olarak zafiyetin giden request metodunda olduğunu biliyoruz. Bunun sebebi genellikle web uygulamarında POST metodu bilindiği üzere veri göndermek için kullanılmaktadır fakat GET'in asıl amacı veri göndermek değildir. Bu yüzden GET metodu üzerinden veri göndermeyi denediğimizde CSRF bypass durumu oluşabilmektedir.
Aşağıdaki görseldeki gibi basitçe giden pakete sağ tıklayarak Change request method dediğimiz zaman Burp bizim için metodu GET olarak uygun şekilde düzenliyor.
Bunu yaptığımızda bizden POST metodu ile veri bekleyen back-end web uygulaması GET ile veri almayı beklemediği için üzerinde CSRF tokeni olup olmadığını incelemiyor. Bu yüzden parametreden csrf kısmını tamamen silebiliriz. Sildikten sonra giden talebin yanıtının başarılı olduğunu görebiliriz.
Görüldüğü üzere 302 redirect aldık, follow redirection diyerek csrf tokensiz mail değiştirebildiğimizi artık kanıtlamış olduk. Bundan sonra CSRF PoC oluşturarak exploitimizi victim'a gönderebiliriz.
Bunun için kullandığım PoC bu şekilde;
Bir önceki lab 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 request method adlı labın çözümünü anlatacağım.
İlgili lab linki: Lab: CSRF where token validation depends on request method | Web Security Academy
Bir önceki lab çözümünden farklı olarak lab ismine baktığımızda ne gibi bir içerikle karşılacağımızı kestirmek mümkün. Http request metoduna göre token doğrulaması. Bir önceki konumdan hatırlayacak olursak requestimiz POST metodu ile gitmişti. O zaman bu sefer diğer http metodlarını kullanmayı deneyebiliriz. Bir önceki konuyu okumayanlar buradan ulaşabilirler -> Web Security Academy | CSRF - Lab 1
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.
Bu labın bir öncekinden farkı olarak zafiyetin giden request metodunda olduğunu biliyoruz. Bunun sebebi genellikle web uygulamarında POST metodu bilindiği üzere veri göndermek için kullanılmaktadır fakat GET'in asıl amacı veri göndermek değildir. Bu yüzden GET metodu üzerinden veri göndermeyi denediğimizde CSRF bypass durumu oluşabilmektedir.
Aşağıdaki görseldeki gibi basitçe giden pakete sağ tıklayarak Change request method dediğimiz zaman Burp bizim için metodu GET olarak uygun şekilde düzenliyor.
Bunu yaptığımızda bizden POST metodu ile veri bekleyen back-end web uygulaması GET ile veri almayı beklemediği için üzerinde CSRF tokeni olup olmadığını incelemiyor. Bu yüzden parametreden csrf kısmını tamamen silebiliriz. Sildikten sonra giden talebin yanıtının başarılı olduğunu görebiliriz.
Görüldüğü üzere 302 redirect aldık, follow redirection diyerek csrf tokensiz mail değiştirebildiğimizi artık kanıtlamış olduk. Bundan sonra CSRF PoC oluşturarak exploitimizi victim'a gönderebiliriz.
Bunun için kullandığım PoC bu şekilde;
HTML:
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://SIZIN-LAB-ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="fahrettin@altay.tht" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>Bir önceki lab 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.
Son düzenleme:
