breakpoint
Team Member
- Katılım
- 12 Nis 2024
- Mesajlar
- 6
- Tepkime puanı
- 14
- Puanları
- 3
Merhaba, bu yazıda Cross Site Request Forgery(CSRF) atağına karşı geliştirilmiş olan CSRF Token kontrollerindeki potansiyel zafiyetler ve nasıl atlatılabilecekleri üzerinde duracağız. Öncelikle CSRF'i kısaca hatırlayalım.
Bir siteye giriş yapıldığında, o sitede oturum(session) sağlanmış olur ve tarayıcımızda bu oturum bilgileri saklanır. İşte bu oturumda gerekli kontroller sağlanmadığında, saldırgan sanki o sitede bir kullanıcıymış gibi istek gönderebilir. Örneğin ilgili kullanıcının e-posta, kullanıcı adı gibi kimlik bilgileri değiştirilebilir. Burada sosyal mühendisliğin büyük bir önemi bulunmaktadır, çünkü ilgili isteğin gönderilebilmesi için belirli bir düzeyde kullanıcı etkileşimine ihtiyaç vardır.
CSRF Token'lar ise saldırganlar tarafından tahmin edilemediği için popüler savunma yöntemlerinden birisidir. Böylece artık kullanıcı herhangi bir istek gönderdiğinde, mevcut CSRF Token'ı da bu isteğin içinde bulunmalıdır, aksi takdirde bu işlem gerçekleşmeyecektir. Ancak hiçbir uygulama kusursuz değildir, CSRF Token doğrulamasında bulunabilen bazı hatalar bu doğrulamanın işlevini yitirmesine sebep olabilir.
Örnekleri PortSwigger Web Security Academy Labları üzerinden anlatıyor olacağız. Gelin ilk örneğimize göz atalım.
1. İstek Metodu Üzerinden Yapılan Kontroller
Lab#1
Hesabımıza giriş yapalım ve e-postamızı değiştirelim. İlgili isteği Burp Suite uygulamamızda takip edelim ve üzerinde değişiklikler yapabilmek için Repeater'a gönderelim.
Karşımıza çıkan POST request'te CSRF Token'ı değiştirdiğimizde "Invalid CSRF token" hatasını alıyoruz. İstek metodunu değiştirelim ve GET metodunu kullanalım.
Hatada email parametresini girmediğimizi belirtiyor. email parametresini de girelim.
Görüldüğü üzere GET metodunda CSRF token belirtmeden de işlemi gerçekleştirebildik. Burada her istek metodu için doğrulama yapılabilirdi, veya da doğrulama istek metodu değil de farklı bir yöntemle sağlanabilirdi.
Sıra bu işlemi kendi sunucumuzda yapmakta. Bunu da sayfaya bir img etiketi ekleyerek, kaynağını da emaili değiştirecek bir url olacak şekilde belirterek çözebiliriz. Örnek payload aşağıdaki gibidir.
Buradan sonra gerekli olan tek şey kullanıcının sayfamızı ziyaret etmesi. Sosyal mühendislik işte tam da burada devreye giriyor. Deliver to Victim butonuna tıkladığımızda lab da çözülmüş oluyor.
2. Mevcut CSRF Parametresi Üzerinden Yapılan Kontroller
Lab#2
Tekrar bize verilen kullanıcı adı ve şifre ile hesaba giriş yapalım ve e-posta adresimizi değiştirelim.
İlgili isteği Burp Suite aracında kontrol ediyoruz. CSRF token'ı değiştirmeye çalıştığımızda "Invalid CSRF token" mesajıyla karşılaşıyoruz.
CSRF token'ı ve csrf parametresini sildiğimizde ise e-posta adresimizi değiştirebildiğimizi görüyoruz. Uygulama burada CSRF parametresi verilmediği durum için bir kontrol yapmamış. Hata da bundan dolayı kaynaklanıyor.
Exploit sunucumuzda body bölümüne aşağıdaki örnekteki gibi bir payload yazabiliriz. Kurban sayfayı ziyaret ettiğinde otomatik olarak POST isteği gönderecek ve e-posta adresini değiştirecektir.
View exploit'e tıkladığımızda e-posta adresimizin değiştiğini teyit edelim.
Store ile exploiti kaydedip sayfamızı ilgili kullanıcıya(kurbana) gönderdiğimizde(Deliver exploit to victim) lab'ı çözmüş oluyoruz.
3. Kullanıcıdan bağımsız CSRF Tokenlar
Lab#3
Şimdiki uygulamamız ise CSRF tokenları bir havuzda tutuyor ve bu havuzdaki tokenları kabul ediyor. Lab'da bize verilen iki hesaptan herhangi birine girelim ve e-posta adresimizi değiştirelim. Burp Suite'de ise ilgili isteğin arasına girelim. Bunun için aracımız Intercept is On konumunda olmalı.
CSRF tokenimizi kopyalayalım ve not edelim. İlgili isteği Drop butonuyla düşürelim. Şu an elimizde bulunan token uygulamadaki doğrulamanın yanlış yapılandırılmasından dolayı diğer kullanıcılarda da kabul görecektir. Bunu diğer hesaba giriş yapıp e-posta adresinizi değiştirirken not ettiğimiz CSRF token'ı girerek gözlemleyebiliriz. Artık uygulamadaki mantık hatasını öğrendiğimiz için biz doğrudan exploit sunucumuza gidelim ve örnekteki payload'u kullanalım. Burada önemli olan kısım ilgili isteğin düşürülmesi çünkü her e-posta değişikliğinde CSRF token rastgele yeni bir değer alacaktır.
Store ile exploitimizi kaydedelim ve kurbana yollayalım, böylece lab'ı çözmüş oluyoruz.
4. Oturumdan Bağımsız Olarak Farklı Çerezde Saklanan CSRF Tokenlar
Lab#4
Son uygulamamızda ise arama fonksiyonunun hatalı yapılandırılması sonucunda CSRF token kontrolünü atlatabileceğiz.
Lab'da verilen kimlik bilgileriyle giriş yapalım ve e-posta adresimizi bu konu için son kez değiştirmeyi deneyelim. Burp Suite'de isteği kontrol edelim ve csrfKey, session çerezleriyle csrf parametresini not edelim. Oturumdan çıkalım ve diğer hesaba geçelim. Not ettiğimiz çerezlerden sadece session değerinin değiştiğini gözlemleyelim. Burada aynı csrfKey çerezi ve csrf parametresiyle e-postamızı değiştirebiliyoruz.
Peki bu bizim ne işimize yarar? Biz şu ana kadar exploit sayfamızda sadece csrf parametresini kontrol edebiliyorduk. Çerezi nasıl kontrol edebiliriz? İşte burada uygulamanın başka bir zafiyeti ortaya çıkıyor. Sitenin ana sayfasında bir arama yaptığımızda, dönen yanıt aşağıdaki gibidir.
Burada ilgi çekici kısım yanıttaki Set-Cookie header'ıdır. Şimdi arama bölümünde çeşitli manipülasyonu yaparak kendi çerezimizi kurbanın tarayıcısında set edebiliriz. Exploit sunucumuza geçelim ve örnekteki payload'u kullanalım.
Bu payload'da bazı noktalara göz atalım. Sorguladığmız terim "asd" nin ardından %0d%0a değerini kullandık. Bu değer HTTP isteklerinde her satır sonunda bulunan CRLF yani \r\n değeridir. Yeni satıra geçtikten sonra kendi csrfKey değerimizi kullanmak için Set-Cookie başlığını belirtiyoruz. Ardından SameSite=None çerezi ile de siteler arası çerez erişimi de sağlanmış olur. Ardından form ile istek gönderilir ve kurbanın e-posta adresi bizim sağladığımız değerler ile değiştirilmiş olur. İlgili exploiti Store ile kaydedip kurbana gönderdiğimizde lab da çözülmüş oluyor.
Bu yazıda çeşitli CSRF token kontrollerindeki bazı hatalardan bahsettik. Umarım faydalı olmuştur. Bir sonraki yazımızda görüşmek üzere!
Bir siteye giriş yapıldığında, o sitede oturum(session) sağlanmış olur ve tarayıcımızda bu oturum bilgileri saklanır. İşte bu oturumda gerekli kontroller sağlanmadığında, saldırgan sanki o sitede bir kullanıcıymış gibi istek gönderebilir. Örneğin ilgili kullanıcının e-posta, kullanıcı adı gibi kimlik bilgileri değiştirilebilir. Burada sosyal mühendisliğin büyük bir önemi bulunmaktadır, çünkü ilgili isteğin gönderilebilmesi için belirli bir düzeyde kullanıcı etkileşimine ihtiyaç vardır.
CSRF Token'lar ise saldırganlar tarafından tahmin edilemediği için popüler savunma yöntemlerinden birisidir. Böylece artık kullanıcı herhangi bir istek gönderdiğinde, mevcut CSRF Token'ı da bu isteğin içinde bulunmalıdır, aksi takdirde bu işlem gerçekleşmeyecektir. Ancak hiçbir uygulama kusursuz değildir, CSRF Token doğrulamasında bulunabilen bazı hatalar bu doğrulamanın işlevini yitirmesine sebep olabilir.
Örnekleri PortSwigger Web Security Academy Labları üzerinden anlatıyor olacağız. Gelin ilk örneğimize göz atalım.
1. İstek Metodu Üzerinden Yapılan Kontroller
Lab#1
Hesabımıza giriş yapalım ve e-postamızı değiştirelim. İlgili isteği Burp Suite uygulamamızda takip edelim ve üzerinde değişiklikler yapabilmek için Repeater'a gönderelim.
Karşımıza çıkan POST request'te CSRF Token'ı değiştirdiğimizde "Invalid CSRF token" hatasını alıyoruz. İstek metodunu değiştirelim ve GET metodunu kullanalım.
Hatada email parametresini girmediğimizi belirtiyor. email parametresini de girelim.
Kod:
http://{hedef_site}/my-account/[email protected]Görüldüğü üzere GET metodunda CSRF token belirtmeden de işlemi gerçekleştirebildik. Burada her istek metodu için doğrulama yapılabilirdi, veya da doğrulama istek metodu değil de farklı bir yöntemle sağlanabilirdi.
Sıra bu işlemi kendi sunucumuzda yapmakta. Bunu da sayfaya bir img etiketi ekleyerek, kaynağını da emaili değiştirecek bir url olacak şekilde belirterek çözebiliriz. Örnek payload aşağıdaki gibidir.
HTML:
<img src="http://{hedef_site}/my-account/[email protected]"Buradan sonra gerekli olan tek şey kullanıcının sayfamızı ziyaret etmesi. Sosyal mühendislik işte tam da burada devreye giriyor. Deliver to Victim butonuna tıkladığımızda lab da çözülmüş oluyor.
2. Mevcut CSRF Parametresi Üzerinden Yapılan Kontroller
Lab#2
Tekrar bize verilen kullanıcı adı ve şifre ile hesaba giriş yapalım ve e-posta adresimizi değiştirelim.
İlgili isteği Burp Suite aracında kontrol ediyoruz. CSRF token'ı değiştirmeye çalıştığımızda "Invalid CSRF token" mesajıyla karşılaşıyoruz.
CSRF token'ı ve csrf parametresini sildiğimizde ise e-posta adresimizi değiştirebildiğimizi görüyoruz. Uygulama burada CSRF parametresi verilmediği durum için bir kontrol yapmamış. Hata da bundan dolayı kaynaklanıyor.
Exploit sunucumuzda body bölümüne aşağıdaki örnekteki gibi bir payload yazabiliriz. Kurban sayfayı ziyaret ettiğinde otomatik olarak POST isteği gönderecek ve e-posta adresini değiştirecektir.
HTML:
<form id="autosubmit" action="https://{hedef_site}/my-account/change-email" enctype="text/plain" method="POST">
<input name="email" type="hidden" value="[email protected]" />
<input name="csrf" type="hidden" value="0QWXcjO6OVmNSXU8w8jwrr5dFXXSKz9D" />
<input type="submit" value="Submit Request" />
</form>
<script>
document.getElementById("autosubmit").submit();
</script>View exploit'e tıkladığımızda e-posta adresimizin değiştiğini teyit edelim.
Store ile exploiti kaydedip sayfamızı ilgili kullanıcıya(kurbana) gönderdiğimizde(Deliver exploit to victim) lab'ı çözmüş oluyoruz.
3. Kullanıcıdan bağımsız CSRF Tokenlar
Lab#3
Şimdiki uygulamamız ise CSRF tokenları bir havuzda tutuyor ve bu havuzdaki tokenları kabul ediyor. Lab'da bize verilen iki hesaptan herhangi birine girelim ve e-posta adresimizi değiştirelim. Burp Suite'de ise ilgili isteğin arasına girelim. Bunun için aracımız Intercept is On konumunda olmalı.
CSRF tokenimizi kopyalayalım ve not edelim. İlgili isteği Drop butonuyla düşürelim. Şu an elimizde bulunan token uygulamadaki doğrulamanın yanlış yapılandırılmasından dolayı diğer kullanıcılarda da kabul görecektir. Bunu diğer hesaba giriş yapıp e-posta adresinizi değiştirirken not ettiğimiz CSRF token'ı girerek gözlemleyebiliriz. Artık uygulamadaki mantık hatasını öğrendiğimiz için biz doğrudan exploit sunucumuza gidelim ve örnekteki payload'u kullanalım. Burada önemli olan kısım ilgili isteğin düşürülmesi çünkü her e-posta değişikliğinde CSRF token rastgele yeni bir değer alacaktır.
HTML:
<form id="autosubmit" action="https://{hedef_site}/my-account/change-email" method="POST">
<input name="email" type="hidden" value="[email protected]" />
<input name="csrf" type="hidden" value="0QWXcjO6OVmNSXU8w8jwrr5dFXXSKz9D" />
<input type="submit" value="Submit Request" />
</form>
<script>
document.getElementById("autosubmit").submit();
</script>Store ile exploitimizi kaydedelim ve kurbana yollayalım, böylece lab'ı çözmüş oluyoruz.
4. Oturumdan Bağımsız Olarak Farklı Çerezde Saklanan CSRF Tokenlar
Lab#4
Son uygulamamızda ise arama fonksiyonunun hatalı yapılandırılması sonucunda CSRF token kontrolünü atlatabileceğiz.
Lab'da verilen kimlik bilgileriyle giriş yapalım ve e-posta adresimizi bu konu için son kez değiştirmeyi deneyelim. Burp Suite'de isteği kontrol edelim ve csrfKey, session çerezleriyle csrf parametresini not edelim. Oturumdan çıkalım ve diğer hesaba geçelim. Not ettiğimiz çerezlerden sadece session değerinin değiştiğini gözlemleyelim. Burada aynı csrfKey çerezi ve csrf parametresiyle e-postamızı değiştirebiliyoruz.
Peki bu bizim ne işimize yarar? Biz şu ana kadar exploit sayfamızda sadece csrf parametresini kontrol edebiliyorduk. Çerezi nasıl kontrol edebiliriz? İşte burada uygulamanın başka bir zafiyeti ortaya çıkıyor. Sitenin ana sayfasında bir arama yaptığımızda, dönen yanıt aşağıdaki gibidir.
Burada ilgi çekici kısım yanıttaki Set-Cookie header'ıdır. Şimdi arama bölümünde çeşitli manipülasyonu yaparak kendi çerezimizi kurbanın tarayıcısında set edebiliriz. Exploit sunucumuza geçelim ve örnekteki payload'u kullanalım.
HTML:
<form action="https://{hedef_site}/my-account/change-email" method="POST">
<input name="email" type="hidden" value="[email protected]" />
<input name="csrf" type="hidden" value="{csrf_tokenimiz}" />
<input type="submit" value="Submit Request" />
</form>
<img src="https://{hedef_site}/?search=asd%0d%0aSet-Cookie:%20csrfKey={csrfKey_değerimiz};%20SameSite=None" onerror="document.forms[0].submit()">Bu payload'da bazı noktalara göz atalım. Sorguladığmız terim "asd" nin ardından %0d%0a değerini kullandık. Bu değer HTTP isteklerinde her satır sonunda bulunan CRLF yani \r\n değeridir. Yeni satıra geçtikten sonra kendi csrfKey değerimizi kullanmak için Set-Cookie başlığını belirtiyoruz. Ardından SameSite=None çerezi ile de siteler arası çerez erişimi de sağlanmış olur. Ardından form ile istek gönderilir ve kurbanın e-posta adresi bizim sağladığımız değerler ile değiştirilmiş olur. İlgili exploiti Store ile kaydedip kurbana gönderdiğimizde lab da çözülmüş oluyor.
Bu yazıda çeşitli CSRF token kontrollerindeki bazı hatalardan bahsettik. Umarım faydalı olmuştur. Bir sonraki yazımızda görüşmek üzere!
