CSRF (Siteler Arası İstek Sahteciliği) Nedir?
Kısa tanım
CSRF (Cross-Site Request Forgery), kullanıcının oturum açık olduğu bir siteye, başka bir sitenin kullanıcının tarayıcısı üzerinden ve onun haberi olmadan durum değiştiren bir istek göndermesine dayanan saldırı türüdür. Tarayıcı çerezleri isteğe otomatik eklediği için sunucu isteği meşru sanabilir. Başlıca önlemler SameSite çerez özniteliği, CSRF token'ları ve isteğin kaynağının doğrulanmasıdır.
Diğer adları: Cross-Site Request Forgery, XSRF, siteler arası istek sahteciliği, CSRF token, session riding
Sorunun kaynağı: otomatik gönderilen kimlik bilgisi
Bir siteye giriş yaptığınızda tarayıcı bir oturum çerezi saklar ve o siteye giden her isteğe bu çerezi kendiliğinden ekler. CSRF bu davranıştan yararlanır. Kullanıcı başka bir sekmede kötü niyetli ya da ele geçirilmiş bir sayfayı açtığında, o sayfa kullanıcının tarayıcısından hedef siteye bir form gönderimi tetikleyebilir. İstek kullanıcının tarayıcısından geldiği ve geçerli çerezi taşıdığı için, ek bir kontrol yoksa sunucu açısından kullanıcının kendi isteğinden farkı yoktur.
Saldırgan yanıtı göremez; CSRF'in amacı veri okumak değil, bir eylem yaptırmaktır. E-posta adresini değiştirmek, bir yöneticiyi panele eklemek, sipariş vermek ya da ayarları değiştirmek tipik hedeflerdir.
Hangi uç noktalar risk altında?
- Durum değiştiren ve çerezle kimlik doğrulayan istekler. Asıl risk alanı budur.
- Durum değiştiren GET istekleri.
/hesap/sil?id=5gibi bir bağlantı tek bir görsel etiketiyle bile tetiklenebilir. GET istekleri yalnızca okuma yapmalıdır. - Giriş formu. "Login CSRF" denen türde kullanıcı fark etmeden saldırganın hesabına giriş yaptırılır ve sonraki işlemleri o hesaba kaydedilir.
Kimliği Authorization başlığındaki bir token ile doğrulayan API'ler bu sınıfa büyük ölçüde girmez, çünkü tarayıcı bu başlığı başka bir siteden gelen isteğe kendiliğinden eklemez. Aynı token bir çerezde tutuluyorsa risk geri gelir.
Katmanlı savunma
| Önlem | Nasıl çalışır? | Sınırı |
|---|---|---|
| CSRF token | Sunucu oturuma bağlı, tahmin edilemez bir değer üretir; form ya da özel başlık bu değeri taşımazsa istek reddedilir | Doğru uygulanırsa ana savunmadır; XSS varsa token okunabilir |
| SameSite çerez özniteliği | Lax ya da Strict değerli çerezler başka sitelerden gelen POST isteklerine eklenmez | Aynı "site" sayılan kardeş alt alan adlarına karşı korumaz; tek başına yeterli kabul edilmez |
| Origin ve Fetch Metadata kontrolü | Sunucu Origin ya da Sec-Fetch-Site başlığına bakarak başka siteden gelen durum değiştiren istekleri reddeder | Eski istemcilerde başlık eksik olabilir; yedek kural gerekir |
Set-Cookie: oturum=…; Secure; HttpOnly; SameSite=Lax
<form method="post" action="/hesap/e-posta">
<input type="hidden" name="csrf_token" value="(oturuma bağlı rastgele değer)">
<input type="email" name="yeni_eposta">
<button>Kaydet</button>
</form>Django, Rails, Laravel ve benzeri çatıların çoğu CSRF token korumasını hazır sunar; en yaygın hata, bir entegrasyon çalışmayınca bu korumayı uç nokta bazında kapatıp unutmaktır. OWASP'ın CSRF önleme rehberi SameSite'ı tek başına değil, ek bir katman olarak önerir.
Sık karıştırılan noktalar
- "CORS ayarlı, CSRF'e gerek yok." CORS yanıtın okunmasını kısıtlar; basit bir form gönderimi sunucuya yine ulaşır ve işlenir.
- "HttpOnly çerez CSRF'i önler." HttpOnly yalnızca JavaScript'in çerezi okumasını engeller; tarayıcı çerezi isteğe eklemeye devam eder.
- Token'ı URL'de taşımak. Sorgu parametresindeki token, sunucu günlüklerine ve tarayıcı geçmişine düşer.
- XSS'i ayrı bir konu sanmak. Sitede XSS açığı varsa saldırgan betiği token'ı okuyup isteği kendisi gönderebilir; CSRF savunmaları XSS karşısında işe yaramaz.