PORTSWIGGER WEB SECURITY - CSRF (CROSS SITE REQUEST FORGERY) LAB ÇÖZÜMLERİ

CSRF (Siteler Arası İstek Sahteciliği), kimliği doğrulanmış kullanıcının web sayfasında istenmeyen faaliyetler gerçekleştirmesine olanak tanıyan bir web güvenliği zafiyetidir. Web uygulaması, gönderilen isteğin hangi kaynaktan, ne şekilde geldiğini doğrulamadığında ortaya çıkmaktadır. Genellikle üç farklı durumda bu zafiyet test edilebilir.

• Farklı kullanıcılara ait izinlerin değiştirilmesi veya kullanıcının parola yenilemesi durumlarında.
• Gönderilen istek üzerinde kullanıcıları doğrulamak adına kullanılan cookie bilgileri yer aldığında.
• İstek üzerinde saldırganın kontrol veya tahmin edebildiği parametreler yer aldığında.

İstemci tarafında gerçekleşen CSRF zafiyeti, saldırganın bir eylemi, hedef aldığı kullanıcıya istemsizce yaptırmasına neden olmaktadır.

Bu çalışmada bahsedilen CSRF zafiyeti için tüm laboratuvar çözümleri ele alınmıştır. Keyifli okumalar..

CSRF zafiyetinde, saldırganın hedef kullanıcıya istemsizce yaptırmayı istediği eylem için, web uygulamasında ele alınan başlık üzerinden bir exploit kodu hazırlaması gerekmektedir. Bunun için Burp Suite aracının Pro versiyonunda otomatik bir exploit kodu oluşturabiliriz ancak Community versiyonu kullandığımız için bu exploit kodunu manuel olarak oluşturacağız. (Bazı laboratuvarlarda exploit kodu tanımlanmıştır.)

Lab 1: CSRF vulnerability with no defenses

Bu web sayfasında, kullanıcı login olduktan sonra email adresini değişebilmektedir. Bu email güncelleme uygulaması herhangi bir denetim söz konusu olmadığı için zafiyet barındırmaktadır. Zararlı bir HTML formu kullanarak CSRF saldırısı gerçekleştireceğiz ve bu sayede email adresinin hedef kullanıcı tarafından değişmesini sağlayacağız.

Burp Suite aracı aktiften laba erişim öncesi tanımlanmış wiener:peter hesabıyla login olalım. Karşımıza email adresini güncelleyebileceğimiz bir panel çıkmaktadır. Email adresimizi random bir mail adresiyle (hacker@gmail.com) değişelim.

Email adresini değişmek için gönderilen isteği HTTP history bölümünden görebiliriz.

CSRF saldırısı gerçekleştirebilmek için zararlı bir HTML formu oluşturmamız ve bunu kullanıcıya göndermemiz gerekmektedir. Gerçek bir senaryo olmadığı için laboratuvarda yer alan exploit sunucusunu kullanıyoruz. Laboratuvarda kullanmamız için bize bir zararlı kod tanımlanmıştır ancak bu kullanıcı tarafından da oluşturulabilir. Örneğin sayfanın kaynak kodu incelendiğinde email güncelleme panelinin ne şekilde oluşturulduğu görülmektedir. Bunu baz alarak <form method=”POST” action=”https://acc41f841fa85bfec07801740065004e.web-security-academy.net/my-account/change-email”> <input type=”hidden” name=”email” value=”hacker2@gmail.com”> </form> <script> document.forms[0].submit(); </script> şeklinde zararlı bir HTML formu oluşturuyoruz. İstek post metoduyla gönderildiği için burada istek metodunu POST olarak belirttik. action parametresine, web sayfasında ki email güncelleme adresini ve value parametresine değişmek istediğimiz yeni email adresini tanımladık. script tagları arasında kullandığımız kod satırı ise otomatik olarak submit butonuna tıklanmasını sağlamak içindir.

Exploit sunucusuna giderek Body input alanında, oluşturduğumuz zararlı HTML formunu Store edelim. Ardında exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

En sonunda exploiti görüntüleyerek (View exploit), wiener kullanıcısının email adresinin hacker2@gmail.com olarak değiştiğini doğrulayabiliriz.

Lab 2: CSRF where token validation depends on request method

Bazı web uygulamaları, istek metodu olarak POST yöntemi kullanıldığında token bilgisini doğru bir şekilde kontrol eder ancak GET yöntemi kullanıldığında kontrol etmeyebilir. Bu durumda bir CSRF saldırısı gerçekleştirmek isteniyorsa istek yöntemi GET olarak değiştirilmelidir.

Bu web sayfası CSRF saldırılarını engellemek için bir token bilgisi kullanmaktadır ve kontrolü istek metoduna göre sağlamaktadır. Dolayısıyla istek metodunu değişerek bir CSRF saldırısı gerçekleştireceğiz.

Burp Suite aracı aktiften laba erişim öncesi tanımlanmış wiener:peter hesabıyla login olalım. Karşımıza çıkan email güncelleme panelinde email adresimizi random bir mail adresiyle (hacker@gmail.com) değişelim.

HTTP history bölümünden email adresini değişmek için gönderilen isteği incelediğimizde bir csrf token bilgisinin yer aldığını göreceğiz.

Bu csrf parametresine random bir değer (894651) verip isteği send ettiğimizde CSRF token bilgisinin geçersiz olduğunu bildiren bir hata mesajı almaktayız.

Ancak sağ tıklayıp istek metodunu GET olarak değiştikten sonra isteği send ettiğimizde bu durumu bypass edebildiğimiz görülecektir. Zafiyetin varlığını tespit ettiğimize göre exploitation aşamasına geçebiliriz.

Şimdi bir CSRF saldırısı gerçekleştireceğiz. Bunun için zararlı bir HTML formu oluşturmamız ve bunu kullanıcıya göndermemiz gerekmektedir. Gerçek bir senaryo olmadığı için laboratuvarda yer alan exploit sunucusunu kullanıyoruz. Laboratuvarda kullanmamız için bize bir zararlı kod tanımlanmıştır ancak bu kullanıcı tarafından da oluşturulabilir. Örneğin sayfanın kaynak kodu incelendiğinde email güncelleme panelinin ne şekilde oluşturulduğu görülmektedir. Bunu baz alarak <form method=”GET” action=”https://ac1c1f5a1e3ac744c0ef0da200a4007c.web-security-academy.net/my-account/change-email”> <input type=”hidden” name=”email” value=”hacker3@gmail.com”> </form> <script> document.forms[0].submit(); </script> şeklinde zararlı bir HTML formu oluşturuyoruz. Web uygulaması post metodu üzerinden CSRF saldırısına önlem aldığı için burada istek metodunu GET olarak belirttik. action parametresine, web sayfasında ki email güncelleme adresini ve value parametresine değişmek istediğimiz yeni email adresini tanımladık. script tagları arasında kullandığımız kod satırı ise otomatik olarak submit butonuna tıklanmasını sağlamak içindir.

Exploit sunucusuna giderek Body input alanında, oluşturduğumuz zararlı HTML formunu Store edelim. Ardında exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

En sonunda exploiti görüntüleyerek (View exploit), wiener kullanıcısının email adresinin hacker3@gmail.com olarak değiştiğini doğrulayabiliriz.

Lab 3: CSRF where token validation depends on token being present

Bazı web uygulamaları, token bilgisini doğru şekilde kontrol eder ancak token bilgisinin yer aldığı parametre kaldırıldığı zaman bu durumu gözden kaçırabilir. Saldırgan token bilgisini içeren tüm parametreyi (yalnızca değerini değil) kaldırarak bir CSRF saldırısı gerçekleştirebilir.

Bu web sayfası CSRF saldırılarını engellemek için bir token bilgisi kullanmaktadır ancak token bilgisini içeren parametrenin kaldırılmasıyla bu engel aşılabilmektedir. Dolayısıyla istek üzerinde yer alan csrf parametresini silerek bir CSRF saldırısı gerçekleştireceğiz.

Burp Suite aracı aktiften laba erişim öncesi tanımlanmış wiener:peter hesabıyla login olalım. Karşımıza çıkan email güncelleme panelinde email adresini random bir email adresiyle (hacker@gmail.com) değişelim.

HTTP history bölümünden email adresini değişmek için gönderilen isteği incelediğimizde bir csrf token bilgisinin yer aldığını göreceğiz.

Bu csrf parametresine random bir değer (54656) verip isteği send ettiğimizde CSRF token bilgisinin geçersiz olduğunu bildiren bir hata mesajı almaktayız.

Ancak bu csrf parametresini delete edip isteği send ettiğimizde bu durumu bypass edebildiğimiz görülecektir. Zafiyetin varlığını tespit ettiğimize göre exploitation aşamasına geçebiliriz.

Şimdi bir CSRF saldırısı gerçekleştireceğiz. Bunun için zararlı bir HTML formu oluşturmamız ve bunu kullanıcıya göndermemiz gerekmektedir. Gerçek bir senaryo olmadığı için laboratuvarda yer alan exploit sunucusunu kullanıyoruz. Laboratuvarda kullanmamız için bize bir zararlı kod tanımlanmıştır ancak bu kullanıcı tarafından da oluşturulabilir. Örneğin sayfanın kaynak kodu incelendiğinde email güncelleme panelinin ne şekilde oluşturulduğu görülmektedir. Bunu baz alarak <form method=”POST” action=”https://ac581fa61eb53377c0a9194c00b800b3.web-security-academy.net/my-account/change-email”> <input type=”hidden” name=”email” value=”hacker4@gmail.com”> </form> <script> document.forms[0].submit(); </script> şeklinde zararlı bir HTML formu oluşturuyoruz. İstek post metoduyla gönderildiği için burada istek metodunu POST olarak belirttik. action parametresine, web sayfasında ki email güncelleme adresini ve value parametresine değişmek istediğimiz yeni email adresini tanımladık. script tagları arasında kullandığımız kod satırı ise otomatik olarak submit butonuna tıklanmasını sağlamak içindir.

Exploit sunucusuna giderek Body input alanında, oluşturduğumuz zararlı HTML formunu Store edelim. Ardında exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

En sonunda exploiti görüntüleyerek (View exploit), wiener kullanıcısının email adresinin hacker4@gmail.com olarak değiştiğini doğrulayabiliriz.

Lab 4: CSRF where token is not tied to user session

Bazı uygulamalar, token bilgisinin istekte bulunan kullanıcıya ait olup olduğunu doğrulamaz. Uygulamanın kendine ait bir jeton havuzu mevcuttur ve bu havuzda yer alan herhangi bir jeton yani token bilgisi kabul görmektedir. Böyle bir durumda, saldırgan kendi hesabıyla oturum açtıktan sonra geçerli bir token elde edebilir ve ardından bu token’ı CSRF saldırısı yapmak için kullanabilir.

Bu web sayfası CSRF saldırılarını engellemek için token bilgileri kullanmaktadır ancak token bilgisinin istekte bulunan kullanıcıya ait olup olmadığını doğrulamamaktadır. İstek üzerinde yer alan csrf parametresine, başka bir kullanıcının token değerini tanımlayarak bir CSRF saldırısı gerçekleştireceğiz.

Laba erişim öncesi tanımlanmış wiener:peter hesabıyla login olalım. Karşımıza çıkan email güncelleme panelinde random bir email adresi (wiener@hacker.ca) tanımlayalım ve Update ettikten sonra isteği burp ile yakalayalım.

Gönderilen isteği incelediğimizde csrf parametresi ile bir token bilgisinin kullanıldığını göreceğiz. Bu token değerini daha sonra carlos kullanıcısı için kullanacağımızdan isteği repeatera gönderelim. Bu csrf token’ları yalnızca bir defa kullanıldığı için isteği drop ediyoruz.

Şimdi gizli bir tarayıcı penceresi açarak carlos:montoya hesap bilgisiyle login olalım. Aynı anda iki hesabında aktif olması için gizli sekmeyi kullanıyoruz. Login olduktan sonra email güncelleme panelinde, random bir email adresi (carlos@hacker.ca) tanımlayalım ve Update ettikten sonra isteği burp ile yakalayalım.

Burada, wiener hesabında yaptığımız işlemleri carlos hesabında da yapmış olduk. Gönderilen isteği incelediğimizde aynı şekilde csrf parametresi ile bir token bilgisinin kullanıldığını görüyoruz. Bu isteği de repeatera gönderelim.

Şimdi wiener hesabında gönderdiğimiz istek üzerinde yer alan csrf token bilgisini, carlos hesabında gönderdiğimiz istek üzerinde yer alan csrf parametresine tanımlayalım. İsteği send ettiğimizde email adresinin başarıyla değiştiğini ve zafiyetin varlığını tespit etmiş olacağız.

Bundan sonrasında, daha önce olduğu gibi zararlı bir HTML formu oluşturarak CSRF saldırısı gerçekleştireceğiz. Bu HTML formunu oluştururken farklı olarak token bilgisine yer vereceğiz. csrf token bilgileri tek kullanımlık oldukları için carlos hesabından çıkış yapıp wiener kullanıcısıyla login olalım ve yeni bir email update isteği gönderelim. Oluşturacağımız zararlı HTML formu içerisinde, gönderilen bu yeni istek üzerinde ki token değerini kullanacağız.

Şimdi zararlı bir HTML formu oluşturacağız. Gerçek bir senaryo olmadığından zararlı formu hedef kullanıcıya göndermek için laboratuvarda yer alan exploit sunucusunu kullanıyoruz. Sayfanın kaynak kodu incelendiğinde email güncelleme panelinin ne şekilde oluşturulduğu görülmektedir. Bunu baz alarak <form method=”POST” action=”https://ac611fe71e8d43dfc1f4784000cc00af.web-security-academy.net/my-account/change-email”><input type=”hidden” name=”csrf” value=”8qof09I9ZgPBFboRb5t6yzBXvA7yaWp3”> <input type=”hidden” name=”email” value=”wiener@hacker.ca”></form> <script> document.forms[0].submit(); </script> şeklinde zararlı bir HTML formu oluşturuyoruz. İstek post metoduyla gönderildiği için burada istek metodunu POST olarak belirttik. action parametresine, web sayfasında ki email güncelleme adresini, birinci value parametresine csrf token değerini ve ikinci value parametresine değişmek istediğimiz yeni email adresini tanımladık. script tagları arasında kullandığımız kod satırı ise otomatik olarak submit butonuna tıklanmasını sağlamak içindir.

Exploit sunucusuna giderek Body input alanında, oluşturduğumuz zararlı HTML formunu Store edelim. Ardında exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

NOT: Zararlı kod store edildikten sonra exploit görüntülenerek (View exploit) email adresinin değiştiği doğrulanabilir.

Congratulations, you solved the lab!

Lab 5: CSRF where token is tied to non-session cookie

Web uygulamaları CSRF saldırılarını önlemek adına iki farklı framework (biri oturum kontrolü diğeri CSRF koruması için) kullanabilir. Bu iki framework birbirine entegre edilmediğinde ve denetimi tam olarak yapılmadığında, her ne kadar zor olsa da bu durumu istismar etmek bazen mümkün olmaktadır. Web sayfası, saldırganın tarafından hedef kullanıcının tarayıcısına cookie tanımlamasına izin veriyorsa saldırı gerçekleşmesi olasıdır. Böyle bir durumda, saldırgan kendi hesabıyla oturum açtıktan sonra geçerli bir token elde edebilir ve ardından bu token’ı CSRF saldırısı yapmak için kullanabilir.

Bu web sayfası CSRF saldırılarını engellemek için oturum açma aşamasını kontrol etmek adına birden fazla token değeri kullanmaktadır. Ancak bu token değerleri tam olarak entegre edilmemiştir. İstek üzerinde yer alan token değerlerinde değişiklikler yaparak zafiyetin varlığını tespit edeceğiz. Ardından zararlı bir HTML formu kullanarak CSRF saldırısı gerçekleştireceğiz.

Laba erişim öncesi tanımlanmış wiener:peter hesabıyla login olalım. Karşımıza çıkan email güncelleme panelinde random bir email adresi (wiener@hacker.ca) tanımlayalım ve Update edelim.

HTTP history bölümünden gönderilen isteği incelediğimizde, csrf ve csrfKey başlıkları altında iki farlı token değerinin kullanıldığını göreceğiz. Bu token değerlerini daha sonra carlos kullanıcısı için kullanacağımızdan isteği repeatera gönderelim.

İstek üzerinde session bilgisine random bir değer (asdfghj) tanımladığımızda oturumun kapatıldığını gözlemliyor olacağız. Bunu isteği send ettikten sonra follow redirection seçeneği ile doğrulayabiliriz.

Daha sonra csrfKey bilgisine random bir değer tanımlayıp isteği send ettiğimizde ise token değerinin geçersiz olduğunu bildiren bir hata mesajı almaktayız. Bu hata mesajı, csrfKey parametresinin oturuma tam anlamıyla bağlı olmadığını göstermektedir.

Şimdi gizli bir tarayıcı penceresi açarak carlos:montoya hesap bilgisiyle login olalım. Aynı anda iki hesabında aktif olması için gizli sekmeyi kullanıyoruz. Login olduktan sonra email güncelleme panelinde, random bir email adresi (carlos@hacker.ca) tanımlayalım ve Update edelim.

Burada, wiener hesabında yaptığımız işlemleri carlos hesabında da yapmış olduk. HTTP history bölümünden gönderilen isteği incelediğimizde, aynı şekilde csrf ve csrfKey başlıkları altında iki farlı token değerinin kullanıldığı görülecektir. Bu isteği de repeatera gönderelim.

Şimdi wiener hesabında gönderdiğimiz istek üzerinde yer alan csrf parametresindeki token bilgisini, carlos hesabında gönderdiğimiz istek üzerinde yer alan csrf parametresine tanımlayalım. İsteği send ettiğimizde email adresinin başarıyla değiştiğini ve zafiyetin varlığını tespit etmiş olacağız.

Zafiyetin varlığını tespit ettiğimize göre artık zararlı bir HTML formu oluşturabiliriz. Ancak öncesinde, orijinal tarayıcıda herhangi bir değer (arif1234) search edip gönderilen isteği inceleyelim. Search edilen değer Set-Cookie başlığında yer almaktadır ve herhangi bir csrf koruması söz konusu değildir. Bu bilgiyi kullanarak zararlı bir form oluşturacağız.

Zararlı HTML formunu oluştururken csrf - csrfKey token bilgilerine ve search edilen değerin yer aldığı Set-Cookie başlığına yer vereceğiz. Dolayısıyla wiener kullanıcısıyla login olalım ve yeni bir email update isteği gönderelim. Oluşturacağımız zararlı HTML formu içerisinde, gönderilen bu yeni istek üzerinde ki token değerlerini kullanacağız.

İlk olarak, csrfKey bilgisini hedef kullanıcıya göndermek için /?search=test%0d%0aSet-Cookie:%20csrfKey=gBqCeRlAyV9dzIpEvMjVWGI874jNWKlr şeklinde bir URL oluşturalım. Bu URL’i zararlı HTML formu içerisinde kullanacağız. Gerçek bir senaryo olmadığından zararlı formu hedef kullanıcıya göndermek için laboratuvarda yer alan exploit sunucusunu kullanıyoruz. Sayfanın kaynak kodu incelendiğinde email güncelleme panelinin ne şekilde oluşturulduğu ekranda görülmektedir. Bunu baz alarak <form action=”https://ac4f1f6f1ee7689ec08e155800e700b9.web-security-academy.net/my-account/change-email" method=”POST”>
<input required type=”hidden” name=”csrf” value=”GdZ5ALNJS6Hx1T2DasVEc4uSLSj6CvJ7”/>
<input type=”hidden” name=”email” value=”hacker5@gmail.com” />
</form>
<img src=”https://ac4f1f6f1ee7689ec08e155800e700b9.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=gBqCeRlAyV9dzIpEvMjVWGI874jNWKlr" onerror=”document.forms[0].submit()”> şeklinde zararlı bir HTML formu oluşturuyoruz. İstek post metoduyla gönderildiği için burada istek metodunu POST olarak belirttik. action parametresine, web sayfasında ki email güncelleme adresini, birinci value parametresine csrf token değerini ve ikinci value parametresine değişmek istediğimiz yeni email adresini tanımladık. script tagları arasında belirtilen URL adresi ile hedef kullanıcıya csrfKey token değerinin enjekte edilmesini sağlıyoruz. onerror=”document.forms[0].submit()” kod satırı ise otomatik olarak submit butonuna tıklanmasını sağlamak içindir ancak belirtilen URL adresi bulunamazsa çalıştırılacaktır.

Exploit sunucusuna giderek Body input alanında, oluşturduğumuz zararlı HTML formunu Store edelim. Ardında exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

NOT: Zararlı kod store edildikten sonra exploit görüntülenerek (View exploit) email adresinin değiştiği doğrulanabilir.

Congratulations, you solved the lab!

Lab 6: CSRF where token is duplicated in cookie

Bazı web uygulamaları csrf saldırılarını önlemek için ‘double submit’ tekniğini kullanmaktadır. Bahsedilen double submit yöntemi, gönderilen istek üzerinde iki parametrenin birbiriyle eşleşmesi yani doğrulanması amacıyla kullanılan bir tekniktir. Web sayfası herhangi bir cookie bilgisi içeriyorsa, saldırgan cookie bilgisinin kullanımını baz alarak hedef kullanıcıya yönelik bir CSRF saldırısı gerçekleştirebilir.

Bu web sayfası CSRF saldırılarını engellemek için ‘double submit’ yöntemini kullanmaktadır. Ancak bu teknik güvenli yapılandırılmamıştır. İstek üzerinde yer alan csrf cookie değerlerinde değişiklikler yaparak zafiyetin varlığını tespit edeceğiz. Ardından zararlı bir HTML formu kullanarak CSRF saldırısı gerçekleştireceğiz.

Laba erişim öncesi tanımlanmış wiener:peter hesabıyla login olalım. Karşımıza çıkan email güncelleme panelinde random bir email adresi (wiener@hacker.ca) tanımlayalım ve Update edelim.

HTTP history bölümünden gönderilen isteği incelediğimizde, aynı cookie değerine sahip farklı konumlarda tanımlanmış iki csrf parametresinin yer aldığını göreceğiz.

Herhangi bir csrf parametresine random bir değer (arif123) verip isteği send ettiğimizde CSRF token bilgisinin geçersiz olduğunu bildiren bir hata mesajı almaktayız. İstek gönderildiği zaman iki değer karşılaştırılıp doğrulanmaktadır. Bu nedenle hata mesajı aldık.

Sayfa üzerinde herhangi bir değer (arif1234) search edip gönderilen isteği inceleyelim. Search edilen değer Set-Cookie başlığında yer almaktadır ve herhangi bir csrf koruması söz konusu değildir. Bu bilgiyi kullanarak zararlı bir form oluşturacağız.

CSRF saldırısı için zararlı bir HTML formu oluşturmamız gerekmektedir. Zararlı HTML formunu oluştururken csrf token bilgisine ve search edilen değerin yer aldığı Set-Cookie başlığına yer vereceğiz. Dolayısıyla yeni bir email update isteği gönderelim. Oluşturacağımız zararlı HTML formu içerisinde, gönderilen bu yeni istek üzerinde ki token değerini kullanacağız.

Artık zararlı HTML formunu oluşturabiliriz. Gerçek bir senaryo olmadığından zararlı formu hedef kullanıcıya göndermek için laboratuvarda yer alan exploit sunucusunu kullanıyoruz. Sayfanın kaynak kodu incelendiğinde email güncelleme panelinin ne şekilde oluşturulduğu görülmektedir. Bunu baz alarak <form action=”https://aced1f591e732fbdc081170700020063.web-security-academy.net/my-account/change-email" method=”POST”>
<input required type=”hidden” name=”csrf” value=”pDTI9DNOVucSSeQW8qyDjmitWgm4wWgZ”/>
<input type=”hidden” name=”email” value=”hacker6@gmail.com” />
</form>
<img src=”https://aced1f591e732fbdc081170700020063.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=pDTI9DNOVucSSeQW8qyDjmitWgm4wWgZ" onerror=”document.forms[0].submit()”> şeklinde zararlı bir HTML formu oluşturuyoruz. İstek post metoduyla gönderildiği için burada istek metodunu POST olarak belirttik. action parametresine, web sayfasında ki email güncelleme adresini, birinci value parametresine csrf token değerini ve ikinci value parametresine değişmek istediğimiz yeni email adresini tanımladık. script tagları arasında belirtilen URL adresi ile hedef kullanıcıya csrf token değerinin enjekte edilmesini sağlıyoruz. onerror=”document.forms[0].submit()” kod satırı ise otomatik olarak submit butonuna tıklanmasını sağlamak içindir ancak belirtilen URL adresi bulunamazsa çalıştırılacaktır.

Exploit sunucusuna giderek Body input alanında, oluşturduğumuz zararlı HTML formunu Store edelim. Ardında exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

NOT: Zararlı kod store edildikten sonra exploit görüntülenerek (View exploit) email adresinin değiştiği doğrulanabilir.

Congratulations, you solved the lab!

Lab 7: CSRF where Referer validation depends on header being present

Bazı web uygulamaları, CSRF saldırılarına engellemek amacıyla gönderilen isteğin, uygulamanın kendi domain adresinden gelip gelmediğini doğrulamak için HTTP Referer başlığını kullanır. Referer başlığının varlığı tam kontrol edilmediğinde, saldırgan CSRF istismar kodunu, Referer başlığını bypass etmeye yönelik oluşturabilir ve saldırı gerçekleştirebilir.

Bu web sayfası, CSRF saldırılarını engellemek adına Referer başlığını kullanmaktadır. Referer başlığını, oluşturacağımız zararlı HTML formu üzerinde META etiketlerini kullanarak bypass edeceğiz ve CSRF saldırısı gerçekleştireceğiz.

NOT: Farklı bypass yöntemleride mevcuttur ancak en kolayı META etiketlerini kullanmaktır.

Laba erişim öncesi tanımlanmış wiener:peter hesabıyla login olalım. Karşımıza çıkan email güncelleme panelinde random bir email adresi (wiener@hacker.ca) tanımlayalım ve Update edelim.

HTTP history bölümünden gönderilen isteği incelediğimizde, bir Referer parametresiyle yönlendirme yapıldığını göreceğiz.

Yönlendirme yapılan domain adresini .com olarak değişip isteği send ettiğimizde hata mesajı almaktayız.

Fakat Referer parametresini tümüyle silip isteği send ettiğimizde herhangi bir hata almamaktayız. Dolayısıyla oluşturacağımız zararlı form üzerinde Referer başlığını bypass etmeye yönelik bir komut satırı kullanabiliriz.

Zafiyetin varlığını tespit ettiğimize göre artık zararlı bir HTML formu oluşturabiliriz. Gerçek bir senaryo olmadığından zararlı formu hedef kullanıcıya göndermek için laboratuvarda yer alan exploit sunucusunu kullanıyoruz. Sayfanın kaynak kodu incelendiğinde email güncelleme panelinin ne şekilde oluşturulduğu görülmektedir. Bunu baz alarak <html><head>
<meta name=”referrer” content=”no-referrer”>
</head><body>
<form action=”https://acd21fff1f951d54c00218ea005e004e.web-security-academy.net/my-account/change-email" method=”POST”>
<input type=”hidden” name=”email” value=”hacker7@gmail.com” />
</form>
<script>document.forms[0].submit();</script></body></html> şeklinde zararlı bir HTML formu oluşturuyoruz. Burada, Referer başlığını atlatmak adına meta etiketleriyle <meta name=”referrer” content=”no-referrer”> şeklinde bir komut satırı kullandık. İstek post metoduyla gönderildiği için burada istek metodunu POST olarak belirttik. action parametresine, web sayfasında ki email güncelleme adresini ve value parametresine değişmek istediğimiz yeni email adresini tanımladık. script tagları arasında kullandığımız kod satırı ise otomatik olarak submit butonuna tıklanmasını sağlamak içindir.

Exploit sunucusuna giderek Body input alanında, oluşturduğumuz zararlı HTML formunu Store edelim. Ardında exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

NOT: Zararlı kod store edildikten sonra exploit görüntülenerek (View exploit) email adresinin değiştiği doğrulanabilir.

Congratulations, you solved the lab!

Lab 8: CSRF with broken Referer validation

Bazı web uygulamaları, CSRF saldırılarına engellemek amacıyla gönderilen isteğin, uygulamanın kendi domain adresinden gelip gelmediğini doğrulamak için HTTP Referer başlığını kullanır. Ancak uygulamanın kendi domain adresi, Referer başlığında yer alan değer içerisinde herhangi bir şekilde mevcut ise doğrulanmış kabul edilir. Dolayısıyla saldırgan, içerisinde uygulamanın domain adresini barındıran bir alt domain kullandığında zafiyetin varlığını tespit etmiş olacaktır.

Bu web sayfası, gönderilen istek üzerinde Referer parametresinin uygulamaya ait domain adresini içerip içermediğini kontrol etmektedir ancak kontrolü yalnızca bundan ibarettir. Referer parametresinde içerisinde uygulamaya ait domain adresini barındıran bir URL tanımlayarak zafiyetin varlığını tespit edeceğiz. Ardından zararlı bir HTML formu kullanarak CSRF saldırısı gerçekleştireceğiz.

Laba erişim öncesi tanımlanmış wiener:peter hesabıyla login olalım. Karşımıza çıkan email güncelleme panelinde random bir email adresi (wiener@hacker.ca) tanımlayalım ve Update edelim.

HTTP history bölümünden gönderilen isteği incelediğimizde, bir Referer parametresiyle yönlendirme yapıldığını göreceğiz.

Yönlendirme yapılan URL adresini https://ariari.com/ olarak değişip isteği send ettiğimizde hata mesajı almaktayız.

Fakat URL adresini, https://ariari.com/?ac641f011fa08e5dc0263b4500db0009.web-security-academy.net içerisinde uygulamanın kendi domain adresini barındıracak şekilde send ettiğimizde hata almamaktayız. Web uygulaması, dizenin herhangi bir yerinde kendi domain adresini içeren Referer bilgisini kabul etmektedir.

Zafiyetin varlığını tespit ettiğimize göre artık zararlı bir HTML formu oluşturabiliriz. Gerçek bir senaryo olmadığından zararlı formu hedef kullanıcıya göndermek için laboratuvarda yer alan exploit sunucusunu kullanıyoruz. Sayfanın kaynak kodu incelendiğinde email güncelleme panelinin ne şekilde oluşturulduğu görülmektedir. Bunu baz alarak <form action=”https://ac641f011fa08e5dc0263b4500db0009.web-security-academy.net/my-account/change-email" method=”POST”>
<input type=”hidden” name=”email” value=”hacker8@gmail.com” />
</form>
<script>
history.pushState(“”, “”, “/?ac641f011fa08e5dc0263b4500db0009.web-security-academy.net”)
document.forms[0].submit();
</script> şeklinde zararlı bir HTML formu oluşturuyoruz. İstek post metoduyla gönderildiği için burada istek metodunu POST olarak belirttik. action parametresine, web sayfasında ki email güncelleme adresini ve value parametresine değişmek istediğimiz yeni email adresini tanımladık. history.pushState fonksiyonuyla daha önce test ettiğimiz domain adresiyle beraber uygulamanın domain adresinin bir alt domain olarak yer almasını sağlıyoruz. script tagları arasında kullandığımız kod satırı ise otomatik olarak submit butonuna tıklanmasını sağlamak içindir.

Exploit sunucusuna giderek Body input alanında, oluşturduğumuz zararlı HTML formunu Store edelim. Ardında exploiti kurbana teslim ettikten (Deliver exploit to victim) sonra laboratuvarı çözmüş olacağız.

NOT: Birçok tarayıcı çalıştırılan sorgu dizesini Referer başlığından kaldırarak bir güvenlik önlemi almaktadır. Bu davranışı geçersiz kılmak ve URL’in tam olarak çalıştırıldığından emin olmak adına zararlı kod store edilmeden önce HEAD alanında Referrer-Policy: unsafe-url başlığı eklenmelidir.

Congratulations, you solved the lab!