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 is not tied to user session adlı labın çözümünü anlatacağım.
İlgili lab linki: Lab: CSRF where token is not tied to user session | Web Security Academy
Bir önceki lablarda olduğu gibi lab ismi bize bir çok şeyi anlatıyor: Token'in kullanıcı oturumuna bağlı olmadığı CSRF, yani seneryodaki ilgili web uygulamasında aslında gerçekten alınmaya çalışılmış bir CSRF önemli mevcut fakat hala yeterince güvenli değil (insecure). Nedenini konunun devamında açıklıyor olacağım ve ayrıca önceki konuyu okumayanlar buradan ulaşabilirler -> Web Security Academy | CSRF - Lab 3
Bir önceki lab 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.
Uygulamayı anlamak adına bir referans noktası belirlememiz için öncelikle uygulamanın normal koşullarda nasıl tepki verdiğini bilmemiz gerek, böylece başlangıç noktamıza göre davranış analizinde bulunabiliriz. Bu talebi olduğu gibi iletirsek 302 Found Redirect aldığımız öğreniyoruz ve güvenlik testlerimize geçiyoruz.
Bir önceki çözümleri uygulamaya çalıştığımız durumları göze alırsak; parametreyi direk silmeyi denediğimizde "Missing parameter 'csrf'" hatası alıyoruz. Http metodunu değiştirdiğimizde ise "Not Found" hatası vermekte. Değeri değiştirirsek bu sefer "Invalid CSRF token" hatası alıyoruz. Bütün önceki edindiğimiz deneyimlerimizin burada işe yaramadığını görüyoruz.
Uygulama davranışını baştada anlattığım gibi analiz etmek açısından requestimiz üzerinde hiçbir değişiklik yapmadan tekrar göndermeye çalışıyorum ve sonucun gene 400 Bad Request olduğunu fark ediyorum.
En başta çıkarımda bulunduğumuz lab ismindeki ipucundan gidecek olursak Back-end tarafındaki uygulamanın kısmen düzgün bir CSRF önlemi aldığını söyleyebiliriz fakat yeterli değil. Denediğimiz yöntemlerin dışında uygulamanın nasıl çalıştığını düşünecek olursak bizim için generate (oluşturduğu) ettiği token'ın yalnızca bizim tarafından kullanılabilir olması gerekiyor. Aksi taktirde uygulama kendi oluşturduğu geçerli token havuzundaki CSRF tokenlarından biri ile çalışırsa saldırgan uygulama tarafından aldığı geçerli bir token ile gene saldırı yapabilir.
Geçerli tokenımızı hesabımız sayfasından developer konsolunu açarak elde edebiliriz.
Diğer lablarda olduğu gibi Burp Suite Pro ile CSRF PoC kodumuzu alıyoruz ve developer konsolundan elde ettiğimiz değer ile düzenliyoruz.
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.
Anlatımlarımda doğrudan lab çözümünü göstermek yerine saldırganın düşünme metodolojisini ve uygulama analizini göstermeye çalıştım ki bu labların çözülme amacında yalnızca çözmüş olmak için çözmek değil bu lablar vesilesi ile kendi düşünme metodolojilerinizi geliştirip bakış açısını kazanabilmek ve zafiyeti doğada nasıl arayacağınızı ve exploit edeceğinizi anlamak.
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 is not tied to user session adlı labın çözümünü anlatacağım.
İlgili lab linki: Lab: CSRF where token is not tied to user session | Web Security Academy
Bir önceki lablarda olduğu gibi lab ismi bize bir çok şeyi anlatıyor: Token'in kullanıcı oturumuna bağlı olmadığı CSRF, yani seneryodaki ilgili web uygulamasında aslında gerçekten alınmaya çalışılmış bir CSRF önemli mevcut fakat hala yeterince güvenli değil (insecure). Nedenini konunun devamında açıklıyor olacağım ve ayrıca önceki konuyu okumayanlar buradan ulaşabilirler -> Web Security Academy | CSRF - Lab 3
Bir önceki lab 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.
Uygulamayı anlamak adına bir referans noktası belirlememiz için öncelikle uygulamanın normal koşullarda nasıl tepki verdiğini bilmemiz gerek, böylece başlangıç noktamıza göre davranış analizinde bulunabiliriz. Bu talebi olduğu gibi iletirsek 302 Found Redirect aldığımız öğreniyoruz ve güvenlik testlerimize geçiyoruz.
Bir önceki çözümleri uygulamaya çalıştığımız durumları göze alırsak; parametreyi direk silmeyi denediğimizde "Missing parameter 'csrf'" hatası alıyoruz. Http metodunu değiştirdiğimizde ise "Not Found" hatası vermekte. Değeri değiştirirsek bu sefer "Invalid CSRF token" hatası alıyoruz. Bütün önceki edindiğimiz deneyimlerimizin burada işe yaramadığını görüyoruz.
Uygulama davranışını baştada anlattığım gibi analiz etmek açısından requestimiz üzerinde hiçbir değişiklik yapmadan tekrar göndermeye çalışıyorum ve sonucun gene 400 Bad Request olduğunu fark ediyorum.
En başta çıkarımda bulunduğumuz lab ismindeki ipucundan gidecek olursak Back-end tarafındaki uygulamanın kısmen düzgün bir CSRF önlemi aldığını söyleyebiliriz fakat yeterli değil. Denediğimiz yöntemlerin dışında uygulamanın nasıl çalıştığını düşünecek olursak bizim için generate (oluşturduğu) ettiği token'ın yalnızca bizim tarafından kullanılabilir olması gerekiyor. Aksi taktirde uygulama kendi oluşturduğu geçerli token havuzundaki CSRF tokenlarından biri ile çalışırsa saldırgan uygulama tarafından aldığı geçerli bir token ile gene saldırı yapabilir.
Geçerli tokenımızı hesabımız sayfasından developer konsolunu açarak elde edebiliriz.
Diğer lablarda olduğu gibi Burp Suite Pro ile CSRF PoC kodumuzu alıyoruz ve developer konsolundan elde ettiğimiz değer ile düzenliyoruz.
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" method="POST">
<input type="hidden" name="email" value="fahrettin@altay.tht" />
<input type="hidden" name="csrf" value="iTEQaBq0gylZq94svAcRfeCknHF0qQ67" />
<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.
Anlatımlarımda doğrudan lab çözümünü göstermek yerine saldırganın düşünme metodolojisini ve uygulama analizini göstermeye çalıştım ki bu labların çözülme amacında yalnızca çözmüş olmak için çözmek değil bu lablar vesilesi ile kendi düşünme metodolojilerinizi geliştirip bakış açısını kazanabilmek ve zafiyeti doğada nasıl arayacağınızı ve exploit edeceğinizi anlamak.
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.
