CSRF: Siteler Arası İstek Sahteciliği ve Korunma Yolları

Güvenlik açıkları arasında en kafa karıştırıcı olanlardan biri CSRF'tir; açık adıyla "Cross-Site Request Forgery", yani siteler arası istek sahteciliği. Kafa karıştırıcıdır çünkü XSS'in aksine burada saldırgan sizin sitenize hiç kod enjekte etmez. Bunun yerine kullanıcının tarayıcısındaki mevcut güveni kötüye kullanır. Kullanıcı sitenize giriş yapmıştır, tarayıcısında geçerli bir oturumu vardır; saldırgan tam da bu oturumu kullanarak kullanıcı adına istenmeyen işlemler yaptırır.

Bu yazıda CSRF'in nasıl çalıştığını, neden bu kadar sinsi olduğunu ve en önemlisi uygulamanızı bu saldırıya karşı nasıl koruyacağınızı somut biçimde ele alacağız. Konuyu netleştirdiğinizde, korunmanın aslında birkaç sağlam prensibe indiğini göreceksiniz.

CSRF Nasıl Çalışır?

CSRF'i anlamanın anahtarı, tarayıcıların çerezleri nasıl gönderdiğini bilmektir. Bir siteye giriş yaptığınızda tarayıcınız bir oturum çerezi saklar. Bundan sonra o siteye gönderilen her istekte tarayıcı bu çerezi otomatik olarak ekler — istek nereden tetiklenmiş olursa olsun. İşte CSRF bu otomatik davranışı istismar eder.

Senaryo şöyle işler: Kullanıcı bankasının veya bir e-ticaret sitesinin oturumunu açık bırakır. Aynı tarayıcıda saldırganın hazırladığı zararlı bir sayfayı ziyaret eder. Bu sayfa, arka planda gizlice hedef siteye bir istek gönderir — örneğin bir para transferi, bir şifre değişikliği veya bir sipariş. Tarayıcı, kullanıcının geçerli oturum çerezini bu isteğe otomatik eklediği için hedef site isteği meşru sanır ve işlemi gerçekleştirir. Kullanıcı hiçbir şeyin farkında bile değildir.

CSRF'in özü şudur: saldırgan sizin kimliğinizi çalmaz; sadece tarayıcınızın halihazırda taşıdığı kimliği, sizin haberiniz olmadan kullanır.

CSRF Neden Bu Kadar Sinsidir?

CSRF'i tehlikeli yapan birkaç özellik vardır. Öncelikle kullanıcı hiçbir hata yapmaz; sadece yanlış bir zamanda yanlış bir bağlantıya tıklar. İkincisi, saldırının kanıtını bulmak zordur çünkü istek tamamen meşru bir kullanıcının meşru oturumundan gelir. Sunucu tarafında her şey normal görünür. Üçüncüsü, saldırı görünür bir arayüz gerektirmez; zararlı istek gizli bir form, bir resim etiketi veya arka planda çalışan bir script ile tetiklenebilir.

CSRF ile bir saldırganın yapabilecekleri, kullanıcının o sitede yapabildiği her şeyle sınırlıdır:

• Kullanıcının şifresini veya e-posta adresini değiştirmek (hesabı ele geçirmenin ilk adımı).
• Kullanıcı adına para transferi veya satın alma yapmak.
• Yönetici panelinde ayar değiştirmek veya yeni kullanıcı eklemek.
• Kullanıcının profilini veya verilerini silmek.

Temel Savunma: CSRF Token

CSRF'e karşı en yaygın ve en etkili savunma, CSRF token (anti-CSRF token) kullanmaktır. Fikir basittir: sunucu, her oturuma veya her forma tahmin edilemez, rastgele bir gizli değer atar. Bu token, formun içine gizli bir alan olarak yerleştirilir. Kullanıcı formu gönderdiğinde token da isteğe dahil olur ve sunucu bunu doğrular.

Bu savunmanın gücü şudur: saldırganın hazırladığı zararlı sayfa, kullanıcının oturumuna özel bu token'ı bilemez. Çünkü token her oturumda farklıdır ve saldırgan onu okuyamaz (aynı kaynak politikası buna izin vermez). Dolayısıyla saldırganın gönderdiği sahte istekte geçerli token bulunmaz ve sunucu isteği reddeder.

CSRF Token Nasıl Doğru Kullanılır?

• Rastgelelik: Token kriptografik olarak güvenli, tahmin edilemez bir değer olmalıdır.
• Oturuma bağlılık: Her kullanıcı oturumu kendi token'ına sahip olmalı, token sunucuda saklanmalıdır.
• Her durum değiştiren istekte: Form gönderimleri, silme, güncelleme gibi tüm "yazma" işlemlerinde token doğrulanmalıdır.
• Doğrulama: Sunucu, gelen token ile saklanan token'ı karşılaştırmalı; eşleşmezse isteği reddetmelidir.

Modern framework'lerin neredeyse tamamı CSRF token mekanizmasını yerleşik olarak sunar. Örneğin bir formu oluştururken tek bir yardımcı fonksiyon token'ı otomatik ekler ve gelen istek middleware düzeyinde doğrulanır. Bu koruma çoğu zaman varsayılan olarak açıktır; kapatmadığınız sürece güvendesiniz.

İkinci Katman: SameSite Çerezler

Modern tarayıcılar, CSRF'e karşı güçlü bir yerleşik savunma sunar: SameSite çerez özniteliği. Bu öznitelik, tarayıcıya çerezin başka bir siteden gelen isteklerde gönderilip gönderilmeyeceğini söyler. Üç değeri vardır:

• Strict: Çerez yalnızca aynı siteden gelen isteklerde gönderilir. En güçlü korumadır ama bazı kullanıcı deneyimi senaryolarını zorlaştırabilir.
• Lax: Çerez, çoğu üçüncü taraf isteğinde gönderilmez ama üst düzey gezinmelerde (bir bağlantıya tıklamak gibi) gönderilir. Denge açısından çoğu site için idealdir ve modern tarayıcılarda varsayılandır.
• None: Çerez her durumda gönderilir; yalnızca Secure bayrağıyla birlikte kullanılmalıdır ve CSRF açısından risklidir.

Oturum çerezinizi SameSite=Lax veya uygunsa Strict olarak ayarlamak, birçok CSRF senaryosunu tarayıcı düzeyinde daha uygulamaya ulaşmadan engeller. Ancak SameSite tek başına yeterli değildir; token ile birlikte katmanlı kullanılması en sağlam yaklaşımdır.

Güvenlikte tek bir savunmaya güvenmek risklidir. CSRF token ile SameSite çerezleri birlikte kullanmak, birinin atlatıldığı durumda diğerinin devreye girmesini sağlar.

Ek Önlemler

Doğru HTTP Metodları

Durum değiştiren işlemler (silme, güncelleme, oluşturma) asla GET isteğiyle yapılmamalıdır. GET istekleri bir bağlantı veya resim etiketiyle kolayca tetiklenebilir. Bu tür işlemleri POST, PUT veya DELETE gibi metodlarla yapmak, en azından basit CSRF denemelerini zorlaştırır. Bu tek başına yeterli bir savunma değildir ama iyi bir hijyen kuralıdır.

Kritik İşlemlerde Yeniden Doğrulama

Şifre değişikliği, e-posta güncelleme veya para transferi gibi çok kritik işlemlerde kullanıcıdan mevcut şifresini yeniden istemek etkili bir ek katmandır. Saldırgan kullanıcının şifresini bilmediği için bu adımı geçemez. Özellikle hesap ele geçirmeye giden yolları kapatmak için değerlidir.

Referer ve Origin Kontrolü

Sunucu, gelen isteğin Origin veya Referer başlığını kontrol ederek isteğin gerçekten kendi sitenizden gelip gelmediğini doğrulayabilir. Bu başlıklar her zaman güvenilir olmasa da ek bir doğrulama katmanı sunar ve token ile birlikte kullanıldığında koruma gücünü artırır.

CSRF ve KVKK Bağlamı

Türkiye'de faaliyet gösteren bir e-ticaret sitesi veya müşteri paneli için CSRF ihmali ciddi sonuçlar doğurabilir. Bir saldırgan CSRF yoluyla müşteri hesaplarını ele geçirir veya kişisel verileri değiştirirse, bu doğrudan bir veri güvenliği ihlali sayılır ve KVKK kapsamında sorumluluğunuz doğar. Güvenlik önlemlerini "makul teknik tedbir" kapsamında almak yalnızca iyi mühendislik değil, aynı zamanda yasal bir yükümlülüktür.

CSRF Korunma Kontrol Listesi

1. Tüm durum değiştiren formlar ve isteklerde CSRF token doğrulaması var mı?
2. Oturum çerezleri SameSite=Lax veya Strict olarak yapılandırıldı mı?
3. Durum değiştiren işlemler GET yerine POST/PUT/DELETE ile mi yapılıyor?
4. Şifre ve e-posta değişikliği gibi kritik işlemlerde yeniden kimlik doğrulama isteniyor mu?
5. Framework'ün yerleşik CSRF koruması etkin ve doğru yapılandırılmış mı?
6. API uçları için token tabanlı kimlik doğrulama (örneğin özel başlıklar) kullanılıyor mu?

Sık Sorulan Sorular

CSRF ile XSS aynı şey mi? Hayır, tamamen farklıdır. XSS'te saldırgan sitenize kod enjekte eder ve kullanıcının tarayıcısında çalıştırır. CSRF'te ise hiç kod enjekte edilmez; saldırgan yalnızca kullanıcının mevcut oturumunu istismar eder. Not: bir XSS açığı, çoğu CSRF korumasını da atlatabilir; bu yüzden ikisini birlikte ele almak gerekir.

Token kullanıyorsam SameSite'a gerek var mı? Gerek vardır. Güvenlik katmanlı olmalıdır. SameSite tarayıcı düzeyinde ek bir kalkan sağlar ve token mekanizmasının bir şekilde atlatıldığı senaryolarda devreye girer.

Tamamen API tabanlı bir uygulamada CSRF risk mi? Eğer kimlik doğrulama çerez yerine özel bir başlıkta taşınan token ile yapılıyorsa CSRF riski büyük ölçüde azalır; çünkü tarayıcı özel başlıkları otomatik eklemez. Ancak çerez tabanlı oturum kullanıyorsanız risk devam eder.

Sonuç

CSRF, ilk bakışta anlaşılması zor görünen ama korunması aslında oldukça net olan bir açıktır. CSRF token'ları, SameSite çerezleri, doğru HTTP metodları ve kritik işlemlerde yeniden doğrulama bir araya geldiğinde, uygulamanız bu tehdide karşı sağlam biçimde korunur. En güzel yanı, modern framework'lerin bu korumaların çoğunu hazır sunmasıdır; sizin yapmanız gereken onları doğru yapılandırmak ve kapatmamaktır.

Uygulamanızın CSRF ve diğer oturum güvenliği açıklarına karşı ne kadar dayanıklı olduğunu denetlemek ve gerekli sıkılaştırmaları uygulamak için projenizi konuşalım. Kullanıcılarınızın güvenini korumak, en değerli yatırımlardan biridir.