Forum
Aktif konular
Üyeler
Kurallar
Arama
Tahribat.com Forumları 
Hertürlü Web tabanlı Saldırı Taktik ve Stratejileri 
Cross Site Request Forgery Cross Site Request Forgery
-
Cross Site Reference Forgery
Genel Web Uygulama Zayıflıklarına Giriş
Giriş
Cross Site Reference Forgery (XSRF), bir eylemi gerçekleştirmek için web tabanlı uygulamaları tahmin edilebilir yapı içinde etkileyebilecek bir saldırı türüdür. Bu saldırının ismi farklı şekillerde kısaltılabilmektedir ama en genel kullanımı XSRF şeklinde olup CSRF ile aynı anlama gelmektedir. XSRF saldırıları, aynı zamanda “Saldırgan Linkleme” saldırıları olarak da bilinmektedir. CSRF ismi, Peter Watkins (peterw@usa.net) tarafından 2001 Haziran ayında verilmiştir. XSRF saldırılarına karşı hassas olan uygulamaların, XSRF kusuruna sahip olabileceği veya XSRF’ye karşı kusurlu duruma gelebileceği söylenilmektedir.
XSRF kusurları; kullanıcıları denetlemek için çerezleri, tarayıcı denetlemelerini ve istemci tarafı sertifikalarını kullanan ve önceden tahmin edilebilir eylem yapısına sahip olan web uygulamalarında oluşmaktadır. XSRF’deki ana fikir çok basittir; saldırgan, bir linkle veya başka bir içerikle hedef uygulama üzerinde, saldırganın seçimiyle, kurbanın eylemlerini yöneten bir başka eylemi gerçekleştirerek kullanıcıyı aldatır. Bu, HTTP GET örneği üzerinde anlamak için en kolay tanımdır.
Örneğin;
Bu linke tıklanılması halinde Google’da “iSEC Partners” olarak arama yapılmaktadır. Bu zararsızdır.
Fakat link yukarıdakine benzer bir şekilde olursa; sadece çerez, tarayıcı denetlenmesi veya sertifikasıyla ispatlanmış kullanıcılara, herhangi bir uygulama üzerinden başka kullanıcının profilini düzenlemeye veya e-posta adresini değiştirmeye izin verecektir.
Linkler, kolay bir şekilde gizlenebilir; bu yüzden başka bir yere yönlenebileceği görülmektedir ve kelimeleri gizlemek, onların gerçek fonksiyonlarını açığa çıkarabilmektedir. XSRF saldırıları; eylemlerini gerçekleştirebilmek için HTTP GET ya da HTTP POST kullanan uygulamaları etkiler.
XSRF Uygulamasına Örnek – Goat Chat
Goat Chat, kullanıcılar arasında mesajlaşmayı sağlayan kuramsal web uygulamasıdır. Goat Chat; kullanıcıların isim ve şifrelerini içermeyen ve daha uzak istekleri denetlemek için kullanıcılar tarafından kullanılan, geniş ve tahmin edilemeyen oturum ID çerezi oluşturur. Goat Chat’in özeliklerinden birisi; diğer bütün linkleri içeren text mesajları gönderebilmesidir. Goat Chat kuramsal olarak https://goatchat.isecpartners.com/ adresinde görülmektedir ve mesajları, delilleri ve oturum tanıtıcılarının sırrını ağ dinleyicilerinden korumak için HTTPS yi kullanır. Bu uygulama, etkin cross site scripting filtreleri içermektedir ve HTML içerik engellemesine sahiptir.
Goat Chat aşağıdaki kullanıcı eylemlerini destekler:
- Oturum Açma(Login)
- Mesaj Gönderme
- Yeni Mesajları Denetleme
- Oturumu Kapatma(Logout)
“Gelen Mesajlar” çerçevesi, oturumu açmış olan kullanıcılara görünür. Bu çerçeve Javascript kullanır ya da “Check for new messages” eylemini gerçekleştirmek için her 10 saniyede kullanıcıların yan tarafında etiket yenilenir. Yeni mesajlar bu çerçevede görüntülenir ve gönderenin ismi ile mesajın metnini içerir. Metin, HTTP veya HTTPS urlsi içeriyorsa otomatik olarak linke dönüştürülmektedir. “Send a message” eylemi 2 parametre içermektedir; Mesajın varış yeri(Kullanıcı ismi) ve kısa karakter dizisi içeren metnin kendisi. “Logout” eylemi ise hiçbir parametreyi gerektirmemektedir.
Uygulamanın XSRF’ye hassas olup olmadığını belirlemek için, “Send a message” eylemine bakmamız gerekmektedir. Bunu yapacağımız zaman; gönderilen mesajlara sunulan aşağıdaki basit HTML formunu buluruz:
Şekil 1: Mesaj Gönderme Formu(Yukarıda)Burada da çerçevenin neye benzediği:
Şekil 2: Şekil 1′in Sunumu(Yukarıda)
Bu forma bakarak, kullanıcıların Hi Alice metnini içeren bir mesajı Alice’e göndermek istediklerinde, Send Messaga’a tıkladıklarında aşağıdaki URL’nin çekileceğini anlayabiliyoruz.URL 1: Alice’e “Hi Alice” metnini içeren mesajı gönderen URLKullanıcı, URL 1 için bir HTTP GET gerçekleştireceği zaman; tarayıcı goatchat.isecpartners.com sitesi için uygun çerezleri içerir. Oturum açmış kullanıcıya çerezin gönderilebilmesi için gereken tek şey; sadece bir istek yapmak. Saldırganlar bunu uygulayabilirler.
Eğer oturumu açmış olan kullanıcı; hackerlar tarafından üçüncü parti başka bir siteye ziyaret ettirilmişse, kullanıcının yönlendirildiği bu site aşağıdaki görüntü etiketini içermiştir. URL 1, kurbanın tarayıcısı tarafından çekilmişse ve uygulama serverı tarafından çalıştırılmışsa; sanki kullanıcı Alice’e “Hi Alice” metnini içeren bir mesaj göndermiş gibi olacaktır.Şekil 3: Kullanıcının URL 1′i ziyaret etmesine neden olan HTMLSaldırgan, bir linki alternatif olarak bir e-postayla ya da anlık mesajlaşma servisleri yardımıyla kullanıcıya gönderebilirdi. Saldırgan, bu linki http://tinurl.com/ benzeri bir site ile gizleyebilir ve ardından kurbanı hedef siteye yönlendirebilir. Birçok site; kurbanları herhangi bir web sayfasına yönlendirmek için kullanılan sayfalara sahiptir. Bu parametreler, sıkça URL şifreleme veya diğer hile yollarıyla oluşturulmaktadır.
Eğer GET yerine POST metodu kullanılsaydı, link tarafından yapılan uygulama değişiklik gösterecekti. Saldırgan, kendi kontrolünde olan bir siteye kurbanı yönlendirecek bir linki kurbana gönderebilir ki bu site; hedef siteyi gösteren bazı içeriklere sahip olabilir. Bu form, ya otomatik olarak ECMAScript ile ya da kullanıcı ona tıkladığında onaylanır. Daha çok varyasyonlar; çok aşamalı formlarla mümkün olabilir.
Şekil 4 örneği ise, kullanıcının eski şifresini girmeden onun parolasını değiştirmeye izin veren bir formdur. Bu örnekte hedef servlet(*) HTTP Post talep etmektedir ve saldırgan; tüm gereksinimlerin yerine getirilebilmesi için kendiliğinden onaylanabilir bir form oluşturabilir. Şunu bilmemiz gerekir ki; bu exploit Şekil 3teki gibi image tabanlı istekler kadar garanti bir yöntem olmayabilir. Kullanıcının tarayıcısı(veya bu exploiti içeren frameler) hedeflenen siteye yönlendirilir. Tarayıcı scripting’i pasif hale getirilmiş kullanıcılar, bu tür saldırılardan etkilenmeyeceklerdir. Ve tabiî ki de bu kullanıcının tarayıcısına ve konfigürasyonuna bağlıdır.(*)Dinamik içerik üreten bir Java Web bileşenidir.
document.evil.submit()
Şekil 4: Gizli form tabanlı exploit
Hatta eğer scripting’i pasif hale getirilmiş olsa bile, “Close This Window” linkleri bile aslında saldırganın isteği doğrultusunda kullanıcıyı kandırmaya yönelik bir buton olabilir.
Görünür ve Gizli XSRF
Benzer bir şekilde XSS ve XSRF zayıflıkları iki büyük kategoriye ayrılırlar. Gizli ve Görünür.
Gizli XSRF zayıflıkları, saldırganın kurbana exploit linkleri gönderdiği uygulamaları kullanabildiği yerlerde veya kurbanın tarayıcısını uygulamaya yönlendiren; böylece kurban yaparmış gibi çalıştırılan ama saldırganın kontrolüne teslim olan içeriklerde görülebilir.
Görünür XSRF zayıflıklarında ise saldırgan; kurbanı exploit linki veya başka bir içerikle karşı karşıya getirmek için sistem dışında bir uygulama kullanır. Bu, bir blogu kullanarak, e-posta mesajlarında, anlık mesajlaşmada, mesaj panosuna post atma gibi şeylerde olabilir. Görünür XSRF açıkları genelde başarısızlıkla sonuçlanır. Exploit denenmeye çalışıldığında, saldırga-nın o sistemin kullanıcısı olarak oraya girme ihtimali düşüktür. Yapılan görünür XSRF ataklarından geriye kalan belirtiler, saldırganın kontrolü altındadır. Exploit tamamlandıktan sonra bu tür belirtiler saldırgan tarafından silinebilir.
Basit Exploitleme Senaryoları
Bazı uygulamalar, XSRF ataklarına karşı diğerlerinden daha zayıf olabilir. Kuşkusuz ki gizli XSRF zayıflıklarına sahip bir uygulama, kesin bir şekilde exploit edilebilir.
Bir çok uygulama HTTP GET çağrılarını, HTTP POST için de yetkili olan aynı kişiye yönlendirir. Servlette(Dinamik içerik üreten bir Java Web bileşeni) örneğin doGet metodu basit bir şekilde doPost metodunu çağırır ve parametreleri böyle yönlendirir. Bu, image veya link tabanlı exploitleri daha kolay kılar ve XSRF açıklarının exploitlenmesini kolaylaştırır.
Bazı uygulamalar; özellikle intranet(*) siteleri, bağlantı ve erişim noktalarındaki yönetim konsolları ve diğer ağ araçları, entegre tarayıcı onaylamasını kullanırlar. Bu tip izinler geçerliliğini yitirmez ve bu yeterlilik belgeleri tarayıcı kapatılana kadar devamlılığını sürdürür. Tüm gün tarayıcısını kullanmak zorunda olanlar için bu süre çok uzundur. Bu tür bir kullanımda, görünür XSRF ataklarının etkinliği daha da artacaktır.
(*) http://tr.wikipedia.org/wiki/İntranet
Birçok uygulama, kullanıcıların o siteye yeniden döndüklerinde bir daha onay belgesini almayı gerektirmeyecek şekilde bir cookie uygulamasına sahiptir. Uzun sessionlar, kullanıcıların XSRF ataklarıyla karşı karşıya bırakabilir.
Bazı uygulamalar ise kullanıcılarına, eski şifreyi yazmadan şifrelerini değiştirme imkanı tanırlar. Eğer bu şifre değiştirme mekanizmaları XSRF’ye karşı zayıfsa, yeniden saldırganlara karşı bir hedef haline gelecektir.
XSRF ve XSS Arasındaki Fark
XSRF ve XSS ki özellikle de görünür XSS, güvenlik risklerinin olduğunu gösterir ve ikisi arasındaki benzerlik bazen kafa karıştırabilir. Bir çok kişi, XSS veya XSRF açıklarını deneyerek bulabilir. Tespit ettiğimiz güvenlik açığının kapanmasındaki yöntemler, aradaki ayrımı daha kolay yapmamızı sağlayacaktır. XSS açıklarına bakarsak saldırgan, girdi veya çıktı filtreleme eksikliğini exploit eder. Eğer uygulamadaki <, >, “, ‘, &, ; veya # gibi zararlı karakterler filtrelenirse açık kapanabilir. Tabii ki sadece XSS açığı. XSRF ise biraz da uygulamanın yapısının tahmin edilebilirliğine bağlıdır. XSS ise, uygulamanın gerçekleştirdiği yetersiz veri onaylaması ile alakalıdır.
XSS açıkları, XSRF’ye karşı alınan güvenlik açıklarına karşı bypass yapmaya izin verebilir. Bundan dolayı XSS açıklarının çözümlenmesinde XSRF açıklarına da göz atılmalıdır.
XSRF Hakkında Yanlış Bilinenler
Yanlış: XSRF, XSS’nin özelleşmiş halidir.
Doğru: XSRF, çözüm yollarının farklılığı ile XSS’den ayrılan bir güvenlik açığıdır. XSS açığını çözmek daha önemli ve öncelikli olmasına rağmen, XSS’ye karşı alınan güvenlik önlemleri XSRF ataklarını durduramayacaktır.Yanlış: İşlem gerçekleştirmek için çok sayfalı formlar kullanılırsa, o uygulama XSRF açıklarına karşı zayıf olmaz.
Doğru: Çok sayfalı formaların kullanılması exploitlemeyi daha zorlu kılsa bile, saldırganlar genellikle onları exploitleyebilirler.Yanlış: HTTP POST kullanan uygulamalar XSRF’ye karşı sağlamdır.
Doğru: POSTlar exploit edilmesi zor olmasına rağmen, kesinlikle exploit edilebilirler.Yanlış: XSRF atakları kullanıcı hatalarıdır.
Doğru: Kullanıcılar, XSRF exploitleri için genellikle kusurlu değillerdir. Uygulamalar, web sitenin sorumluluğunu alan kişi tarafından daha güvenli tasarlanmalıdır.Yanlış: XSRF açıkları düşük risklidir.
Doğru: XSRF açıkları sayesinde saldırgan, izin verilmiş bir kullanıcının gerçekleştirdiği eylemleri kolaylıkla gerçekleştirebilir! Bu şifre değiştirme, ticari bir mal satın alma veya para transferi olabilir.Yanlış: Benim güvenlik duvarım/ SSL server/ .NET beni XSRF’den korur.
Doğru: Eğer uygulamanızı özel olarak XSRF’ye karşı koruma konusunda çaba sarf etmiyorsanız, hemen hemen XSRF’ye karşı savunmasızsınız.Pdf şeklinde okumak isteyenler:
http://www.scribd.com/doc/17455340/Cross-Site-Reference-Forgery
Kaynak: http://www.isecpartners.com/documents/XSRF_Paper.pdf
Çeviri: diamoniqueNot: Orijinal metnin son 2-3 sayfası terminoloji ve açığa karşı alınabilecek önlemler üzerine. Bazı teknik detaylara değindikleri için çevirisini yapmadım. Açığı ben de yeni öğrenmeye çalıştığım için sorularınızı yanıtlama konusunda yetersiz kalacağımı düşünüyorum. Bir de döküman olarak yayınlanması için başvurdum; ama çeviri olduğu için kabul edilmeyeceğini düşündüğümden konu olarak açtım.
-
teşekkürler çeviri için
dökümanlara eklenecek bir yazı
ilk mesajı üyeler editleyemez
-
Güzel döküman, ekleyecem en kısa zamanda...
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla