31 Aralık 2008 Çarşamba

Cross Site Request Forgery (CSRF/XSRF)

Cross-Site Request Forgery

1. Giriş
2. Cross-Site Request Forgery Nedir ?
3. Nerelerde Kullanılır ? Hangi Uygulamalarda CSRF Bulunabilir ?
4. Nasıl Uygulanır ? (Exploiting)
5. CSRF (XSRF) ve XSS Arasındaki Bağ ve Farklılıklar
6. CSRF’den Korunma Yöntemleri

------------------------------------------------------------------------------------------

1. GirişGünümüzde En Yaygın Web Uygulaması Açığı Olan XSS’in Farklı Bir Türevi ve XSS’ide Kaplayan CSRF: Yerine Göre Son Derece Tehlikeli ve Sömürücü Bir Açıktır. Gelin Bu CSRF Nedir Ne Değildir İnceleyelim.

2. Cross-Site Request Forgery Nedir ?
Saldırganın Herhangi Bir Web Sayfasına Gömdüğü JS(JavaScript) veya HTML Kodlarıyla Kurbanın Haberi Olmadan Session(Oturum) Bilgilerini Çalması Olayıdır. Tabi Bu Olay Sadece Oturum Bilgilerini Çalmaktan İbaret Değildir. Kurbana Çalıştırttığı Kod Tipine Göre Değişir (En Basiti ve Çok Verilen Bankadan Örnek Para Transferi.). Bu Olayda Kurban Tamamen Habersizdir Yaptığı Tek Şey Saldırganın Gönderdiği Linke Tıklamasıdır. Tıkladığı Sayfada Herhangi Bir İmaj Tagı (

3. Nerelerde Kullanılır ? Hangi Uygulamalarda CSRF Bulunabilir ?
Bütün Web Uygulamaları CSRF Saldırılarına Uygundur. (ASP, PHP......)

4. Nasıl Uygulanır ? (Exploiting)
Açığı Exploit Etmeye Değinmeden Önce İstemci ve Sunucu Arasındaki Veri Alışverişi Hk. Hazırladığım Alttaki Diyagram’ı Okuyunuz.

Resim 1



CSRF Saldırıları Daha Öncedende Dediğim Gibi Kurbanın Haberi Olmadan Yapılır. Buna Çok Basit Bir Örnek Verelim ;

Herhangi Bir aaa.com Sitesinde Şifre Değiştirme Sayfası Olsun. Link ;
http://www.aaa.com/sifredegis.php

Kullanıcı Şifresini Değiştirdiği Zaman ;
http://www.aaa.com/sifredegis.php?sifrem=123456

Kullanıcının Yeni Sifresi 123456 Olmuştur. Şimdi Olayı Biraz Daha Açalım. Bknz. Resim 2

Resim 2

5. CSRF (XSRF) ve XSS Arasındaki Bağ ve Farklılıklar
XSS İle CSRF Arasında Fazla Farklılık Yoktur. Zaten CSRF XSS’ide İçine Alan Bir Saldırı Tipidir. XSS Olan Her Yerde CSRF Olması %90’dır.

6. CSRF’den Korunma Yöntemleri
- Herhangi Bir İşlem Yapılmadan Önce Kimlik Doğrulaması Yapılmalıdır.

- GET Yerine POST(2) Kullanılmalı.
GET Yerine POST Kullanımı Bazen Yeterli Olmayabiliyor. Fakat GET Metoduna Göre Daha Zordur Çünkü GET Metodunda Değişkenler Tamamen Sayfada Yansıtılır ve Saldırganın İşini Kolaylaştırır.

- URL Rewrite
Form-tabanlı kimlik doprulama yaparken diğer bir opsiyon da cookie yerine URL rewrite (özellikle bu opsiyon uygulama sunucusu tarafından transparan olarak yapılabiliyorsa) kullanımıdır. Oturum tanımlayıcısını her URL’ye dahil edildiğinde, bu tanımlayıcı arka arkaya yapılan sayfa isteklerinde ayrıştırılıp oturum bilgisini tanımakta kullanılabilir. Fakat çoğu uygulamada bunun uygulanabilmesi büyük bir çalışma gerektirebilmektedir.

- Yönlendirme
XSRF saldırılarını HTTP isteğinin yetkili bir kaynaktan gelip gelmediğini kontrol ederek ve yönlendirme kullanarak önleyebilirsiniz. Eğer Referer başlığı yoksa, veya işlemi gerçekleştirmesi gerekmeyen bir sayfa veya site içeriyorsa, yönlendirme kullanıcıyı başka bir sayfaya yönlendirerek ek işlem yapılmasını engelleyebilir.

if ($_SERVER[’HTTP_REFERER’] != ‘[Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...] )
{
header(”********: [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...]
exit;
}
?>

- CAPTCHA
CAPTCHA implemente etmekde XSRF saldırılarını engelleyebilir. CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) basitçe kullanıcının karışık fakat okunabilir harf (veya harf rakam kombinasyonu) içeren resimde gösterilenleri girmesini gerektirir. Burdaki fikir bilgisayarın grafikte gizli olan kelimeyi bulamayacağı ve insanların kolaylıkla ayırtedebileceğidir. CAPTCHA kullanımı, kullanıcının spesifik işlemler öncesi resimdeki bilgiyi girmesi ile olur. İşleme devam için otomatik bir script’in yaratılması çok zor olsa da bunu aşma konusunda araştırmalar yapılıyor. Eğer bu metodu kullanmaya karar verirseniz güçlü bir CAPTCHA kullanın. Güçlü bir CAPTCHA inşa etmek zor olabilir. Ek olarak, resimlerin bilgisayar tarafından okunamadığına emin olmak için, geliştiricilerin, CAPTCHA’nın script seviyesinde atlatılamayacağına emin olması gerekir. Aynı CAPTCHA birden fazla mı kullanılıyor? uygulamanın tekrar-oynatma (replay) saldırısından etkilenmesine yol açarmı? Ya da CAPTCHA ya geçirilen düz yazı cevap web formunun bir parçasımı? Bunlar düşünülmesi gereken problemler.

- Kullanıcıların Yapabileceği Bazı Yöntemlerde Vardır. Cookie’lerinizi Her Oturum Sonunda Temizleyiniz.

Not : Korunma Yöntemleri Alıntıdır. Diğer Bilgiler Kendi Anlatımımdır.




(1)GET
Bir Login (Giriş) Sayfası Ele Alalım Kullanıcı Adı ve Şifreden Oluşsun.. GET Yöntemi Form’u Karşı Tarafa Gönderirken; Gönderilen Bilgiler Adres Satırında Açıkça Görüntülenir.. Örneğin Kullanıcı Adı Ve Şifrenizi Girdiğiniz Zaman Form’a Girdiğiniz Bilgiler Adres Satırında veya Kodlanmada Nereye Yönlendirilmişse Orada Görüntülenir

(2)POst
STPOST Yöntemi İse Form’u Karşı Tarafa Gönderirken Bilgiler Adres Satırında Görüntülenmez.

Bu İki Farkı Ele Alalım ;
Kullanıcı Adı ve Şifre Girdiğiniz Bir Web Sayfasını Karşıya Gönderiken Girmiş Olduğunuz Bilgilerin Adres Satırında (veya Kodlamada Nereye Yönlendirilmişse) Görünmesi Olayına GET Yöntemi Denir. POST Yönteminde Girilen Bilgiler Karşı Tarafa Yine Gönderilir Fakat Bir Fark Var Adres Satırında Girdiğiniz Bilgiler Değil Sadece Standart URL (Link) Görüntülenir.

Hiç yorum yok:

Yorum Gönder