CSRF (Cross-Site Request Forgery), kullanıcının oturum açık olduğu bir sitede, haberi olmadan istek yaptırılmasıdır. Saldırgan kullanıcının parolasını bilmez; tarayıcının çerezleri otomatik göndermesinden yararlanır. Kullanıcı başka bir sayfayı gezerken, arka planda bankasına veya yönetim paneline istek gönderilmiş olabilir.
Nasıl çalışır?
- Kullanıcı
panel.ornek.com'a giriş yapmıştır; oturum çerezi tarayıcıdadır. - Başka bir sekmede saldırganın hazırladığı sayfayı açar.
- Bu sayfa görünmez bir form ile
panel.ornek.com/kullanici/eposta-degistiradresine istek gönderir. - Tarayıcı çerezi otomatik ekler; panel isteği meşru kullanıcıdan gelmiş gibi işler.
<form action="https://panel.ornek.com/eposta-degistir" method="post">
<input type="hidden" name="eposta" value="saldirgan@example.com">
</form>
<script>document.forms[0].submit()</script>E-posta değiştikten sonra saldırgan "parolamı unuttum" ile hesabı ele geçirebilir.
Savunmalar
1. Anti-forgery token
Sunucu, her formda tahmin edilemez bir token gönderir ve istekte bu token'ı doğrular. Saldırganın sayfası bu token'ı okuyamadığı için sahte istek reddedilir.
ASP.NET Core MVC ve Razor Pages'te form etiket yardımcıları token'ı otomatik ekler ve doğrulama varsayılan olarak etkindir. Minimal API'lerde form tabanlı uç noktalar için antiforgery ara katmanı etkinleştirilmelidir.
2. SameSite çerezler
Çerezlerin SameSite özniteliği, başka sitelerden gelen isteklerde gönderilip gönderilmeyeceğini belirler:
| Değer | Davranış |
|---|---|
| Strict | Başka siteden gelen hiçbir istekte gönderilmez |
| Lax | Üst düzey gezinmelerde (bağlantıya tıklama) gönderilir, arka plan POST isteklerinde gönderilmez |
| None | Her durumda gönderilir (Secure zorunlu) |
Modern tarayıcılar özniteliği belirtilmeyen çerezlere çoğunlukla Lax davranışı uygular; bu, CSRF riskini önemli ölçüde azaltmıştır. Yine de tarayıcı farklılıkları ve alt alan adı senaryoları nedeniyle tek başına güvenilmemeli, token ile birlikte kullanılmalıdır.
3. GET istekleri durum değiştirmemeli
Silme, güncelleme ve ödeme gibi işlemler asla GET ile yapılmamalıdır. Bir görsel etiketi bile GET isteği tetikleyebilir. Bkz. REST API.
4. Kritik işlemlerde yeniden doğrulama
E-posta, parola veya ödeme bilgisi değişikliklerinde mevcut parolanın veya ikinci faktörün istenmesi ek bir kalkan oluşturur.
API'lerde durum
Kimlik bilgisini çerez yerine Authorization başlığında taşıyan API'ler (örneğin JWT ile) klasik CSRF'e karşı doğal olarak korunur; çünkü tarayıcı bu başlığı otomatik eklemez. Ancak API çerez tabanlı kimlik doğrulama kullanıyorsa aynı korumalar gerekir. CORS ayarlarının gevşek tutulması (her kaynağa kimlik bilgisiyle izin vermek) bu korumayı da zayıflatır.
Sık yapılan hatalar
- Token doğrulamasını "hata veriyor" diye kapatmak
- Durum değiştiren işlemleri GET ile yapmak
SameSite=Noneçerezleri gereksiz yere kullanmak- XSS açığı bulunan sitede CSRF korumasının anlamsızlaşacağını unutmak; XSS ile token da okunabilir. Bkz. XSS
Sık sorulan sorular
CSRF hâlâ güncel bir tehdit mi?
SameSite varsayılanları riski azaltmış olsa da yanlış yapılandırmalar, eski tarayıcılar ve özel senaryolar nedeniyle güncelliğini korur.
Tek sayfalık uygulamalarda CSRF olur mu?
Kimlik doğrulama çerezle yapılıyorsa evet. Çerez tabanlı SPA'larda token veya özel başlık kontrolü uygulanmalıdır.
Sonuç
CSRF, tarayıcının iyi niyetli davranışını istismar eder. Anti-forgery token, doğru SameSite ayarları ve durum değiştirmeyen GET istekleri; bu saldırıya karşı basit ama etkili bir savunma oluşturur. Diğer riskler için bkz. OWASP Top 10.
