Bu sayfa Google Translate ile otomatik çevrilmiştir. Özgün metin Türkçedir. Özgün dile dön

Siber Güvenlik

CSRF Saldırısı Nedir?

CSRF Saldırısı Nedir?

Web uygulamalarında kimlik doğrulama süreçleri çoğunlukla tarayıcı tabanlı oturum çerezleri (cookies) üzerinden yürütülür. Bir kullanıcı bir web sitesine giriş yaptığında, sunucu istemciye bir oturum tanımlayıcısı gönderir ve tarayıcı bu bilgiyi saklar. Daha sonra o siteye yapılan her istekte tarayıcı, ilgili çerezi otomatik olarak pakete dahil eder. Bu davranış, internetin kullanımını kolaylaştırsa da temel bir güvenlik açığına zemin hazırlar: Siteler Arası İstek Sahteciliği ya da bilinen adıyla CSRF.

CSRF Nedir ve Temel Mantığı Nasıl Çalışır?

Açılımı Cross-Site Request Forgery olan ve Türkçe kaynaklarda sıklıkla Siteler Arası İstek Sahteciliği olarak anılan bu zafiyet, son kullanıcının mevcut yetkilerini kötüye kullanarak haberi olmadan sunucuya istek gönderilmesini sağlar. Web geliştiricilerinin ve güvenlik analistlerinin sıklıkla araştırdığı csrf nedir sorusunun yanıtı, tarayıcıların otomatik çerez gönderme mekanizmasında yatar.

Bir CSRF saldırısında hedef, kullanıcının verilerini doğrudan çalmak değildir. CSRF, siteler arası betik çalıştırma (XSS) saldırılarından farklı olarak tarayıcıdaki oturum bilgilerini okuyamaz. Bunun yerine, hedeflenen web uygulamasının kullanıcıya duyduğu güveni suiistimal eder. Tarayıcı, istek bir bağlantıya tıklanarak mı yapıldı yoksa arkada çalışan kötü niyetli bir komut dosyası tarafından mı tetiklendi ayırt edemez; tek gördüğü, geçerli oturum çereziyle gelen yetkilendirilmiş bir HTTP isteğidir.

Bir CSRF Saldırısı Nasıl Gerçekleşir?

Saldırının başarılı olabilmesi için belirli koşulların bir araya gelmesi gerekir. Kullanıcının hedef web sitesinde aktif bir oturumunun bulunması ve hedeflenen uygulamanın gelen isteklerin kaynağını doğrulamaması şarttır.

Sürecin adım adım işleyişi şu şekildedir:

  • Kullanıcı, internet bankacılığı gibi kritik bir sisteme giriş yapar ve tarayıcısında geçerli bir oturum çerezi oluşur.
  • Kullanıcı, oturumunu kapatmadan aynı tarayıcıda başka bir sekme açar ve saldırganın kontrolündeki tuzak bir web sitesini ziyaret eder ya da zararlı bir e-posta bağlantısına tıklar.
  • Saldırganın sitesinde gizlenmiş olan kodlar, kullanıcının tarayıcısına hedef banka sunucusuna belirli parametrelerle bir istek atması komutunu verir.
  • Tarayıcı, bankanın alan adına giden bu isteğe kullanıcının tarayıcısında saklanan banka oturum çerezlerini otomatik olarak ekler.
  • Banka sunucusu, isteğin geçerli bir çerez taşıdığını görerek işlemi onaylar ve talep edilen para transferini gerçekleştirir.

Form Tabanlı POST İsteği Senaryosu

Birçok web sitesi kritik işlemleri POST metoduyla yürütür. Ancak POST metodu tek başına CSRF saldırısını engellemez. Aşağıdaki HTML kodu, saldırganın kendi sitesine yerleştirebileceği basit bir otomatik gönderim formunu göstermektedir:

<form action="http://ornek-banka.com/hesap/transfer" method="POST" id="csrfForm">
  <input type="hidden" name="alici" value="saldirgan_hesap_no" />
  <input type="hidden" name="miktar" value="10000" />
</form>
<script>
  document.getElementById('csrfForm').submit();
</script>

Bu örnekte yer alan kod parçası, sayfa yüklendiği anda JavaScript yardımıyla formu otomatik olarak hedeflenen adrese postalar. Kurban sayfayı açtığında hiçbir butona tıklamasa bile transfer isteği onun yetkisiyle hedefe ulaşır.

GET Metodu Üzerinden Gerçekleştirilen İstekler

Durum değiştiren (veritabanında kayıt silen, şifre değiştiren veya veri güncelleyen) işlemlerin GET istekleriyle yürütülmesi, CSRF riskini katbekat artırır. Saldırgan bu durumda JavaScript çalıştırmaya bile gerek duymaz.

<img src="https://ornek-uygulama.com/profil/sifre-sifirla?yeni_sifre=123456" width="0" height="0" />

Tarayıcı, görseli yüklemek için belirtilen URL adresine bir GET isteği yapar. Kullanıcının oturumu açıksa, şifre sıfırlama işlemi arka planda sessizce gerçekleşir. Bu nedenle HTTP standartlarına göre GET istekleri yalnızca veri okuma amaçlı olmalı, asla sistem üzerinde kalıcı değişiklik yaratmamalıdır.

CSRF Saldırılarından Korunma Yöntemleri

CSRF açıklarını kapatmak, kullanıcı tarafında değil tamamen sunucu ve uygulama mimarisi tarafında alınacak önlemlere bağlıdır. Modern web uygulamalarında bu açığı engellemek için kabul görmüş standart yaklaşımlar bulunmaktadır.

Anti-CSRF Belirteci (Token) Kullanımı

CSRF korumasının temel taşı “Synchronizer Token Pattern” yöntemidir. Bu yapıda, sunucu her kullanıcı oturumu veya her form için kriptografik olarak güvenli, tahmin edilemez ve tekil bir belirteç (token) üretir.

<form action="/profil/guncelle" method="POST">
  <input type="hidden" name="csrf_token" value="e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" />
  <input type="text" name="eposta" />
  <button type="submit">Kaydet</button>
</form>

Kullanıcı formu gönderdiğinde, sunucu formdan gelen csrf_token değeri ile kullanıcının oturumunda saklanan değeri karşılaştırır. Saldırgan, üçüncü taraf bir siteden istek gönderirken kurbanın hesabına atanmış bu gizli belirteci bilemeyeceği için istek sunucu tarafından reddedilir.

SameSite Çerez Özniteliği

Modern tarayıcılar, çerezlerin hangi durumlarda isteklerle birlikte gönderileceğini belirleyen SameSite niteliğini destekler. Çerez tanımlanırken bu parametrenin ayarlanması CSRF riskini büyük ölçüde ortadan kaldırır.

Set-Cookie: oturum_id=abc123xyz; Secure; HttpOnly; SameSite=Lax

Bu başlıkta yer alan yapılandırma seçenekleri şu şekildedir:

  • Strict: Çerez, yalnızca istek doğrudan sitenin kendi içinden yapıldığında gönderilir. Dışarıdan verilen hiçbir bağlantıda çerez iletilmez.
  • Lax: Varsayılan güvenli seçenektir. Üçüncü taraf sitelerden gelen POST veya iframe isteklerinde çerez gönderilmez; yalnızca üst düzey (top-level) gezinme sağlayan güvenli bağlantı tıklamalarında (GET) iletilir.
  • None: Çerez her koşulda iletilir. Bu seçeneğin çalışması için Secure özniteliğiyle birlikte HTTPS üzerinden kullanılması zorunludur ve CSRF koruması sağlamaz.

Özellikle sunucusuz (stateless) mimarilerde veya API odaklı tek sayfa uygulamalarında (SPA) oturum durumunu sunucuda saklamak maliyetli olabilir. Çift çerez gönderimi yönteminde, rastgele bir belirteç hem çerez olarak istemciye verilir hem de yapılacak isteklerde bir başlık (header) veya form alanı olarak talep edilir.

İstemci tarafındaki meşru JavaScript kodu çerezden bu değeri okuyup isteğin başlığına ekler:

fetch('/api/veri-kaydet', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-CSRF-TOKEN': 'belirtec_degeri'
  },
  body: JSON.stringify({ veri: 'test' })
});

Aynı Köken Politikası (Same-Origin Policy) gereği, saldırgan üçüncü taraf bir siteden kurbanın çerezini doğrudan okuyamaz. Dolayısıyla isteğin gövdesine veya başlığına bu belirteci ekleyemez. Sunucu, başlıktaki değer ile çerezdeki değeri karşılaştırarak doğrulamayı tamamlar.

Özet ve Sonraki Adımlar

CSRF, tarayıcıların otomatik kimlik doğrulama mekanizmalarını istismar eden ve kritik işlemlerin yetkisiz biçimde yürütülmesine yol açan önemli bir güvenlik zafiyetidir. Yalnızca GET metodunun veri değiştiren işlemlerde kullanılmaması tek başına yeterli değildir; mutlaka Anti-CSRF belirteçleri ve doğru yapılandırılmış SameSite çerez politikaları devreye alınmalıdır.

Uygulamanızın güvenliğini artırmak için ilk adım olarak tüm durum değiştiren uç noktalarınızı (endpoints) gözden geçirin, oturum çerezlerinize SameSite=Lax veya SameSite=Strict bayraklarını ekleyin ve kullandığınız web çatısının (framework) yerleşik CSRF koruma katmanlarının aktif olduğundan emin olun.

#csrf#siber güvenlik#uygulama güvenliği#web gelistirme#web guvenligi

Comments

No comments yet. Write the first comment.

Write a comment

Comments are published after admin approval.