Cross Site Reference ForgeryGenel Web Uygulama Zayıflıklarına GirişGirişCross Site Reference Forgery , 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 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 sylenilmektedir. 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 yneten 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 ynlenebileceği grü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ı gnderebilmesidir. Goat Chat kuramsal olarak https://goatchat.isecpartners.com/ adresinde grü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 - Mesaj Gnderme- Yeni Mesajları Denetleme- Oturumu Kapatma "Gelen Mesajlar" çerçevesi, oturumu açmış olan kullanıcılara grü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 grüntülenir ve gnderenin ismi ile mesajın metnini içerir. Metin, HTTP veya HTTPS urlsi içeriyorsa otomatik olarak linke dnüştürülmektedir. "Send a message" eylemi 2 parametre içermektedir; Mesajın varış yeri 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; gnderilen mesajlara sunulan aşağıdaki basit HTML formunu buluruz:Şekil 1: Mesaj Gnderme Formu Burada da çerçevenin neye benzediği:Şekil 2: Şekil 1in Sunumu Bu forma bakarak, kullanıcıların Hi Alice metnini içeren bir mesajı Alice'e gndermek istediklerinde, Send Messaga'a tıkladıklarında aşağıdaki URL'nin çekileceğini anlayabiliyoruz. https://goatchat.isecpartners.com/GoatChatMessageSender?Destination=Alice&message=Hi+Alice&Send=Send+MessageURL 1: Alice'e "Hi Alice" metnini içeren mesajı gnderen URL Kullanı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 gnderilebilmesi 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 ynlendirildiği bu site aşağıdaki grü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 gndermiş gibi olacaktır. "https://goatchat.isecpartners.com/GoatChatMessageSender?Destination=Alice&message=Hi+Alice&Send=Send+Message"Şekil 3: Kullanıcının URL 1i 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 gnderebilirdi. Saldırgan, bu linki http://tinurl.com/ benzeri bir site ile gizleyebilir ve ardından kurbanı hedef siteye ynlendirebilir. Birçok site; kurbanları herhangi bir web sayfasına ynlendirmek 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 gsterecekti. Saldırgan, kendi kontrolünde olan bir siteye kurbanı ynlendirecek bir linki kurbana gnderebilir ki bu site; hedef siteyi gsteren 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 yntem olmayabilir. Kullanıcının tarayıcısı hedeflenen siteye ynlendirilir. Tarayıcı scripting'i pasif hale getirilmiş kullanıcılar, bu tür saldırılardan etkilenmeyeceklerdir. Ve tabii 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ı exploitHatta 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 ynelik bir buton olabilir. Grünür ve Gizli XSRFBenzer bir şekilde XSS ve XSRF zayıflıkları iki büyük kategoriye ayrılırlar. Gizli ve Grünür. Gizli XSRF zayıflıkları, saldırganın kurbana exploit linkleri gnderdiği uygulamaları kullanabildiği yerlerde veya kurbanın tarayıcısını uygulamaya ynlendiren; bylece kurban yaparmış gibi çalıştırılan ama saldırganın kontrolüne teslim olan içeriklerde grülebilir. Grü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. Grü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 grü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 ynlendirir. Servlette rneğin doGet metodu basit bir şekilde doPost metodunu çağırır ve parametreleri byle ynlendirir. 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 ynetim 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, grünür XSRF ataklarının etkinliği daha da artacaktır. http://tr. wikipedia. org/wiki/İntranetBirçok uygulama, kullanıcıların o siteye yeniden dndü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 FarkXSRF ve XSS ki zellikle de grünür XSS, güvenlik risklerinin olduğunu gsterir 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 yntemler, 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 gz atılmalıdır. XSRF Hakkında Yanlış BilinenlerYanlış: 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-ForgeryKaynak: 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 dkü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. Reecep Tayyip'in Askerleriyiz

teşekkürler çeviri içindkümanlara eklenecek bir yazı ilk mesajı üyeler editleyemez inspired by love and guided by knowledge

Güzel dküman, ekleyecem en kısa zamanda... Sanıyorum kendi ataszümü yaptım, kaynak belirterek kullanabilirsiniz. 10.05.2013 tarihli google arama sonucu : Aradığınız - "herşeyin hayırlısı rampanın bayırlısı" - ile ilgili hiçbir arama sonucu mevcut değil. Not : Syleyeni belli olduğu için ataszü değil, zlüsz oluyormuş, dolayısı ile kendi zlüszümü yapmış oldum :)