CSRF Saldırıları Nedir? Web Formlarınızı Nasıl Korursunuz?

CSRF (Cross-Site Request Forgery — Siteler Arası İstek Sahteciliği), bir saldırganın, oturum açmış bir kullanıcının tarayıcısını kullanarak o kullanıcının haberi ya da isteği olmadan bir web sitesinde işlem yaptırmasıdır. XSS'in aksine CSRF, sitenize kod enjekte etmez — bunun yerine kullanıcının zaten güvendiğiniz oturumunu silah olarak kullanır.

Saldırı nasıl işler?

Diyelim ki bir bankacılık sitesinde oturumunuz açık ve site, para transferi işlemini şu şekilde bir formla yapıyor:

<form action="/transfer" method="POST"><input name="amount"><input name="to"></form>

Eğer bu endpoint, isteğin gerçekten bankanın kendi sayfasından mı yoksa başka bir siteden mi geldiğini doğrulamıyorsa, kötü niyetli bir sitede gizlenmiş otomatik gönderilen bir form, sizin oturum çerezinizi kullanarak aynı isteği sizin adınıza gönderebilir. Tarayıcı, çerezleri istekle birlikte otomatik gönderdiği için sunucu bu isteğin sizden geldiğini "düşünür" — oysa siz o formu hiç görmediniz bile.

CSRF token: standart çözüm

En yaygın ve etkili savunma, her formda tahmin edilemeyen, oturuma özel bir CSRF token göndermektir. Sunucu, oturum başına rastgele bir token üretir, bunu forma gizli bir alan olarak ekler ve form gönderildiğinde token'ın oturumdaki değerle eşleştiğini doğrular:

• Token, kriptografik olarak güvenli rastgele bir üreteçle oluşturulmalıdır (PHP'de random_bytes() gibi) — tahmin edilebilir bir değer (örneğin artan bir sayaç) hiçbir koruma sağlamaz.
• Doğrulama, zamanlama saldırılarına (timing attack) karşı sabit zamanlı bir karşılaştırma fonksiyonuyla yapılmalıdır (hash_equals()), basit bir == karşılaştırması değil.
• Token, yalnızca GET isteklerinde değil, durum değiştiren her POST/PUT/DELETE isteğinde zorunlu kılınmalıdır — bir tane bile korumasız endpoint bırakmak tüm sistemi zayıflatır.

Ek savunma katmanı: SameSite çerezler

Modern tarayıcılar, çerezlere SameSite özniteliği eklemenize izin verir. SameSite=Strict, çerezin yalnızca aynı siteden gelen isteklerde gönderilmesini sağlayarak CSRF'i büyük ölçüde engeller. Ancak dikkat: Strict ayarı, üçüncü taraf bir siteden (örneğin bir OAuth sağlayıcısından) geri yönlendirme sonrası oturumun taşınmasını da engelleyebilir — bu durumda SameSite=Lax daha uygun bir denge sunar, çünkü üst düzey (top-level) navigasyonlarda çerezin gönderilmesine izin verirken, arka planda çalışan sahte form gönderimlerini yine de engeller.

Sık yapılan hatalar

• Yalnızca JavaScript ile kontrol etmek: İstemci tarafı doğrulama, sunucu tarafı doğrulamanın yerini asla tutmaz — saldırgan doğrudan sunucuya istek gönderebilir.
• Token'ı URL'de taşımak: Token'lar tarayıcı geçmişinde, sunucu loglarında ve Referer başlığında sızabileceğinden, gizli form alanı veya özel bir HTTP başlığı tercih edilmelidir.
• Token'ı tüm oturum boyunca sabit tutup hiç yenilememek: Özellikle giriş sonrası token'ın yenilenmesi (session fixation saldırılarına karşı da faydalıdır), güvenliği artıran iyi bir pratiktir.

Sonuç

CSRF, anlaşılması basit ama gözden kaçırılması kolay bir açıktır. Her durum değiştiren formda token doğrulaması, doğru SameSite çerez ayarı ve sabit zamanlı karşılaştırma fonksiyonlarının bir arada kullanılması, bu saldırı sınıfına karşı sağlam bir savunma oluşturur.