Webde başka bir güvenlik sorunu, CSRF
Öncelikle bu güvenlik sorunu, hem kullanıcıya hem siteye yönelik dolayısıyla site geliştirmiyorsanız bile bilginizin olması gereken birşey. Nitekim çalınacak hesap sizin hesabınız veya hesabın çalınacağı kullanıcı sizin kullanıcınız.
CSRF, Crosssite Remote Forging (sitelerarası uzaktan işleme) açığı, XSS ile benzerlik gösterse önemli bir farklılık taşıyor. Bu sefer sorun sizin siteniz değil, kullanıcı güvenilmeyen bir siteye girdiğinde, sizin sitenizdeki bilgilerinin çalınabilmesi. Bu da XSS’i tersten düşünmeniz demek, çünkü saldırgan site, bu sefer bütün Ajax, Script Proxy, vb olanaklarını serbestçe kullanıp sizin değer verdiğiniz kullanıcınızın bilgisini alabilecek.
Özellikle büyük kullanıcı tabanlı sistemleri çalıştıranların okumasını öneririm nitekim daha yenice meksikada bir bankanın müşterileri oldukça zarar gördü, milyonlarda e-bay kullanıcısının hesapları değiştirildi ve gmail’in alanadı servisini kullananların hesapları ele geçirildi. Şimdi soru, saldırı nasıl yapılıyor ve sitenizi bundan nasıl kurtarabilirsiniz, fakat ingilizce bilen kullanıcılar için, yazının sonlarındaki ‘Nasıl engelleriz‘ başlığı hariç, wikipedia’dan okumanızı öneririm. Zira orada anlatıldığı gibi Form Token çözüm değil, devam edelim.
Web Geliştirmenleri için bakış açısı
Sizin sitede XSS açığı bulunmasa da, kendi çerezini, oturum bilgisini, veya hesabında sitede yapacağı bir değişiklikle kaptırabilir. Dolayısıyla bu sefer saldırganımız, aslında bir bakıma başka bir siteden ötürü yanlış yönlendirilmiş kullanıcının ta kendisi. Bundan ötürü engellememiz gereken şey de, kullanıcının yaptığı şeyden haberinin olduğuna emin olmak.
Saldırgan sitede siz veya kullanıcılar nasıl böyle yönlendirilebilir
1 – Basit reface: Artık geçmişte kaldı, (bkn: meşhur hotmail jacking) ama örneklendirelim. Site, facebookda gerekli bir işlemi yapmanız için iframe açtığını söyler. Fakat aslında açtığı sitenizin giriş görüntüsüne birebir bir kopyasıdır, dolayısıyla kullanıcı oraya kullanıcı adını şifresini yazıp göndere tıkladığında, sayfa şifresini alır, JavaScript ile gerçekten sayfaya giriş yaptırır ve hesabına ulaştırır mağduru, oysaki farkında bile değildir arada şifresinin çalındığının.
2- Bir adım ilerisi, deface: Site, facebookda gerekli bir işlemi yapmanız için iframe açtığını söyler. Ama bak şu çakallara dersiniz, siz tecrübeli bir internet kullanıcısınızdır. Açılan sayfaya sağ tıklar, bir özelliklerine bakar ve görürsünüz ki bilgi kısmında üstelik SSL desteğiyle bile karşılaşırsınız, https://www.facebook.com yazmaktadır. Sorun görmeden kullanıcı adınızı ve şifrenizi girer, göndere tıklayıverirsiniz. Fakat, açılan iframe’in üzerinde ustaca yerleştirilmiş CSS ile bir DIV durduğunu kaynak kodlarına iyice bir bakmadan anlayamazsınız. Bu DIV tagı z-index:10000 yapılmış, opacity:0.01 ile görünmez hale getirilmiş ve absolute position ile tam da olması gereken yere hizalanmıştır çünkü. Kullanıcı adı ve şifreyi alan JavaScript, gerçekten sayfaya giriş yaptırır ve hesabına ulaştırır mağduru, oysaki mağdur pek bir emindir şifresinin çalınmadığının. Meraklılar için bu yöntemlerin genel adı, clickjacking.
3 – Dyn. IMG src: Diyelim ki, kullanıcı sitenizde oturum açtıktan sonra, GET ile veri değişimine izin verdiğiniz bir sisteminiz mevcut. Özellikle Ajax ile yapılan formlarda, sık sık POST yerine GET kullanıldığını görüyoruz. Adresimiz: www.facebook.com/friend.php?ekle=1992202 olsun, eğer kişi 1992202 numaralı üyeyi facebookunuza bu img tagıyla eklemek için gerekli tek durum, kullanıcının kurban sitede oturum veya “beni hatırla” opsiyonunu açmış olması. Bu durum sağlanmışsa, ister mail ile ister bir forum sitesinde bir iletide bulunan bir resim tagıyla pek çok kişiye sitenizde istemedikleri işlemleri yaptırmak mümkün.
Bir diğer tehdit sunucunuzun IP adresini spam liste düşmesidir. Tecrübeli internet geliştirmenleri ve yöneticileri bilirler: internette anti-spam, e-posta hizmeti kurumlarının tuzak e-postaları vardır, eğer bu adreslere birden fazla e-posta gönderirseniz MTA IP adresiniz otomatik olarak spam listelerine düşecektir. Eğer Opt-in formunuzun aksiyonu maillist.php?ekle=gokce@yalcin.com gibi bir şeyse, bu adres yerine bir çok e-posta kullanarak sunucu IP adresinizin spam listlere girmesi sağlanabilir.
3- İleri CSRF – Öncelikle, bu durum sadece sitede beni hatırla gibi bir opsiyon kullanılmışsa geçerli olmakla beraber, 2. adımla birlikte kullanılır. Buarada POST kullanıldığı sürece kendinizi güvende sanabilirsiniz, nitekim Ajax çağrısı siteler arası yapılamaz ve img veya script proxy tekniği POST ile veri gönderimine izin vermez. Fakat aksiyonu gönderirken js ile bir anchor tagı tetiklenirse sabitlenen inceleyicinin browser tagı, sitenin veri yollama adresini tekrar değiştirerek POST verisi bile gönderilebiliyor.
4- Malware – Kurbanın bilgisayarında bir malware (istenmeyen yazılım) vardır. Kurbanın, kurban sitedeki kritik işlemlerini oturum cookielerini ele geçirerek otomatik yapıyordur.
Nasıl engelleriz (web geliştirmenleri)
Bu sefer istek kullanıcının kendisinden geleceğinden, daha önce dediğim gibi hesabına girişi veya siteye erişimi gerçekten bilinçli olarak istediğini emin olmalıyız. Aslında davranışımız bir formun gerçekten bizim sayfa açılıp mı yollanıyor kontrol edişimizle aynı, fakat çok daha derin bakmak gerekiyor.
Yöntem 1 – Captcha veya tekrar şifre istemek: Sunucuda bir resim yaratmak ve kullanıcıdan onu yazmasını istemek, dolayısıyla karşımızdakinin bir robot olmadığını anlamak sizi kurtarır. Her kritik işlemde, captcha veya kullanıcının şifresini yeniden isteyebilirsiniz. Eksisinden bahsedersek örneğin bir sosyal ağ sitesinde eklenilen her arkadaş için captcha doğrulamak, veya şifre istemek pek hoş olmayacaktır. Öte yandan bankaların tercihidir.
Yöntem 2 – Form Tokens: Kullanıcıdan ikinci bir adımda emin misiniz? gibi bir soruyla işleme devam etmesini sağlayabilirsiniz, veya formda bir gizli alanda forma uniqe bir değer atayabilir onu kontrol edebilirsiniz. Örneğin del.icio.us her ne kadar bu yöntemi kullandıysa da, bu da pek geçerli bir güvenlik değil. Nitekim gelen ikinci sayfa, CSS ile üstüste bindirilip kullanıcı kandırılabilir. Eğlenceli bir örneği var, bakın: CSRF Chat!
Yöntem 3 – Frame Yasaklama: “if (window.top != window) window.top.location.href=window.location.href” şeklinde bir JavaScript koduyla sitenizin iframede açılmasını engelleyebilirsiniz. Fakat kullanıcının JS motoru kapalıysa, çalışmayacaktır.
Yöntem 4 – Referer Kontrolü: Referer malesef sizi 3. madde haricinde hiç korumaz. Iframe örneğinde, referer zaten siz olacaksınız, başka durumlarda yapılan HTTP sorgularında referer kullanıcının sağladığı bir bilgi olduğundan, referer kısmına istediğiniz şey yazılır.
Sonuç:
1. Uygulama bir değişiklik yapacaksa, mutlaka olması gerektiği gibi POST yöntemi kullanın.
2. Kullanıcıları ‘logout’ butonuna olabildiğince alıştırın.3. Kullanıcıyı oturum kapatmaya yönlendirin.
4. Oturum cookielerinizi mümkünse şifreleyin ve beni hatırla opsiyonunda mutlaka kullanının kendi kimliğini de açığa vurmayın, id’sini, e-postasını, kullanıcı adını bu cookie’ye koymayın. Onun yerine onu temsil edecek veritabanında tuttuğunuz bir başka unique değer kullanın. Bunun örneği için Kohana’nın veya ZF’nin Auth modülünü inceleyebilirsiniz.
5. Frame’lenmekten kaçının. JS kodunu kullanabilir, JS’yi zorunlu yapabilirsiniz.6. Kullanıcıyı yaptığı işlem hakkında bir sonraki sayfada mutlaka uyarın. CSS konusundaki İşlerini zorlaştıracaktır.
7. Referer, User-Agent gibi kullanıcı tarafında setlenen bilgilere hiçbir zaman güvenmeyin.
Nasıl korunuruz (kullanıcılar)
1- Mutlaka oturumlarınızı kapatın, beni hatırla opsiyonunu tercih etmeyin.
2- Iframelerden çekinin, sitenin içinde bir başka site açılıyorsa, bunun nedeni açıklanıyorsa bile kuşkunuz olsun. Siz gene iyisini yapın, o siteyi kendiniz açın.
3- Çerezlerinizi “sadece ziyaret ettiğiniz alanadından” kabul edin. Nasıl yapacaığınızı soruşturun, her inceleyicide farklıdır.
4- Hep denildiği gibi, bir anvirus yazılımı kullanın, bilmediğiniz şeyleri kullanmayın, IE’yi pek tercih etmeyin.
5- Çok mu paranoyaksınız, “Lynx” veya “Links” kullanın! :-)
bkz:(http://en.wikipedia.org/wiki/Cross-site_request_forgery,http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html,http://www.schneier.com/blog/archives/2008/10/clickjacking.html,http://lists.immunitysec.com/pipermail/dailydave/2008-September/005356.html)