blog posts

CSRF güvenlik açığı nedir?

CSRF teriminin Siteler Arası İstek sahteciliği anlamına geldiğini, kelimenin tam anlamıyla istek sahteciliği saldırıları anlamına geldiğini söylemiştik. Bu hata veya güvenlik açığı aynı zamanda deniz sörfü, XSRF, oturum sürme, düşmanca bağlantı ve tek tıklama saldırısı olarak da bilinir. Söylediğimiz gibi bu güvenlik açığı sunucu tarafındadır ve bankacılık hizmetleri, çevrimiçi mağazalar, eğitim merkezleri vb. gibi kimlik doğrulama sistemine sahip web sitelerinin çoğu bu saldırıdan zarar görmektedir.

Bu saldırı türünde saldırgan, kullanıcıları istediği eylemleri yapmaya zorlamak için CSRF zafiyetini kullanır, aslında saldırgan, kurban kullanıcının yardımıyla isteğini sunucuya gönderir. Bu tür bir güvenlik açığı, saldırganın SOP (Aynı Kaynak Politikası) politikalarını atlamasına olanak tanır.

CSRF saldırısının etkileri nelerdir?

CSRF saldırılarında saldırgan, mağdur kullanıcıyı istenmeyen eylemler gerçekleştirmeye zorlayabilir ve uygulama performansı düzeyine ve mağdur kullanıcının erişim düzeyine bağlı olarak, birkaç durumu anlatacağımız farklı zararlara neden olabilir:

• Basit düzeyde, CSRF güvenlik açığının yardımıyla saldırgan, kurban kullanıcıların şifresini, e-postasını vb. değiştirebilir.

• Kullanıcıların içerik yayınlayabildiği web sitelerinde saldırgan, mağdurun hesabıyla istediği içeriği yayınlayabilmektedir.

• Bu güvenlik açığının bulunduğu bankacılık uygulamalarında saldırgan, mağdur kullanıcının hesabı ve kimliğiyle para transferi gerçekleştirebiliyor.

• Saldırgan, mağdur kullanıcının seviyesine bağlı olarak farklı eylemler gerçekleştirebilir, örneğin üst düzey bir kullanıcı olması durumunda, uygulama bilgilerini de değiştirebilir.

Bu saldırı ilk kez nasıl keşfedildi?

Bu saldırı ilk olarak 4 Ekim 2005’te MySpace sosyal ağında Samy adlı bir solucan tarafından gerçekleşti. Bu saldırıda, 20 saat içinde, bu sosyal ağın bir milyondan fazla kullanıcısının profil resmi “Ama hepsinden önemlisi, Samy benim kahramanım” yazısı olarak değiştirildi, bu da Samy’nin en çok benim kahramanım olduğu anlamına geliyordu ve Saldırıya uğrayan kişiler istemeden Samy isimli hesapla arkadaşlık isteği göndermişler. Sami’nin aslında 1364’te Amerika’da doğmuş bir bilgisayar korsanlığı uzmanı ve İranlı girişimci olan Sami Kamkar olduğunu bilmek ilginçtir.

CSRF güvenlik açığı nasıl çalışır?

Bir CSRF güvenlik açığı saldırısının mümkün olabilmesi için her birini dikkate alacağımız üç temel koşul vardır:

Saldırgan için olumlu eylem

Aslında web sitelerinde bazı veriler üzerinde gerçekleştirilebilecek e-posta, şifre değiştirme vb. olası eylemler bu alandaki saldırganlar için arzu edilen bir durumdur ve bunları yapmak için nedenleri vardır.

Çerezlere dayalı oturum yönetimi

Bazı eylemlerin gerçekleştirilmesi bir HTTP isteği gönderilmesini gerektirir ve eğer web sitesi kullanıcıyı tanımlamak için yalnızca çerezlere dayanıyorsa ve kullanıcı oturumunu tanımlamak ve doğrulamak için başka bir yol yoksa CSRF saldırısı mümkündür.

• Web sitesi dönüşüm oranını optimize etme ve artırma

İstek parametrelerini tahmin etme imkanı

Web sitelerinde bazı işlemlerin linkler yardımıyla yapıldığı söylendi. CSRF saldırısını önlemek için istek parametreleri belirtilmemelidir. Örneğin gün değiştirme talebinde ilgili parametre kullanıcının mevcut şifresini gösteriyorsa saldırgan kolaylıkla saldırı yapabilir.

CSRF güvenlik açıklarının türleri nelerdir?

CSRF açıkları uygulanma şekline göre üç kategoriye ayrılmaktadır. Elbette çoğu zafiyette saldırgan, sosyal mühendislik teknikleri yardımıyla saldırısını tamamlamak için kurban kullanıcıyı kullanır .

GET yöntemi senaryosu

Bu senaryoda saldırıya uğrayan web sitesi, para transferi, hesap bilgilerinin değiştirilmesi gibi bazı önemli işlemler için GET yöntemini kullanıyor. Bu yöntem, çerezlere dayalı kimlik doğrulamayla birlikte CSRF’yi savunmasız bırakan en büyük hatalardan biridir. Bu yöntemde saldırgan, kurbanı sahte bir istek göndermeye yönlendirmek için sosyal mühendislik tekniklerini kullanır. Saldırgan, bağlantı kodu, etiket ve cazip metinlerin yardımıyla kurbanı tuzağa düşürür. Sonunda saldırgan istediği linke, GET metoduna tıklayıp, çerezler ile istek göndererek saldırısını tamamlar. Bu senaryoyu daha iyi anlamak için aşağıdaki örneği okuyun.

Örnek: Bir bankacılık uygulamasında saldırgan, 6037 numaralı varsayımsal karta 5 milyon toman yatırmak istiyor ve tutarı ve alıcının kart numarasını belirledikten sonra transfer seçeneğine tıklıyor ve talebi gönderiliyor. GET yönteminde URL kodunun belirli bir düzeni vardır. Örneğin kart numarası hesap şablonuyla, tutar ise tutar parametresiyle görüntülenir ve kimlik doğrulama da çerezlere dayalı olarak yapılır. Dolayısıyla saldırganın hedef kart numarası yerine istediği kart numarasını girmesi ve mağdurun istediği sayfaya girmesi halinde tutar, saldırganın istediği hesabına yatırılacaktır. URL’nin aşağıdaki örnekteki gibi olduğunu varsayalım:

http://bank.com/transfer.do?acct=6037&amount=3000000

Artık saldırgan kendi teknikleri ve bağlantılı link ile sahte linkini kurbana gönderebiliyor ve kurban linke tıkladıktan sonra GET metoduyla ve banka çerezi yardımıyla isteği gönderiyor ve miktar şu şekilde oluyor: saldırganın istediği hesaba yatırılır. Bir örnek aşağıdaki bağlantı gibidir:

<a href http://bank.com/transfer.do?acct=6037&amount=3000000 Burayı tıklayın!</a>

Elbette bu yöntem çoğunlukla saldırganın yalnızca metin ve bağlantı gönderebildiği kısa mesaj ve web sitelerinin yorum bölümü vb. durumlarda kullanılır. Bazı durumlarda saldırgan <Img> gibi sahte etiketler kullanabilir. Bu durumlarda mağdurun tarayıcısı bu kodun sayfasını açarak saldırganın görseli bankanın web sitesine açma isteğini otomatik olarak gönderir. Evet, istek GET yöntemiyle gönderiliyor ve mağdur kullanıcı banka sitesini ve görselini göremiyor. Bu durumda görüntünün uzunluğu ve genişliği sıfıra ayarlanır. Bağlantısı aşağıdaki bağlantıya benzer:

<img src=”http://bank.com/transfer.do?width6037&amount=3000000″ width=”0″ height=”0″ border=”0″>

GET yöntemindeki CSRF saldırısının gerçek örneği

17 Ocak 2016’da HackerOne sitesinde (ünlü Bug Bunty platformu ), WeSecureApp’tan bir penetrasyon testi uzmanı tarafından twittercommerce.shopifyapps adresindeki shopify adlı Twitter ile ilgili alanlardan birinde bir güvenlik açığı olduğuna dair bir rapor sunuldu. .com. Bu alan adı, mağaza sahibinin kullanıcılarını birbirine bağlamak için oluşturuldu ve o platforma bağlı Twitter hesabını kaldırma özelliğine sahipti. Uzman, get yöntemi ve aşağıdaki URL ile hesaptan çıkış yapmanın mümkün olduğunu tespit etti

https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect/

Bu bir tür CSRF güvenlik açığıdır ve aşağıdaki kodu kavram kanıtı (poc) olarak kullandı ve ödül olarak 500 ABD doları aldı.

<html> 
<body> 
<img src=”https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect”> 
</body> 
</html>

POST yöntemi senaryosu

GET yönteminin önemli eylemler için çok tehlikeli olduğu ortaya çıktı ancak POST yöntemi CSRF güvenlik açığını kötüye kullanmanın yollarını da bıraksa da bir sonraki POST yönteminin önceki örnek gibi saldırılara karşı daha güvenli olduğu ortaya çıktı. Bu güvenlik açığını daha iyi açıklamak için aşağıdaki örneği kullanıyoruz:

Kullanıcılara e-posta adreslerini değiştirme olanağı sağlayan, com.siter adlı hayali bir web sitesi düşünün. E-postayı değiştirme talebinde bulunurken, kullanıcıyı tanımlamak için çerezlerin kullanılması, bu türe uygun e-posta değiştirme eylemi gibi CSRF güvenlik açığından yararlanmak için gereken her şeyi içeren özel bir Http kalıbıyla istek gönderilir. saldırı yapma ve bağlantıdaki parametreleri tespit etme yeteneğine sahiptir. Örneğin aşağıdaki kod:

POST /email/change HTTP/1.1 Ana Bilgisayar: Site.com İçerik Türü: application/x-www-form-urlencoded İçerik Uzunluğu: 30 Çerez: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE email= ....com

Daha sonra saldırgan, e-postanın saldırganın istediği e-postaya dönüşmesini sağlayacak şekilde parametreleri kolayca değiştirebilir. Saldırgan, sosyal mühendislik yardımıyla, kendi sitesi ve özelleştirilmiş HTTP üzerinden kurbanı savunmasız web sitesine yönlendirir ve savunmasız site, kurbanın çerezini isteğe yerleştirir ve istek otomatik olarak gönderilir ve hedef site, isteği kabul eder ve saldırıyı tamamlar. olacak Özel bağlantı aşağıdaki örnekteki gibidir:

<form action=https://site.com/email/change method=”POST”> <input type=”hidden” name=”email” value=hacker@.com /> </form> <script> belgesi. formlar[0].gönder </script>

POST yönteminde CSRF saldırısının gerçek örneği

9 Ağustos 2015’te Instacart web sitesiyle ilgili bir csrf güvenlik açığı bildirildi. Online satın alma ve ürün teslimi imkanı olan bir gıda mağazası olan bu platformda, belirli bölgelerin ürün göndericileri bulunur ve her bölgeye ait siparişler onlara atanır. Uzman, aşağıdaki bağlantıya sahip gönderenler panelindeki ürünün CSRF saldırılarına karşı savunmasız olduğunu, saldırganın özel bir html komutu ile bağlantı açıldıktan sonra gönderen alanındaki aktiviteyi tespit edip, zafiyete uğramadan değiştirebileceğini tespit etti. site biliyor..

Diğer yöntemlerin senaryosu

Diğer yöntemlerde CSRF’nin zafiyeti önceki iki senaryo kadar yüksek olmasa da yine de bilgilerin JSON formatında olması ve kimlik doğrulamanın çerezler aracılığıyla yapılması durumunda örneğin PUT yönteminde para transferi yapılması mümkündür. Saldırgan, kullanıcıdan sahte bir istekte bulunmak için bir tür XHR komutu oluşturabilir ve bunu tarayıcıda açarak paranın otomatik olarak aktarılmasını sağlar. Elbette bu yöntem uygulamalarda genellikle kullanılmıyor ve bu yöntem nedeniyle savunmasız kalma olasılığı çok düşük ancak gerekirse filtreleri değiştirmek için bu yönteme aşina olmak daha iyidir.

CSRF saldırılarını önleyin

bu saldırılarını önlemek için kullanılan birçok yöntem var, biz en yaygın olanlarından ikisini inceleyeceğiz.

CSRF belirteçleri

Saldırıları önlemenin farklı yolları vardır ancak en güvenilir yol, CSRF tokenını belirli özelliklere sahip olması gereken geçerli isteklere koymaktır; Belirteç tahmin edilemez ve rastgele olmalı, kullanıcı oturumuyla bire bir ilişkiye sahip olmalı ve herhangi bir eylemden önce doğrulanmalıdır. Ancak CSRF belirteci ile birlikte kullanılması daha iyi olan güvenliği artırmanın başka bir yolu da Samesite’yi kullanıcı oturumu çerezlerinde kullanmaktır.

Elbette token kullanımı saldırıları tamamen engellemiyor; Birçok CSRF güvenlik açığının kaynağının aslında CSRF token doğrulamasında meydana gelen hatalar olduğunu bilmek ilginç olabilir. Bunun nedenlerini kontrol etmek için aşağıdaki makaleyi izleyin:

CSRF belirteci doğrulaması istek yöntemine bağlıdır

Bazen POST yöntemini kullanırken doğrulama doğru şekilde yapılır, ancak GET yönteminde doğrulama doğru şekilde yapılmaz; Bu durumlarda saldırgan, saldırısını gerçekleştirmek amacıyla doğrulamayı atlamak için GET yöntemini kullanır.

CSRF belirteci doğrulaması, belirtecin varlığına bağlıdır

Bazı web sitelerinde doğrulama yalnızca belirteç mevcut olduğunda gerçekleştirilir; Bu durumda saldırgan, jetonun tamamını kaldırarak doğrulamayı atlar ve bir CSRF saldırısı gerçekleştirir.

CSRF belirteci aynı kullanıcının oturumuna ait değil

Bazı durumlarda web sitesi tokenın ait olup olmadığı konusunda gerekli kontrolü yapmaz, hatta bu durumda web sitesi yayınlanan tüm tokenleri kaydeder ve mevcut tokenları kabul eder; Bu durumda saldırgan siteye katılarak gerçek tokenı atarak ve bunu mağdur kullanıcının token’ı olarak kullanarak saldırısını gerçekleştirir.

CSRF jetonunu oturum çerezi dışında bir çereze yerleştirmek

Bazen web sitesi belirteci oturum çerezine koyar, ancak kullanıcıyı izlemek için kullanılan çerez olması gerekmez! Bu, web sitesinin CSRF koruması ve oturum yönetimi için iki çerçeve kullanması durumunda mümkündür.

CSRF jetonu yalnızca bir çereze kopyalanır

Bazı web siteleri yayınladıkları çerezleri sunucu tarafında saklamaz ancak her bir belirteç hem çereze hem de request parametresine yerleştirilir. Bu durumlarda, doğrulama sırasında yalnızca çerezdeki belirtecin değerinin ve kayıtlı belirtecin aynı olup olmadığı kontrol edilir. Bu şekilde kolay uygulanabilmesi nedeniyle yaygın olarak kullanılan CSRF’ye karşı savunma çözümü (Double Submit) adı verilmektedir.