Hızlı cevap: CSRF (Cross Site Request Forgery, siteler arası istek sahteciliği), oturumu açık bir kullanıcının tarayıcısını kandırarak, kullanıcının haberi olmadan güvendiği bir siteye istek gönderten bir web açığıdır. Saldırgan kullanıcının parolasını çalmaz; onun zaten açık olan oturumunu kullanır. Örneğin bankada oturumu açık bir kullanıcı, saldırganın hazırladığı zararlı sayfayı ziyaret ettiğinde, tarayıcısı arka planda para transferi isteği gönderebilir. Çünkü tarayıcı, o siteye ait çerezleri her isteğe otomatik ekler. CSRF'ye karşı temel savunma, sunucunun her durum değiştiren isteği bir CSRF token ile doğrulaması ve çerezleri SameSite özelliğiyle sınırlamasıdır.

CSRF yıllardır OWASP Top 10 listesinde yer aldı ve hâlâ birçok uygulamada karşımıza çıkar. Adı karışık gelse de mantığı basittir: tarayıcı, bir siteye istek gönderirken o sitenin çerezlerini otomatik ekler ve isteğin nereden tetiklendiğini sormaz. Saldırgan bu güveni suistimal eder. Bu yazıda CSRF'nin nasıl çalıştığını, hangi savunmaların gerçekten işe yaradığını ve sık yapılan hataları anlatıyoruz.

CSRF nasıl çalışır

Senaryo şudur:

  1. Kullanıcı güvendiği bir siteye (örneğin bankasına) giriş yapar. Tarayıcıda o siteye ait bir oturum çerezi oluşur.
  2. Kullanıcı oturumu kapatmadan başka bir sekmede saldırganın hazırladığı sayfayı açar.
  3. O sayfada gizli bir form ya da görsel isteği vardır ve hedef bankaya bir işlem isteği gönderir.
  4. Tarayıcı, bankaya giden bu isteğe oturum çerezini otomatik ekler. Sunucu isteği geçerli ve yetkili sanır, işlemi yapar.

Kritik nokta: saldırgan yanıtı okuyamaz, ama işlemi tetikleyebilir. Bu yüzden CSRF genelde durum değiştiren işlemleri hedefler: para transferi, e-posta değiştirme, parola sıfırlama, ayar güncelleme. Sadece veri okuyan istekler CSRF için çekici değildir.

CSRF ile XSS farkı

İkisi sık karıştırılır ama farklıdır:

Yön CSRF XSS
Ne yapar Kullanıcı adına istek gönderir Kurbanın tarayıcısında kod çalıştırır
Güveni suistimal eder Sitenin kullanıcıya güveni Kullanıcının siteye güveni
Yanıtı okur mu Hayır Evet
Ana savunma CSRF token, SameSite çerez Çıktı kodlama, CSP

XSS varsa CSRF savunmaları da anlamsızlaşır; çünkü saldırgan sayfada kod çalıştırıp token'ı okuyabilir. Bu yüzden XSS korunması CSRF savunmasının da ön koşuludur. CSRF'yi sunucunun kullanıcıya körü körüne güvenmesi, SSRF'yi ise sunucunun kendi ağına güvenmesi olarak düşünebilirsiniz.

CSRF'ye karşı gerçek savunmalar

1. SameSite çerez özelliği

Modern tarayıcılar çerezlere SameSite özelliği ekler. SameSite=Lax ya da Strict ayarlandığında, tarayıcı başka bir siteden tetiklenen isteklere çereği eklemez. Bu, CSRF'nin büyük kısmını kökten engeller ve bugün ilk savunma hattıdır. Oturum çerezleri en az Lax, hassas işlemler için Strict olmalıdır.

2. CSRF token (senkronizasyon jetonu)

Sunucu her forma, tahmin edilemez ve oturuma özel bir token gömer. İstek geldiğinde bu token'ı bekler. Saldırgan sayfası bu token'ı bilemeyeceği için istek reddedilir. Token güçlü rastgele üretilmeli, oturuma bağlı olmalı ve sunucu tarafında doğrulanmalıdır.

3. Çift gönderim çerezi

Token'ı hem çerezde hem istek gövdesinde göndertip ikisinin eşleştiğini kontrol etme yöntemidir. Sunucu tarafında durum tutmadan çalıştığı için API'lerde tercih edilir, ama SameSite ile birlikte kullanılması önerilir.

4. Origin ve Referer kontrolü

Sunucu, durum değiştiren isteklerde Origin ya da Referer başlığını kontrol ederek isteğin gerçekten kendi sitesinden geldiğini doğrulayabilir. Tek başına yeterli değildir ama ek bir katman sağlar. DSET'in kendi form uçlarında bu kontrol ilk katman olarak kullanılır.

Sık yapılan hatalar

  • GET isteğiyle durum değiştirmek. Silme, güncelleme gibi işlemleri GET ile yapmak CSRF'yi kolaylaştırır. Durum değiştiren her işlem POST, PUT ya da DELETE olmalı ve token istemelidir.
  • Sadece token, SameSite yok. İkisi birbirini tamamlar; modern uygulamalar ikisini birlikte kullanmalıdır.
  • Token'ı doğrulamadan kabul etmek. Formda token olması yetmez; sunucu onu gerçekten kontrol etmelidir.
  • CORS ile CSRF'yi karıştırmak. CORS tarayıcının yanıt okumasını sınırlar, isteğin gitmesini değil. CORS CSRF'yi çözmez.
  • JWT'yi çerezde SameSite'siz tutmak. Token tabanlı kimlik doğrulamada bile çerez kullanılıyorsa CSRF geçerlidir.

CSRF testi ve doğrulama

Bir açığın gerçekten sömürülebilir olup olmadığını görmek için web uygulaması sızma testi metodolojisi izlenir: durum değiştiren uçlar tespit edilir, token'ın var olup olmadığı, doğrulanıp doğrulanmadığı ve SameSite ayarları kontrol edilir. Token'ı kaldırıp isteğin yine de işlenip işlenmediği denenir. DSET, bulguları yanlış pozitif olmadan, çalışan bir kanıtla raporlar.

Sık sorulan sorular

CSRF ile parolam çalınır mı? Doğrudan hayır. CSRF parolanızı okumaz; açık oturumunuzu kullanarak sizin adınıza işlem yaptırır. Ama bu işlem e-posta ya da parola değiştirme ise hesabınız ele geçirilebilir.

SameSite çerez CSRF'yi tamamen bitirir mi? Büyük ölçüde azaltır ama tek başına yeterli sayılmaz. Eski tarayıcılar, bazı istek türleri ve yanlış yapılandırmalar için token ile birlikte kullanılması önerilir.

API'lerde CSRF olur mu? Kimlik doğrulama çerezle yapılıyorsa evet. Sadece Authorization başlığıyla token gönderen ve çerez kullanmayan API'ler CSRF'ye karşı doğal olarak dirençlidir.

CSRF sadece web sitelerinde mi olur? Tarayıcı üzerinden çerezle oturum tutan her uygulama risk altındadır. Mobil uygulamalar genelde çerez yerine token başlığı kullandığı için daha az etkilenir.

Kaynaklar

Web uygulamanızda CSRF ve diğer OWASP açıklarını çalışan kanıtla doğrulatmak için DSET ile iletişime geçin. Ankara Hacettepe Teknokent laboratuvarımızdan sızma testi ve güvenli kod denetimi hizmeti veriyoruz.