PortSwigger Cross Site Request Forgery (CSRF) Labs
Cross-site Request Forgery yani CSRF, saldırganların kullanıcıların onayı ve bilgisi olmadan kullanıcılar adına işlem yapabilmesine neden olan bir güvenlik zafiyetidir. Başarılı bir CSRF saldırısı, e-posta adresi değiştirme ve para transferi gibi kullanıcının isteği ve amacı olmayan eylemleri gerçekleştirmeye olanak tanır. Eylemin niteliğine bağlı olarak saldırgan kurban üzerinde tam kontrole sahip olabilmektedir. Eğer kurbanın ilgili uygulamada ayrıcalıklara sahipse saldırganın etki edebileceği yüzey daha geniş olmaktadır
Lab 1 Lab 2 Lab 3 Lab 4 Lab 5 Lab 6 Lab 7 Lab 8
Lab-1 CSRF vulnerability with no defenses
Bu laboratuvardaki e-posta değiştirme fonksiyonunda CSRF güvenlik zafiyeti bulunmaktadır. Lab’ın tamamlanması için özel olarak bir HTML oluşturup kurbanın e-mail adresinin değiştirmesini hedefleyen bir CSRF saldırısıı gerçekleştirilmelidir.
Lab tarafından verilen wiener:peter bilgileri ile giriş yapılmaktadır.
Daha sonrasında e-posta değiştirme işlevi kullanılarak bir request yakalanmaktadır.
Yakalanan request ile BurpSuite’in Generate CSRF PoC aracı ile zararlı bir HTML formu oluşturulmaktadır.
Oluşturulan form Exploit server üzerinden kurbana iletilerek lab tamamlanmaktadır.
Lab-2 CSRF where token validation depends on request method
Bu laboratuvardaki e-posta değiştirme fonksiyonunda CSRF güvenlik zafiyeti bulunmaktadır. Uygulama, bazı request tiplerinde CSRF saldırısı engellemektedir. Lab’ın tamamlanması için CSRF saldırısı gerçekleştirerek kurbanın e-posta bilgisi değiştirilmektedir.
wiener:peter bilgileri ile giriş yaptıktan sonra e-posta değiştirme requestini bir önceki lab’da yapıldığı üzere alınmaktadır. CSRF token bilgisi değiştirilerek request gönderilmek istediğinde uygulama hata varmektedir. Fakat POST isteğini GET isteği olarak değiştip denendiğinde uygulama kabul etmektedir. Çünkü CSRF önleme sadece POST isteği için kullanılmaktadır.
Lab-3 CSRF where token validation depends on token being present
Bu laboratuvardaki e-posta değiştirme fonksiyonunda CSRF zafiyeti bulunmaktadır. Lab’ın tamamlanması için CSRF saldırısı gerçekleştirilmelidir.
Uygulama farklı request metodlarını kontrol ettiğinden POST olan requesti GET yapmak bir sonuç vermemektedir. Ancak body’de iletilen mail ve CSRF token bilgisinden token bilgisini silerek uygulama sunucusuna gönderildiğinde saldırı başarılı olmaktadır.
Lab-4 CSRF where token is not tied to user session
Bu laboratuvarda e-posta değiştirme fonksiyonunda CSRF güvenlik zafiyeti bulunmaktadır. Uygulama CSRF saldırısı için token kullanmaktadır ancak bu tokenler uygulamanın session handling sistemine entegre değildir.
wiener:peter kullanıcısına girip e-posta değiştirme fonksiyonunu kullanıp hesapla ilişki olan CSRF token bilgisi not alınmaktadır.
Daha sonrasında hedef kullanıcı olan carlos hesabına giriş yapılıp aynı request ele geçirme işlemi yapılmaktadır.
Daha sonrasında carlos kullanıcısı için PoC hazırlanırken CSRF token değeri weiner kullanıcısının CSRF token bilgisiyle değiştirip uygulanmaktadır. Uygulama kullanıcılar ile CSRF token bilgilerini ayrı ayrı ilişkilendirmediğinden ele geçiren bir CSRF token bilgisi başka hesaplar için de kullanılabilmektedir.
Lab-5 CSRF where token is tied to non-session cookie
Bu laboratuvardaki e-posta değiştirme fonksiyonunda CSRF zafiyeti bulunmaktadır. Uygulama CSRF saldırılarından korunmak için token kullanmaktadır ancak session handling sisteme tam anlamıyla entegre değildir. Lab’ın tamamlanması için CSRF saldırısı gerçekleştirilerek kurbanın e-posta bilgisi değiştirilmelidir.
weiner:peter kullanıcısı ile giriş yaptıktan sonra e-posta değiştirme requesini yakalayıp üzerinde değişiklikler ile denemeler yapılmaktadır. CSRF token değiştiğinde veya silindiğinde invalid token hatası vermektedir. Fakat csrfKEY değiştiğinde yine invalid CSRF token hatası vermektedir. Yani csrfKEY bilgisinin session ile tam anlamıyla entegre çalışmadığını göstermektedir.
weiner kullanıcısı ile e-posta değiştirme requesti yakalanmaktadır.
Diğer kullanıcı olan carlos hesabına giriş yapılarak CSRF token ve csryKey bilgileri alınmaktadır.
Daha sonrasında ilk weiner kullanıcına ait olan e-posta değiştirme requesti üzerindeki CSRF token ve csrfKey bilgileri carlos kullanıcısına ait olan bilgilerle değiştirilerek gönderilmektedir. csrfKey ile session tam olarak entegre olmadığından bu işlemin çalışması gerekmektedir.
Beklenildiği gibi e-posta değiştirme işlemi gerçekleşmektedir.
Search fonksiyonu kullanıldığındaki response bilgisine bakıldığında Set-Cookie header’ı görüntülenmektedir. ve arattığımız “Selam” değeri görüntülenmektedir. Yani bu header’da kontrol edebileceğimiz bir değer bulunmaktadır. Ayrıca CSRF koruması bulunmadığından kurban kullanıcının tarayıcısına cookie bilgisi enjekte etmek için kullananabiliriz.
csrfKey enjeksiyonu
/?search=test%0d%0aSet-Cookie:%20csrfKey=s6Tz8qK5v3S5bfJ32EBPxnLZKjExQRJB
Son olarak CSRF PoC oluşturarak ( e-posta değiştirme requesti ile ) bir payload elde etmekteyiz. Script kısmını değiştirerek sayfa açılır açılmaz csrfKey enjeksiyonu gerçekleşmektedir ve sonra csrf bilgimiz ile birlikte csrfKey kullanılarak hedef kullanıcının e-posta bilgisi değiştirilmektedir.
Lab-6 CSRF where token is duplicated in cookie
Bu laboratuvardaki e-posta değiştirme fonksiyonunda CSRF güvenlik zafiyeti bulunmaktadır. Uygulama “double submit” CSRF yaklaşımına karşı korunmaktadır. Lab’ın tamamlanması kurbanın e-postasını değiştirecek CSRF saldırısı gerçekleştirilmelidir.
E-posta değiştirme requesti incelendiğinde cooki’de bulunan CSRF token ile body’de iletilen CSRF token birbirinin aynısıdır yani sunucu tarafında bu iki değer kontrol ettirilerek bir önlem alınmaya çalışılmaktadır.
Arama request-response döngüsü incelendiğinde bir önceki lab’daki gibi “Set-Cookie” header’ına erişim sağlanabilindiği gözlemlenmektedir. Bu durum CSRF saldırısı için kullanabiliriz.
E-posta değiştirme request’i üzerinden hazırlanan CSRF PoC içerisindeki csrf token bilgisi saldırganın token bilgisi ile değiştirilmektedir. Ayrıca kurban zararlı web sitesine gittiğinde cookie’de taşınan csrf token bilgisine enjekte edilmek üzere ek bir payload daha bulunmaktadır. Bu payload hedef kullanıcıya gittiğinde cookie’de ve body’de taşınan csrf tokenlar kontrol edilecek ve birbirisinin aynısı olduğundan istenilen e-posta değiştirme gerçekleştirilecektir.
Lab-7 CSRF where Referer validation depends on header being present
Bu laboratuvardaki e-posta değiştirme fonksiyonunda CSRF güvenlik zafiyeti bulunmaktadır. Uygulama CSRF saldırısını önlemek için farklı domainlerden gelen requestleri engellemektedir fakat güvenilir olmayan bir geri dönüşü bulunmaktadır. Lab’ın tamamlanması için kurbanın e-posta bilgisini değiştirecek CSRF saldırısı gerçekleştirilmelidir.
E-posta değiştirme requesti incelendiğinde Referer header bilgisi değiştiğinde sunucu hata vermektedir.
E-posta değiştirme requesti ile bir CSRF PoC hazırlanmaktadır ve ek olarak bir referere header’ı eklenmektedir. Çünkü bu header benzersiz bir veri iletmediğinden saldırgan bu veriyi de PoC içerisine ekleyip kurbanı hedef alabilmektedir.
Lab-8 CSRF with broken Referer validation
Bu laboratuvardaki e-posta değiştirme fonksiyonunda CSRF güvenlik zafiyeti bulunmaktadır. Uygulama farklı domain’lerden gelen requestleri tespit ederek engellemektedir fakat bu önleme sistemi atlatılabilmektedir. Lab’ın tamamlanması için kurbanın e-posta bilgisini değiştiren bir CSRF saldırısı gerçekleştirilmelidir.
E-posta değiştirme requesti incelendiğinde Referer bilgisi değiştirildiğinde sunucu isteği onaylamamaktadır. Fakat Referer bilgisinde uygulamanın yasal domain’i de bulunursa uygulama bunu kabul etmektedir.
CSRF PoC hazırlarken history.pushState’in 3. argümanını hedef web sitesinin yasal domaini olarak değiştirerek hazırlayak kullanıcıya iletilmektedir.
Eğer exploit başarısız olursa. Bunun sebebi bir çok tarayıcının güvenlik önlemi olarak query string’i Referer header’dan varsayılan olarak çıkarmasıdır. Bunu atmatlamak için exploit server’daki header kısmına “Referrer-Policy: unsafe-url” header bilgisi eklenmelidir.
Daha sonra store ederek saldırgana iletilmektedir.
