XSRF FAQ

25/Tem/09 02:56

Kısayol

Şikayet

Özel Mesaj

diamonique

Banlanmış Üye

Kayıt Tarihi: 23/Temmuz/2009

Cross Site Request Forgery Nedir?

Cross Site Request Forgery XSRF, CSRF ve Cross Site Reference Forgery olarak da bilinir. Site komutları genellikle özel işlemlerin yapılabilinmesine olanak sağlayan özel url\’lere linklenmiştir.(Örneğin: http://site/stocks?buy=100&stock=ebay) Eğer bir kullanıcı siteye giriş yaptıysa ve saldırgan da kurbanın tarayıcısında yukarıdaki türden görev linklerini kullanarak bazı hileler denerse aynen kullanıcı gibi siteye giriş yapabilir. Genel olarak saldırgan, ya direkt olarak ya da Cross Site Scripting(XSS) açığından yararlanarak kullanıcının bilgisi olmadan, özel görev linklerine istek gönderecek şekilde zararlı HTML ve JavaScript kodlarını bir e-postaya veya websiteye gömebilir. BBCode gibi bazı biçimleme dillerinde bu mümkün olabilmektedir.

CSRF ile Neler Yapılabilir?

Website tarafından izin verilen bir çok işlevsel modül, CSRF açığından yaralanılarak saldırganlar tarafından kullanılabilir. Bu; mesaj panosuna post atmak, online gazetelere abone olmak, hisse senedi ticareti yapmak, alışveriş kartı kullanmak ve hatta e-kartlar göndermek bile olabilir. CSRF aynı zamanda mevcut XSS açıklarının da exploit edilmesine aracılık edebilir. Şimdi şöyle düşünelim: XSS açığının olduğu bir online forum veya blog düşünün. Saldırgan burada CSRF\’den yararlanarak kullanıcıların etkili solucan yazılımlarına maruz kalmasına neden olabilir. İşte bu yolla CSRF açığını kullanarak istediği siteye DoS saldırıları düzenleyebilir.

CSRF Saldırılarını Gerçekleştirmenin Genel Yolları Nelerdir?

CSRF ataklarını gerçekleştirmenin en popüler yolu, HTML image taglarını veya JavaScript image nesnelerini kullanmaktır. Saldırgan, bunları bir e-postaya veya websiteye gömer. Kullanıcı web siteyi veya e-postayı açtığı zaman, saldırganın belirlediği herhangi bir linkin çalıştırılması yönünde bir istek yapmış olur. Aşağıda, saldırganların bu tür istekleri göndermesini sağlayan bazı yöntemler göreceksiniz.

\’XMLHTTP\’ Object (Bunu kullanacağınız zaman aşağıdaki \”Yalnızca POST Kullanan Uygulamalar Savunmasız Olabilir mi?\” başlığına bir göz atın.)

HTML/VBScript/JavaScript/ActionScript/JScript gibi dillerde ve diğer birçok biçimlendirme dilinde, kullanıcıların tarayıcılarında bazı işlemleri gerçekleştirmek için birçok yol mevcuttur.

Bu Güvenlik Açığı Tarayıcılarla mı Sınırlıdır?

Tabii ki hayır. Saldırgan bir scripti; word dökümanının, Flash dosyasının, filmin veya scriptlemeye izin veren diğer diğer döküman formatlarının içine de gömebilir. XML dökümanlarından yararlanan uygulamalar, verinin daha çabuk derlenmesi için XML derleyicilerini kullanır. XML dökümanlarındaki etiketler, XML derleyicilerine (*)URI\’den ek dökümanlar talep etmesine yardımcı olur. Tarayıcılar bu tür saldırıları gerçekleştirmede daha baskın bir rol alır; fakat tek yöntem değillerdir.

(*)URI(Uniform Resource Identifier): İnternet üzerinde kullanılan, bir kaynağı isimlendirmek veya kimliğini saptamak gibi işlemleri yapmakta kullanılan karakterler. Bu kimlikleme işlemi, özel protokoller kullanılarak World Wide Web gibi bir ağ üzerinde bu kaynağın yeniden gösterilmesi ve sunulması şeklinde de yapılabilir.

Yalnızca POST Kullanan Uygulamalar Savunmasızdır Olabilir mi?

Evet. Eğer uygulama CSRF içeriyorsa, belirli bir bölgede çalıştırılan tarayıcı bileşenlerini kullanır. Herhangi bir web siteye remote POST isteklerini göndermek; XMLHTTP veya benzer şeyleri kullanarak mümkün olabilmektedir.

Sadece POST tabanlı parametreleri kullanarak bir websitesine saldırmanın başka yolu da vardır. Ama bu tamamen web uygulamasının nasıl programlandığına bağlıdır. Perl – CGI.PM gibi popüler web tabanlı kütüphaneler; GET veya POST istekleriyle gelmiş olmasına bakılmaksızın bir parametrenin çekilmesine izin verebilir. CGI.PM kullanımında olduğu gibi, saldırgan tarafından POST istekleri GET isteklerine dönüştürülebilir ve uygulama hala çalışıyor olacaktır. Aşağıda bir örnek:

Perl\’s CGI.PM

Bu script, uygulamaya gönderilmek üzere ya GET ya da POST isteklerine izin verecektir. Bu sadece Perl ile sınırlı değildir ve kullandıkları kütüphaneye göre veya uygulamanın hangi yolla geliştirildiğine göre herhangi bir dilde de etkili olabilir. Eğer CGI.PM kullanıyorsanız ve GET isteklerini engellemek istiyorsanız tek yol; \’$ENV{\’REQUEST_METHOD\’}\’ kullanılarak kodlarınızın geri kalanını çalıştırmadan önce bir tarama yapmak için istek gönderme metodu uygulamaktır. Aşağıda, gönderilen GET veya POST istekleri için izin veren dillerin, parametreleri çekmesini sağlayan genel yöntemler var.

JSP Örneği

Genelde Kullanılan: request.getParameter(\”foo\”)
Çözüm: HTTP istek metodunu kontrol edin ve istenilen eylemin gerçekleştirilmesinden önce POST kullandığından emin olun.

PHP Örneği

Genelde Kullanılan: $_REQUEST[\'foo\']
Çözüm: Sadece POST belirlemek için $_POST[\'foo\'] kullanın.

ASP.NET Örneği

Genelde Kullanılan: Request.Params[\"foo\"];
Çözüm: Sadece POST\’u kapsayan HTTPRequest.Form (Request.Form) kullanın.

Eylemleri POST\’a dönüştürmek, CSRF için tek çözüm olmayabilir; ama yine de bu önlemler uygulanmalıdır. Daha kapsamlı çözümler için aşağıdaki \”Kendi Uygulamamı Korumak İçin Neler Yapabilirim?\” konusuna göz atabilirsiniz.

Web Site Savunmasızsa Bunu Nasıl Tespit Edebiliriz?

Eğer siteniz statik URL veya POST istekleri kullanarak herhangi bir site fonksiyonunu gerçekleştirmeye izin veriyorsa açık olabilir. Eğer bu komut GET yoluyla çalıştırılıyorsa daha yüksek bir risk oluşturabilir. Eğer site tamamen POST kullanıyorsa yukarıdaki \”Yalnızca POST Kullanan Uygulamalar Savunmasızdır Olabilir mi?\” konusuna bakabilirsiniz. Şimdi hızlı bir test yapacak olursak Paros gibi bir proxy yardımıyla site üzerinde biraz sörf yapın ve yapılan istekleri kaydedin. Sonra aynı işi proxy kullanmadan gerçekleştirin ve isteklerin aynı biçimde mi çalıştırıldığına göz atın.(Cookieler muhtemelen değişecektir.) Eğer aynı fonksiyonu çalıştırmada GET veya POST istekleri aralıksız olarak kullanılıyorsa, uygulamamız savunmasız olabilir.

Büyük Sitelerde Açıklar Bulunmuş mudur?

Ocak 2007\’de GMail\’de, mail kullanıcılarının irtibat listelerinin çalınmasına izin veren bir açık bulundu. Farklı bir açık da; saldırganın Netflix sitesinde hesaplar üzerinde isim, adres değiştirmesine ve hatta film kiralama isteğinde bulunmasını sağlıyordu.

Kullanıcı Olarak Kendimi Korumak İçin Ne Yapabilirim?

Hiçbir şey. Aslında bir web sitesinde dolaşırken ve web sitesindeki uygulamalar sizin kontrolünüzde olmadığı müddetçe hiçbir şey yapamazsınız. Gerçekler acı, değil mi?

Kendi Uygulamamı Korumak İçin Neler Yapabilirim?

CSRF açıklarına karşı alınabilecek en önemli önlemlerden birisi, her isteğe bir sorun belirteci eklemek olacaktır. Şunu belirtmek gerekir ki; bu sorun belirteçleri kullanıcı sessionu ile alakalı olmalıdır. Aksi takdirde saldırgan geçerli belirteçleri kendisi çekebilecektir ve saldırılarında bunu kullanabilecektir. Kullanıcı sessionuna ek olarak, belirtecin geçerli olduğu zamanın sınırlandırılması da önemlidir.

Pdf şeklinde okumak isteyenler:

http://www.scribd.com/doc/17453775/CSRF-FAQ

Kaynak: http://www.cgisecurity.com/csrf-faq.html
Çeviri: diamonique

Not: CSRF FAQ demek, CSRF Frequently Asked Questions yani CSRF Hakkında Sıkça Sorulan Sorular.

Reecep Tayyip'in Askerleriyiz

Alıntı yap