Günümüzde, İnternet kullanımı hayatımızın önemli bir parçası haline geldi ve günlük hayatta yapılan işlerin birçoğu İnternet üzerinden yapılıyor. Bu işler arasında bankacılık işlemleri, alışverişler, mail gönderimleri gibi kişisel bilgi içeren önemli işlemler örnek gösterilebilir. İnternet’in kullanımının önem kazanmasıyla beraber bu uygulamaların geliştirilmesi sırasında yapılan hatalardan faydalanma teknikleri de ortaya çıktı. Bu tekniklerden biri de kullanıcıların bilgilerini çalınmasına, değiştirilmesine neden olan bir saldırı yöntemi olan CSRF(Cross-Site Request Forgery)’dir. CSRF saldırısı, web uygulamalarının geliştirilmesi aşamasında yapılan basit bir hatadan faydalanılmasıyla oluşur.

CSRF nedir?

CSRF, “siteler arası istek sahteciliği” anlamında olup “Cross Site Request Forgering” deyiminin baş harflerinin kısaltılmış halidir. Saldırı, herhangi bir son kullanıcının, kullandığı uygulamada isteği dışında işlemler yaptırtılmasıyla gerçekleştirilir. CSRF saldırıları, “Sleeping-giant” yani uyuyan dev olarak adlandırılıyor[1] çünkü İnternet’te bulunan birçok sitede, bu saldırıya karşı herhangi bir koruma mevcut değildir, geliştiriciler ve web güvenlikçileri tarafından arka plana bırakılmış[2] oluşturabileceği zaafiyetler önemsenmemiştir. Fakat, bu açıklığın bulunduğu bir site kolayca ortaya çıkarılıp çok kolay bir şekilde saldırı gerçekleştirilebilir ve sonuçları da ağır olabilir. CSRF, Daha önce yapılan farkındalık anketlerinde en az bilinen web saldırı çeşidi olarak karşımıza çıkmaktadır[3]. Kullanıcıların İnternet banka hesabından para transferi, email hesabının ayarlarını değiştirme, e-posta gönderme CSRF saldırısı ile yapılabilecekler arasındadır. Buna karşın saldırıyı önlemek için uygulanması gereken teknikler de basittir [2].

Güvensiz kod yazımı ve CSRF’den Faydalanma

Sitelerdeki CSRF saldırısına neden olan zaafiyetin temelinde geliştiricilerin uygulamayı geliştirme aşamasında, istemci tarafından gelen her isteğin gerçekten kullanıcıdan geldiğini düşünmeleri yatıyor. PHP ile hazırlanmış örnek bir alışveriş sitesiyle saldırı daha iyi anlaşılacaktır. Site ulaşım için aşağıdaki adresi kullanıyor olsun;
http://ww.shopping.com
Sitede bir kullanıcı, hesabıyla oturum açıp alışveriş yapabilsin. Alışveriş sırasında sepete ekleme yapılabilsin ve sepettekiler silinebilsin. Sepettekilerin silinebilmesi için aşağıdaki gibi bir kod parçacığıyla itemciden istek geldiği düşünülsün.
<form action=”admin.php” method=”GET”>
    <input type=”hidden” name=”cmd” value=”deleteall”/>
    <input type=”submit” value=”delete” />
</form>
Burada GET isteği ile sunucuya, kullanıcı alışveriş sepetindekileri silmesini isteyen parametre gönderiliyor. Sunucu tarafında oturum kontrolü yapılıyor ve geçerli bir oturumdan geldiği için istek yerine getiriliyor.
Bir saldırgan burada bulunan açıklıktan faydalanmak için bir web sitesi hazırlıyor. Hazırlamış olduğu sayfa içerisine açıklığın bulunduğu alışveriş sitesine istek yapmayı sağlayan “<img>” etiketi koyuyor. Kaynak değeri olarak alışveriş sitesinde kullanıcı sepetini boşaltan istek adresi konuyor. “<img>” etiketi, “width” ve “height” değerleri ayarlanarak sayfada gösterilmiyor. Sonuçta sayfa açıldığında alışveriş sitesine kullanıcı sepetini sil isteği gönderilecektir. İstek, geçerli kullanıcı hesabından gelmemişse herhangi bir işlem yapılmayacak, geçerli bir kullanıcı hesabından gelmişse işlem yapılacaktır. Saldırganın hazırlamış olduğu sitenin adresi
http://www.attacker.com/index.html
olsun. Sayfa içerisine aşağıdaki kod parçacığı konulsun:
<html>
    …
<img src=www.shopping.com/admin?cmd=deleteall width=0 height=0 />
<html>
 CSRF için bir saldırı senaryosu şu şekilde gerçekleşecektir; bir kullanıcı alışveriş sitesinde  kendi hesabıyla oturum açıyor ve sitede gezinmeye başlıyor ve sepetine bazı şeyler ekliyor. Bu sırada saldırganın hazırlamış olduğu betik içeren sayfayı açıyor. Saldırganın hazırlamış olduğu sayfada bulunan <img> etiketi ile sepetindekileri silecek istek alışveriş sitesine gönderiliyor ve kullanıcı sepeti boşalıyor. Burada kullanıcının oturum bilgisi isteğin oturum bilgisi olarak isteğe eklendiğinden yetkilendirme ile ilgili bir problem ortaya çıkmayacaktır ve silme işlemi gerçekleşip işlem devam edecektir.
csrf.png
Şekil 1: CSRF Saldırısı
Kullanıcının bu gönderilen istekten haberi yoktur. Burada saldırgan ciddi sonuçlar elde edebilecek başka betikler de hazırlayabilirdi. Bunun yanında bu örnekte bir “GET” isteği üretilerek saldırı gerçekleştirildi. Fakat sayfa nın “GET” isteklerini kabul etmeyip “POST” isteklerini kabul etmesi saldırının gerçekleştirilemeyeceği anlamına gelmiyor[4]. Bu durumda XMLHTTP nesnesi kullanılarak saldırı gerçekleştirilebilirdi. Buna örnek olarak her türlü güvenlik önlemi alınan İnternet ortamındaki bazı önemli denebilecek sitelerdeki CSRF zafiyeti örnek gösterilebilir. Bunların arasında, New York Times (nytimes.com), ING Direct, Metafilter ve YouTube gibi çok kullanılan siteler mevcuttur. Fakat şu anda bu sitelerdeki açıklık kapatılmış durumdadır[2]. ING Direct bankasında bulunan zaafiyet ile kullanıcı hesabından saldırgan hesabına para transferi yapılabiliyordu. Aynı şekilde saldırgan YouTube kullanıcısının favori videolarına istediği videoları ekleyebiliyor hatta kullanıcının sadece ailesinin ve arkadaşlarının izlemesine izin verdiği videolara erişebiliyordu.

CSRF Zafiyetinin Farkına Varmak

Web geliştiricileri ya da web güvenlik testi yapanlar, bir sitede CSRF saldırısına karşı bir zaafiyetin olup olmadığını anlamaları için şu şekilde bir yol takip edebilirler Paros, Burp Suite gibi web proxy kullanılarak siteden sabit url ve POST ile yapılan istekler kaydedilir. Daha sonra kaydedilen bu istekler proxy’deki repeater özelliği ile tekrarlandığında daha önce karşılaşılan aynı sonuçlar alınıyorsa sitenin ilgili kısmında CSRF saldırısına karşı zaafiyet vardır sonucu çıkarılabilir. Bu sitenin tüm sayfaları için ya da kullanıcı için önemli sayfalarda denenerek sitedeki tüm açıklıklar bulunabilir.   

CSRF Açıklıklarının Önlemleri

CSRF saldırısı yetkili kullanıcıların yapacağı aktivitelerde başarıya ulaşırsa çok daha etkili olacaktır. Bu saldırının uygulamada yetkilendirilmiş kullanıcı sayfaları için gerçekleştirildiğini düşünerek alınabilecek önlemler çıkarılabilir. Bazıları tam olarak korumasa da korumaya yardımcı bir etken olarak kullanılabilir. Bunun yanında bu metotların avantajları ya da dezavantajları vardır. Geliştirici uygulamanın kritikliğine, performansına, metodun uygulanabilirliğine göre uygun koruma metodunu seçebilir. Bu bağlamda kullanıcı oturum kontrolü saldırıyı engellemeyecektir. Çünkü, istemci tarafından zorla üretilen isteğe kullanıcının o andaki oturum bilgisi eklenecek ve geçerli oturum bilgisiyle gönderilecektir. Her sayfada, kullanıcıdan hesap bilgilerinin girilmesinin beklenmesi uygulamanın kullanım verimliliğini ciddi şekilde etkileyecektir. Sunucu tarafında alınabilecek önemler şu sekilde sıralanabilir:
  1. HTTP “referer” başlığı ile sitenin kendisinden üretilen istekle istemcinin haberi olmadan başka bir site üzerinden zorla ürettiği istek ayırt edilebilir[5]. Fakat “referer” kullanılması site sahibinin arama sitelerinde daha iyi bir yer edinebilmesini sağlaması açısından faydalı olmasına karşın kullanıcıların özel bilgilerini ortaya çıkaracaktır. Bu durum da site kullanıcılarını rahatsız edebilir[6].  Bunun yanında HTTPS bağlantılarında “referer” kullanımı daha etkilidir. HTTP bağlantılarında “referer” saldırgan tarafından kullanıcı tarayıcısında kullanımını egelleyebileceğinden çok da etkili olmayacaktır.
  2. GET metodunu sadece veri okunan kısımda kullanmak, verileri değiştiren isteklerde kullanmamak. Böylece IMG etiketi ve diğer GET ile yapılan saldırı yollarından korunulabilecektir. Ama POST isteği ile gelen saldırılara karşı hala zaafiyet vardır.
  3. Bütün POST isteklerinde rasgele üretilen kriptografik değer üretilir. Üretilen bu değeri cookie bilgisi içinde kullanıcı bilgisayarında saklanır. Kullanıcı tarafından yapılan form gönderimlerinde form değerini ve kullanıcı cookie değerini alarak bu değerlerin aynı olması beklenir. Çünkü saldırgan sadece form değerini istedği gibi değiştirebilir bunun yanında cookie değerini bilemeyecektir, ancak tahmin etmek durumunda kalacaktır. Bu önlemin dezavantajı bir pencerede açılan aynı form sekmelerinde, açılan son formun işlem görecek olmasıdır. İlk form yeni değerin oluşturulmasıyla, değerleri eşit olamayacağından işlem yapılamayacaktır.
  4. Kullanıcı oturumunda tutulan rasgele değer üretmek, bu değeri oturum bilgisinde saklamak ve istemci tarafında “hidden” değer olarak göndermek. İstemci tarafından gelen bu değerin oturumda tutulan değerle aynı olması beklenir. Aşağıda istemci tarafında gönderilen değerin kullanımı şu şekilde olabilir:
<form …>
<input type=”hidden” name=”csrf value”value=”8dcb5e56904d9b7d4bbf333afdd154ca”>
134 Okunma 07 Nis 2014

Yorumlar


Sen de Yorumla!