29 Ekim 2012 Pazartesi

Siteler Ötesi İstek Sahteciliği (CSRF)

CSRF saldırıları; sisteme girişi yapmış mağdura ait tarayıcının, bir web uygulamasına sonradan saldırganın yararına olacak, düşmanca hazırlanmış ve önceden doğrulanmış bir istek göndermesine sebep olur. CSRF, saldırdığı web uygulaması kadar güçlü olabilir.

Siteler ötesi istek sahteciliği (Cross Site Request Forgery) yeni bir saldırı türü değildir fakat basittir ve zarar vericidir. CSRF saldırısı, saldırıya açık bir İnternet uygulamasına bir isteği yollaması için kurbanın tarayıcısına zorla giriş yapar, sonra kurbanın adına seçilen hareketi yapar.

Bu saldırıya açıklık aşırı derecede yaygındır, herhangi bir İnternet uygulaması şu nedenlerden dolayı risk altındadır;

Saldırıya açık işlemler için hiçbir kimlik doğrulama kontrolü yoktur,Eğer orijinal giriş bilgileri (kullanıcı adı & şifre) geçerliyse, işlem gerçekleşecektir, 
Örneğin;

http://www.bilgiguvenlik.org/admin/doSomething.ctl?username=admin&passwd=admin

Yetkilendirilmiş istekler, eğer oturum açılmış uygulama varsa oturum çerez bilgileri, eğer oturum açılmamışsa "Beni hatırla" fonksiyonu, veya eğer aktif dizinle açılmış oturumda katılımcı bir Intranet'in parçası ile bütünleşmişse Kerberos işareti gibi otomatik olarak yollanan kimlik bilgilerine dayanır.
Maalesef bugün birçok İnternet uygulaması sadece, otomatik olarak yollanan, oturum çerezleri, temel kimlik doğrulama bilgileri, kaynak IP adresleri, SSL sertifikaları veya Windows alan güven belgelerine güvenmektedir.

Bu saldırıya açıklık ayrıca “Session Riding, One-Click Attacks, Cross Site Reference Forgery, Hostile Linking, and Automation Attack” gibi birkaç başka isim ile de anılır. Baş harflerinin kısaltması olan XSRF de sıklıkla kullanılır. OWASP ve MITRE, Cross Site Request Forgery (siteler ötesi istek sahteciliği) ve CSRF terimlerinin her ikisini de standartlaştırmıştır.

Tipik olarak bir foruma karşı yapılan CSRF saldırısında bazı fonksiyonları çağırmak için, oturum kapatma sayfasında olduğu gibi, yönlendiren kullanıcı formunu alabilir. Kurban tarafından görülen aşağıdaki etikete sahip herhangi bir İnternet sayfasında oturum kapatma isteği oluşturacaktır:
<img src="http://www.bilgiguvenlik.org/logout.php">
Eğer İnternet hizmeti veren bir banka, gelen istekleri işlemek için uygulamaya izin verseydi, örneğin para transferi gibi, benzer bir saldırıya izin vermiş olurdu:
<img src="http://www.bilgiguvenlik.org /transfer.do?frmAcct=document.form.frmAcct
 &toAcct=4345754&toSWIFTid=434343&amt=3434.43">

“BlackHat-2006” da “Intranet sitelerine dışarıdan saldırmak” konusunda konuşan Jeremiah Grossman, kullanıcı, DSL yönlendiricisinin bir İnternet arayüzü olduğunu bilmezse dahi, rızası  olmadan DSL yönlendiricisinde istediği değişiklikleri yapmak için bir kullanıcıyı zorlamanın mümkün olduğunu gösterdi.
Jeremiah saldırıyı gerçekleştirmek için yönlendiricinin hazır gelen hesap ismini kullandı.Bu saldırıların hepsi işe yarar, çünkü saldırgan izin belgesini sağlamasa da, kullanıcının izin belgesi otomatik olarak tarayıcının isteğine dahil olur (genellikle oturum çerezi).

Eğer saldırıyı içeren etiket, saldırıya açık uygulamaya gönderilebilirse, o zaman kurbanlarda kaydedileni bulmanın olasılığı, depolanan ve yansıtılan XSS  (Cross Site Scripting –  siteler arası  betik yazma) kusurları arasındaki riskteki artışa benzer şekilde artar. XSS kusurları, XSS kusurlu uygulamanın CSRF'e hassas olmasına rağmen, CSRF saldırısını çalıştırabilmek için gerekli değildir. Çünkü CSRF saldırısı,kendisine karşı koymak için basamak olabilen elle gönderilen herhangi bir izin belgesini çalmak için XSS kusurunu kullanabilir. Birçok uygulama solucanı, her iki tekniğin birleşimini kullanmıştır.

CSRF saldırısına karşı savunma inşa etmek için, uygulamada XSS açıklıklarını ortaya çıkarmaya odaklanmalı, çünkü böyle kusurlar, CSRF savunmalarını aşmak için kullanılabilir.
Uygulamalar, tarayıcılar tarafından otomatik olarak yollanan izin belgesi veya işaretlerine güvenmemelidir.
Uygulamanın CSRF saldırısına karşı koruma içermesinin tek çözümü, tarayıcının hatırlayamayacağı özel bir işareti kullanmaktır.

Takip eden stratejiler, bütün İnternet uygulamalarında zaten olmalıdır:

● Uygulamada hiçbir XSS saldırıya açıklığı olmamalıdır (Bakınız A1 – Siteler Arası Betik Yazma)

● URL ve her form için tarayıcı tarafından otomatik olarak istenmeyecek rastgele işaretler eklenmelidir. 

Örneğin,
<form action="/transfer.do" method="post">
<input type="hidden" name="8438927730" value="43847384383">
</form>

Ve sonra güncel kullanıcı için gönderilen işaretin doğru olduğunu kanıtlanmalıdır. Bunun gibi işaretler kullanıcı için bazı özel sayfa veya fonksiyonlarda ya da basitçe bütün oturumda benzersiz olabilir. İşaretlerin özel bir fonksiyon ve/veya özel veri takımı olmasına odaklanmak daha kuvvetli bir koruma sağlasa da yapıyı inşa etmek ve sürdürmek daha zor olacaktır.

Hassas veri veya değer işleri için, tekrar kimlik doğrulanmalı, veya isteğin gerçek olduğunu garanti etmesi için işlem işareti kullanılmalıdır. İstekleri doğrulamak veya kullanıcı isteğini iletmek amacıyla e-posta veya telefon irtibatı gibi dış mekanizmalar kurulmalıdır.

● Önemli işler veya hassas veriler için GET isteği (URLs) kullanılmamalıdır. Kullanıcı tarafından hassas verinin işleme tabi tutulduğu zamanlarda sadece POST metodu kullanılmalıdır. Yine de, benzersiz bir URL'i yaratmak için rastgele işaret içeren URL, CSRF'i gerçekleştirmeyi neredeyse imkansız kılar.

● POST metodu tek başına yetersiz bir korumadır. CSRF'e karşı uygun şekilde korunmak için bant dışı kimlik doğrulamasıyla, tekrar kimlik doğrulamayla veya rastgele işaretlerle birleştirilmelidir.

● ASP.NET   için,  ViewStateUserKey  kurulmalı   (Bakınız  Referanslar).  Bu  işlem,  yukarıda tanımladığını gibi rastgele bir işareti benzer yöntemle kontrol etmeyi sağlar.

Bu öneriler, saldırılara maruz kalmayı önemli ölçüde azaltacaksa da, gelişmiş CSRF saldırıları, bu kısıtlamaların birçoğunu geçebilir. En kuvvetli teknik, benzersiz işaretleri kullanmak ve uygulamadaki bütün XSS saldırıya açıklıklarını yok etmektir.

Kaynakça : http://www.bilgiguvenligi.gov.tr

Hiç yorum yok:

Yorum Gönder