Sitenizi CSRF Saldırılarına Karşı Nasıl Korursunuz

Herhangi bir savunma kodu yazmadan önce uygulamanızın tam olarak nerelerde açıkta olduğunu haritalandırın. CSRF yalnızca durum değiştiren işlemleri (veri değiştiren veya bir eylemi tetikleyen her şeyi) etkiler ve yalnızca kurbanın zaten kimliği doğrulanmış olduğu durumlarda geçerlidir. Salt okunur GET istekleri genellikle güvenlidir; ancak cookie tabanlı kimlik doğrulamaya dayanan her POST, PUT, PATCH ve DELETE uç noktası potansiyel bir hedeftir.

• Durumu değiştiren tüm uç noktaları listeleyin: form gönderimleri, hesap güncellemeleri, ödemeler, silme işlemleri ve yönetici eylemleri.
• Hangi uç noktaların kimlik doğrulama için oturum cookie'lerine veya otomatik gönderilen diğer kimlik bilgilerine dayandığını doğrulayın.
• CORS aracılığıyla çapraz kaynaklı istekleri kabul eden uç noktaları işaretleyin — bunlar dikkatli bir inceleme gerektirir.
• Üçüncü taraf entegrasyonlarına veya web kancalarına (webhook) açık olan uç noktaları belgeleyin; bunlar genellikle özel işlem gerektirir.
• Uygulama çerçevenizin yerleşik CSRF ara yazılımına sahip olup olmadığını ve şu anda etkin olup olmadığını kontrol edin.

Senkronizatör token modeli, CSRF savunmasının altın standardıdır. Sunucu, kullanıcının oturumuyla bağlantılı gizli ve tahmin edilemez bir token oluşturur, bunu her HTML formuna gizli alan olarak yerleştirir ve ardından her gelen durum değiştiren istekte doğrular. Farklı bir kaynaktaki saldırgan bu token'ı okuyamaz veya taklit edemez.

• Oturum başına (veya yüksek güvenlikli akışlar için istek başına) kriptografik olarak rastgele bir token (en az 128 bit entropi) oluşturun.
• Token'ı sunucu tarafında kullanıcının oturumunda saklayın — yalnızca istemciden gönderilen bir token'a güvenmeyin.
• Token'ı her HTML formuna gizli bir giriş olarak ekleyin: <input type="hidden" name="_csrf" value="{token}">.
• AJAX istekleri için token'ı bir meta etiketten veya cookie'den okuyun ve özel bir istek başlığında gönderin (örn. X-CSRF-Token).
• Sunucuda, gönderilen token oturum token'ıyla eşleşmediğinde durum değiştiren her isteği reddedin — HTTP 403 döndürün.
• Ayrıcalık düzeyi değişikliklerinden sonra (örn. oturum açma, rol değişikliği) CSRF token'ını yenileyin.
• Kendi çözümünüzü geliştirmek yerine çerçevenizin yerleşik CSRF korumasını kullanın (Django'nun {% csrf_token %}, Laravel'in , Rails'in protect_from_forgery, Spring Security'nin CSRF filtresi vb.).

SameSite cookie özniteliği, tarayıcılara çapraz site istekleriyle cookie göndermemelerini söyler; bu da sunucu tarafında token doğrulama gerektirmeyen güçlü bir ikinci CSRF savunma katmanı sağlar. Tüm modern tarayıcılar tarafından desteklenir ve her oturum ile kimlik doğrulama cookie'sinde ayarlanmalıdır.

• Çapraz site gezintisinin oturumu taşımasına gerek olmayan oturum cookie'lerinde (örn. bankacılık panoları, yönetici panelleri) SameSite=Strict ayarlayın.
• Diğer tüm oturum cookie'lerinde en az SameSite=Lax ayarlayın — bu, üst düzey GET gezintilerine hâlâ izin verirken çapraz site POST isteklerinden gelen CSRF'yi engeller.
• Cookie'nin gerçekten çapraz site olarak gönderilmesi gerekmediği sürece (örn. gömülü widget'lar) asla SameSite=None kullanmayın; her zaman Secure ile eşleştirin.
• Tüm cookie'lerde Secure bayrağını ayarlayarak yalnızca HTTPS üzerinden gönderilmelerini sağlayın.
• JavaScript'in oturum cookie'lerini okumasını önlemek için HttpOnly bayrağını ayarlayın; bu, XSS tabanlı CSRF saldırılarını azaltır.
• Set-Cookie başlıklarınızı tarayıcı Geliştirici Araçları veya otomatik bir tarayıcı kullanarak denetleyin — Sensagraph, sitenizdeki cookie güvenlik özniteliklerini otomatik olarak kontrol eder.

Origin ve Referer istek başlıklarını kontrol etmek, durum doğrulamasından önce bile pek çok CSRF saldırısını durdurabilecek hafif ve durumsuz bir sunucu tarafı kontrolüdür. Tarayıcılar bu başlıkları çapraz site isteklerine ekler; kendi ön ucunuzdan gelen meşru aynı site istekleri bu başlıklarda sizin etki alanınızı taşır.

• Durum değiştiren isteklerde Origin başlığını okuyun. Mevcut olup izin verilen kaynağınızla eşleşmiyorsa isteği HTTP 403 ile reddedin.
• Origin yoksa Referer başlığına geri dönün ve uygulamanızın temel URL'siyle başladığını doğrulayın.
• Hem Origin hem de Referer'ın olmadığı ve isteğin bilinen güvenli bir bağlamdan gelmediği istekleri reddedin.
• İzin verilen kaynaklar için açık bir beyaz liste tutun — alt dize veya sonek eşleştirmesi kullanmayın, bu atlatılabilir (örn. evil.etkilanininiz.com).
• Yalnızca Referer kontrolüne güvenmeyin — gizlilik araçları ve HTTPS-to-HTTP geçişleri tarafından bastırılabilir.

Senkronizatör token'larının pratik olmadığı durumlarda — örneğin merkezi oturum deposu olmayan durumsuz mimarilerde veya dağıtık sistemlerde — double submit cookie modeli kullanılabilir bir alternatif sunar. Rastgele bir değer hem cookie hem de istek parametresi olarak saklanır; sunucu ikisinin eşleşip eşleşmediğini kontrol eder.

• Kriptografik olarak rastgele bir değer oluşturun ve bunu bir cookie olarak ayarlayın (JavaScript'in okuyabilmesi için HttpOnly değil).
• Aynı değeri her durum değiştiren istekte gizli form alanı veya özel başlık olarak ekleyin.
• Sunucuda, cookie değeri ile gönderilen değerin eşleştiğini doğrulayın — Aynı Kaynak İlkesi nedeniyle çapraz kaynaklı bir saldırgan cookie'yi okuyamaz.
• Sunucu tarafı gizli anahtarıyla token'ı HMAC ile imzalayan imzalı double submit cookie varyantını tercih edin; bu, saldırganın eşleşen bir çift oluşturmasını önler.
• Uygulamanız alt alan adı ele geçirmeye karşı savunmasızsa bu modeli kullanmayın; üst etki alanı için cookie ayarlayabilecek bir saldırgan savunmayı atlatabilir.

REST ve GraphQL API'lerinin JSON kullandığı için CSRF'ye karşı güvenli olduğu yaygın bir yanılgıdır; ancak cookie kabul ederlerse ve uygun içerik türü veya token kontrollerini zorunlu kılmazlarsa hâlâ savunmasızdırlar. Saldırganlar, uygun korumadan yoksun API'lerde durum değişikliklerini tetiklemek için HTML formları veya fetch istekleri kullanabilir.

• Tüm JSON API uç noktalarında Content-Type: application/json zorunlu kılın — HTML formları bu içerik türünü gönderemez, bu da basit CSRF vektörlerini engeller.
• Cookie kimlik doğrulamalı tüm API uç noktalarına, tıpkı HTML formlarında yaptığınız gibi, CSRF token doğrulaması uygulayın.
• Cookie yerine yalnızca Authorization başlıkları (Bearer token, API anahtarı) kullanan API'ler için CSRF geçerli değildir — API istemcilerinizin oturum cookie'si de gönderip göndermediğini doğrulayın.
• CORS politikasını gözden geçirin: Access-Control-Allow-Origin'da yalnızca güvenilir kaynaklara izin verin ve asla Access-Control-Allow-Credentials: true ile * birlikte kullanmayın.
• URL parametrelerinde kimlik bilgisi kabul etmekten kaçının (örn. ?token=...); bunlar sunucu günlüklerine ve tarayıcı geçmişine kaydedilir.
• GraphQL kullanıyorsanız, mutasyonlar anlam olarak durum değiştirdiğinden CSRF token'larını GraphQL katmanı içinde değil HTTP taşıma düzeyinde uygulayın.

CSRF saldırıları, sunucunun kimliği doğrulanmış bir oturuma duyduğu güveni istismar eder. Oturum yönetiminizi sıkılaştırmak, başarılı bir CSRF girişiminin pencerini ve etkisini azaltır.

• Oturum sabitleme saldırılarını önlemek için oturum açma, rol değişikliği ve ayrıcalık yükseltme işlemlerinden sonra oturum kimliklerini yenileyin.
• Oturum cookie'sinin süresini mümkün olan en kısa pratik süreye ayarlayın; mutlak süre sonlarına ek olarak boşta kalma zaman aşımlarını (örn. 15–30 dakika) kullanın.
• Oturum cookie'lerini gerektiği kadar dar bir yola ve etki alanına kapsayın: Path=/ özniteliğini yalnızca uygulamanızın gerçekten tüm yollar boyunca ihtiyaç duyduğu durumlarda kullanın.
• Sunucu tarafı oturumunu tam olarak geçersiz kılan bir çıkış uç noktası uygulayın; yalnızca istemci tarafı cookie'sini temizlemek yeterli değildir.
• E-posta, şifre veya ödeme ayrıntılarını değiştirme gibi yüksek riskli işlemler için yeniden kimlik doğrulama (adım yükseltme kimlik doğrulaması) gerektirilmesini değerlendirin — geçerli bir CSRF token'ı bile taze kimlik bilgisi isteyen bir saldırgana yardımcı olamaz.
• CSRF token doğrulama hatalarındaki ani artışları kaydedin ve uyarı gönderin; bu, aktif bir saldırı kampanyasına işaret edebilir.

CSRF savunmaları, çerçeve yükseltmeleri, yeniden yapılandırma veya yeni özellik geliştirme sırasında sessizce bozulabilir. Sürekli test, korumalarınızın zaman içinde etkili kalmasını sağlar.

• Her durum değiştiren uç noktayı, geçerli bir CSRF token'ı olmadan çapraz kaynaklı bir HTML formu veya fetch isteği oluşturarak manuel olarak test edin — sunucu HTTP 403 döndürmelidir.
• CSRF token doğrulama testlerini otomatik test paketinize (birim ve entegrasyon testleri) ekleyin; böylece gerilimler CI/CD ardışık düzeninde yakalanır.
• Özellikle büyük sürümler veya mimari değişikliklerden sonra CSRF'ye odaklanan periyodik sızma testleri gerçekleştirin.
• Üçüncü taraf kitaplıkları ve çerçeveleri CSRF ile ilgili CVE'ler için inceleyin ve yamaları derhal uygulayın.
• Tüm web mülklerinizde eksik veya yanlış yapılandırılmış CSRF korumalarını sürekli kontrol etmek için otomatik tarama kullanın — Sensagraph, sürekli taramasının bir parçası olarak yaygın CSRF yanlış yapılandırmalarını algılar.
• Content Security Policy (CSP) başlıklarınızı gözden geçirin — satır içi komut dosyalarına izin vermeyen güçlü bir CSP, XSS yardımlı CSRF atlatma riskini azaltır.
• CSRF ile ilgili güvenlik açığı açıklamalarından önceden haberdar olmak için teknoloji yığınınız için güvenlik duyurularına abone olun (örn. Django, Laravel, Spring).