- See-Sirf şeklinde okunur.
- Kurbanın bilgisi olmadan, sanki kurbandan geliyormuşçasına kurbanın ziyaret etmekte olduğu siteye isteklerin yollanması şeklinde saldırı gerçekleştirilir.
- Kullanıcının tarayıcısını bir kaldıraç gibi kullanarak tarayıcı üzerinden talebini gönderir.
- Bir site, başka bir siteye istek gönderebilir (başka siteye link vermesi mesela), ama istek sonucunu göremez, çünkü SOP (same origin policy) aynı değil. Ama CSRF’in güzel tarafı, cevabı okumaya zaten gerek yok, isteği yapsın yeter.
- Saldırı senaryosu şu şekildedir:
- Kurban, A sitesine giriş yapar
- Başka bir tabda zehirli B sitesine girer
- B sitesi kurbanın tarayıcısına yüklenir yüklenmez A sitesine istek yapar (Saldırgan, kurbanın A sitesine girmiş olduğu tahmin ediyor. Facebook, gmail gibi çok girilen siteler olabilir mesela. Yada saldırganın CISCO ile ilgili bir blog açtığını, bu bloğa CISCO yöneticisinin geleceğini ve onun tarayıcısında da CISCO’nun web yönetim uygulamasının açık olacağını düşünebiliriz)
- A sitesi gelen talebin kurbandan olduğunu kabul ederek talebi devreye alır.
- IE, her ekran için ayrı bir session açar fakat aynı ekrandaki her tab için tek session kullanır. Firefox, her tab için tek bir session kullandığı gibi tüm ekranlar için de tek bir session kullanır. Açıklık da burada zaten. Chrome’da her tab için ayrı bir process başlatıldığı için bu açıklık oluşmaz.
- Bilgi güvenliğinde CSRF açıklığı “Confused Deputy” (Şaşkın vekil) sınıfı altında değerlendirilir. Confused Deputy genel olarak kullanıcının verilen hizmetleri bir vekile güvenerek onun üzerinden almasıdır (müşterinin bankaya gitmeden internet tarayıcısı üzerinden internet bankacılığını kullanması gibi). Burada deputy tarayıcıdır.
- CSRF açıklığı manüel olarak nasıl test edilir?
- Bunun için kişisel web proxy’ler kullanılır (Burp, webscarab vs)
- Proxy aktifken uygulama kullanılır.
- Daha sonra uygulamadan çıkmadan Proxy kullanılarak istek “replay” edilir.
- Tekrarlanan işlem sonucu orijinal cevap ile aynıysa CSRF zafiyetinden bahsedilir.
- Daha detaylı bir manuel test için
- Burp açıp istek yapın,
- Logout olun,
- Tekrar login olun,
- Orjinal isteği (ilk logindeki request) Burp ile replay edin; sadece yeni login olduğunuzda aldığınız cookie'yi yerine yerleştirecek şekilde değişiklik yapın,
- İlk cevapla yeni aldığınız cevabın tutup tutmadığını kontrol edin. Tutuyorsa CRSF vardır.
- Otomatik açıklık tarayıcılarının CSRF açıklığı bulma oranı çok çok düşük. Bu nedenle CSRF açıklığı konusunda manuel tarama yapmak önemli. Burp vb. ile manuel taramalar yapmak gerekir bu açıklık için.
- Hassas sonuçlu işlemler ve özellikle GET tipi ve AJAX istekler öncelikli olarak test edilmelidir.
- Klasik POP istekleri özellikle .NET uygulamalarında çatıların default özellikleri nedeniyle açıklığa karşı dayanıklıdır. Yine de dikkat, bu özellikler değişemez değil sonuçta!
- Otomatik test teknikleri de var ama çok etkili değil.
- CSRFTester.
Önceleri web uygulama güvenliğine özel olması düşünülen blog, daha sonra diğer sızma testleri konularını da kapsayacak şekilde genişletilmiştir.
30 Mayıs 2010 Pazar
14: CSRF (Cross Site Request Furgery)
Kaydol:
Kayıt Yorumları (Atom)
Web Uygulama Sızma Testleri İçin Kontrol Listeleri - V
Checklist for Web App Pentesting - V 6. Veri Denetimi (Data Validation) Testleri 6.1 Girdi Denetimi Bütün girdiler denetlenmelidir....
-
& (%26) URL sorgu tümcesindeki parametreleri mesaj gövdesinden ayırmada kullanılır. = (%3d) URL sorgu tümcesindeki parametrelerin i...
-
Checklist for Web App Pentesting - V 6. Veri Denetimi (Data Validation) Testleri 6.1 Girdi Denetimi Bütün girdiler denetlenmelidir....
-
Bu yazı, web uygulama sızma testleri sırasında kullanılan araç çeşitlerini konu almıştır. Bu araçların hangi amaçla kullanıldığı anlatılarak...
Hiç yorum yok:
Yorum Gönder