Cross-Site Request Forgery (CSRF)

SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama
SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama

Tüm Kayıtlar

Sitenizi Tarayın

Sitenizi bu zafiyete karşı kontrol edin

Otomatik bir tarama başlatın ve sitenizin etkilenip etkilenmediğini görün — sade dille bulgular ve çözümlerle.

Taramaya Başla
KategoriCross-Site Request Forgery
Tipik Önem DerecesiYüksek
OWASPA01:2021 – Kırık Erişim Denetimi
CWECWE-352: Cross-Site Request Forgery (CSRF)
Diğer adlarıXSRF, Sea Surf, Oturum Sürme, Tek Tık Saldırısı, Hostile Linking
Etkilenen sistemlerÇerez tabanlı veya HTTP Basic/Digest kimlik doğrulaması kullanan ve GET ya da POST üzerinden durum değiştiren işlemler gerçekleştiren web uygulamaları
İlgili standartlarRFC 6265 (HTTP Çerezleri), OWASP CSRF Önleme Kopya Kağıdı

Genel Bakış

Cross-Site Request Forgery (CSRF), bir saldırganın kurbanın tarayıcısını — kurbanın çerezlerini veya HTTP kimlik doğrulama kimlik bilgilerini taşıyan — kurban farkında olmadan veya rızası olmadan hedef uygulamaya HTTP isteği göndermeye yönlendirdiği istemci taraflı bir güvenlik açığıdır. Tarayıcı, depoladığı kimlik bilgilerini otomatik olarak eklediğinden hedef uygulama, sahte isteği yalnızca kimlik bilgileri bazında meşru bir istekten ayırt edemez.

CSRF, OWASP Top 10'da yıllarca bağımsız bir kategori olarak yer almış olup günümüzde CWE-352 kapsamında kodlanmıştır. Durum değiştiren işlemler için özellikle tehlikelidir: parola veya e-posta adresi değiştirme, para transferi başlatma, hesap ayrıcalıklarını değiştirme veya kayıt silme gibi eylemler bu kategoriye girer.

Nasıl çalışır?

Bu saldırı, web tarayıcılarının iki özelliğine dayanır: çerezler, çerezin kaynağına yönelik her istekle otomatik olarak gönderilir; Aynı Kaynak İlkesi (Same-Origin Policy), JavaScript'in yanıtlara okuma erişimini düzenler ancak tarayıcının çapraz kaynaklı istekler göndermesini engellemez.

  1. Kimlik doğrulama: Kurban, bir hedef uygulamaya (örn. bir bankacılık sitesi) giriş yapar ve tarayıcıda saklanan bir oturum çerezi alır.
  2. Tuzak: Oturum hâlâ aktifken kurban, kötü amaçlı bir sayfayı ziyaret eder veya ziyaret etmesi için kandırılır (hazırlanmış e-posta, üçüncü taraf web sitesi veya enjekte edilmiş reklam).
  3. Sahte istek: Kötü amaçlı sayfa, tarayıcının hedef uygulamaya istek göndermesine neden olan işaretleme veya komut dosyası içerir; hazırlanmış src özniteliğine sahip bir <img> etiketi, JavaScript otomatik gönderimi olan gizli bir HTML formu ya da uygun CORS ön uçuş atlamasıyla bir fetch() çağrısı bu yöntemler arasında sayılabilir.
  4. Kimlik bilgisi ekleme: Tarayıcı, oturum çerezini (ve HTTP Basic/Digest kimlik bilgilerini) giden isteğe otomatik olarak ekler.
  5. Eylemin gerçekleştirilmesi: Hedef uygulama, geçerli kimlik bilgilerini görüp isteği kasıtlı yapılmış gibi işler.

İstismar edilebilirliği etkileyen temel teknik faktörler:

  • HTTP yöntemi: GET tabanlı durum değişiklikleri, <img src> veya <link href> aracılığıyla önemsiz biçimde istismar edilebilir. POST tabanlı işlemler bir form veya fetch gerektirir ancak yalın HTML ile yine de istismar edilebilir.
  • Content-Type kısıtlamaları: application/json POST istekleri normalde CORS ön uçuşunu tetikler; tarayıcı bunu çapraz kaynaklı isteklerde izin vermeyen uç noktalara karşı engeller. Ancak text/plain veya multipart/form-data ön uçuşu tetiklemez ve JSON benzeri yükler taşıyabilir.
  • Çerez öznitelikleri: SameSite özniteliğinin bulunmaması (veya SameSite=None kullanımı), çerezlerin tüm çapraz site istekleriyle gönderilmesi anlamına gelir ve saldırı yüzeyini genişletir.
  • Alt alan adı güveni: Alt alan adları çerezleri paylaşıyorsa (geniş Domain özniteliği) ele geçirilmiş bir alt alan adı, ana uygulamaya karşı bir CSRF yükü sunabilir.

İş etkisi

Başarılı bir CSRF saldırısı, kurbanın tam ayrıcalıklarıyla rastgele durum değiştiren işlemleri gerçekleştirir. Somut sonuçlar şunlardır:

  • Hesap ele geçirme: Saldırgan, kurbanın e-posta adresini veya parolasını değiştirerek onu kilitler ve tam denetim elde eder.
  • Finansal dolandırıcılık: Ödeme destekli uygulamalarda yetkisiz para transferleri, satın alımlar veya abonelik değişiklikleri.
  • Veri imhası veya sızıntı kurulumu: Kayıtları silme, veri paylaşım ayarlarını değiştirme veya saldırganın denetimindeki bir yönetici hesabı ekleme.
  • Ayrıcalık yükseltme: Saldırgana uygulama içinde yüksek roller verilmesi.
  • Yasal ve düzenleyici yükümlülükler: Kişisel veya finansal verilerin yetkisiz işlenmesi, GDPR, PCI DSS veya diğer çerçeveler kapsamında yükümlülükler doğurabilir.
  • İtibar kaybı: Açıklanamayan hesap değişiklikleri yaşayan kullanıcılar platforma olan güvenini kaybeder.

Nasıl düzeltilir?

  1. Senkronizatör Belirteç Deseni (birincil savunma): Kriptografik olarak rastgele, oturum başına (veya istek başına) bir belirteç oluşturun ve bunu her durum değiştiren HTML formuna gizli bir alan olarak ya da AJAX için özel bir HTTP başlığı (X-CSRF-Token) olarak ekleyin. Belirteci her değiştiren istekte sunucu tarafında doğrulayın. Belirteçler tahmin edilemez olmalı (en az 128 bit entropi) ve oturuma bağlı olmalıdır.
  2. Çift Gönderim Çerezi: Rastgele bir değeri hem çereze hem de bir istek parametresine (veya başlığa) ayarlayın. Bunların eşleştiğini sunucu tarafında doğrulayın. Bu yöntem, alt alan adı çerez enjeksiyonu mümkünse senkronizatör deseninden daha zayıftır; ancak durumsuz mimariler için kullanışlıdır.
  3. SameSite Çerez Özniteliği: Oturum çerezlerine SameSite=Strict veya SameSite=Lax ayarlayın. Strict, tüm çapraz site isteklerinde çerezi engeller. Lax (2020'den bu yana çoğu tarayıcıda varsayılan), çapraz site alt kaynak ve form POST isteklerinde çerezi engeller; üst düzey gezintilere ise izin verir. Bu öznitelik tek başına tam bir savunma değildir — derinlemesine savunma katmanı olarak kullanılmalıdır.
  4. Origin veya Referer başlığını doğrulayın: Sunucuda, Origin başlığının (tercih edilir) veya Referer başlığının beklenen kaynaklı eşleştiğini kontrol edin. Beklenmedik kaynaklardan gelen istekleri reddedin. Proxy'ler tarafından başlık kaldırma ve doğrudan gezintilerde eksik başlıklara karşı dikkatli olun.
  5. AJAX için özel istek başlıkları kullanın: Tüm AJAX tabanlı durum değişiklikleri için özel bir başlık (örn. X-Requested-With: XMLHttpRequest) zorunlu kılın. Çapraz kaynaklı istekler, CORS ön uçuşu olmadan rastgele başlıklar ayarlayamaz; sunucu bu ön uçuşu reddedebilir.
  6. GET tabanlı durum değişikliklerini ortadan kaldırın: HTTP GET isteklerinin idempotent olmasını sağlayın ve sunucu durumunu asla değiştirmemelerini garantileyin. Tüm değişiklikler için REST anlambilimine uygun olarak POST, PUT, PATCH veya DELETE kullanın.
  7. Hassas işlemler için yeniden kimlik doğrulama isteyin: Yüksek etkili eylemler (parola değiştirme, ödeme, ayrıcalık verme) için kullanıcılardan CSRF belirteçlerinden bağımsız olarak parolalarını yeniden girmelerini veya ikinci bir faktörü tamamlamalarını isteyin.
  8. CORS politikasını doğru uygulayın: Kısıtlayıcı bir CORS politikası, çapraz kaynaklı JavaScript'in yanıtları okumasını engeller; ancak basit çapraz kaynaklı isteklerin gönderilmesini engellemez. CORS'u CSRF savunması olarak kullanmayın.
  9. Çerçeve varsayılanları: Özel belirteç mantığı uygulamak yerine web çerçevenizin yerleşik CSRF korumasını kullanın (Django'nun CsrfViewMiddleware'i, Laravel'in VerifyCsrfToken'i, Spring Security'nin CsrfFilter'i, Rails'in protect_from_forgery'si vb.).

Kaynaklar

Sıkça sorulan sorular

XSS (Cross-Site Scripting), güvenilen site tarafından sunulan bir sayfaya kötü amaçlı komut dosyaları enjekte eder; bu sayede saldırgan hedef kaynak içinden veri okuyabilir, çerez çalabilir veya kurban adına eylemler gerçekleştirebilir. CSRF ise tarayıcının kimlik bilgilerini otomatik olarak eklemesini istismar ederek farklı bir kaynaktan istek sahtecilik yapar; hedef sitede kod enjekte etmeye ya da çalıştırmaya gerek yoktur. XSS, Aynı Kaynak İlkesini tamamen atlattığı için genellikle daha ciddi kabul edilir. Dikkat edilmesi gereken husus şudur: hedef uygulamadaki bir XSS açığı CSRF korumalarını da geçersiz kılar; çünkü saldırganın komut dosyası CSRF belirteçlerini okuyup yeniden kullanabilir.

Hayır. HTTPS, iletişim kanalını şifreler ve sunucunun kimliğini doğrular; ancak tarayıcının çapraz kaynaklı isteklerde çerezleri otomatik olarak göndermesini engellemez. CSRF, aktarım katmanının üzerindeki uygulama katmanında çalışır; dolayısıyla TLS, sahte isteklere karşı herhangi bir koruma sağlamaz.

SameSite=Strict veya SameSite=Lax, CSRF riskini önemli ölçüde azaltır ve güçlü bir derinlemesine savunma kontrolüdür; ancak tek başına yeterli bir koruma olmamalıdır. Tarayıcı desteğindeki tutarsızlıklar, eski tarayıcılar ve sınır durumlar (örn. Lax kapsamında üst düzey gezimsel GET isteklerine izin verilmesi) göz önüne alındığında, SameSite ile birlikte bir senkronizatör belirteci veya kaynak doğrulama yaklaşımı kullanılmalıdır.

Klasik CSRF yalnızca istek sahteciliği yapar; saldırganın yanıtı doğrudan okumasına izin vermez (tarayıcı, komut dosyasının erişebildiği yanıtlar için Aynı Kaynak İlkesini uygular). Ancak bir CSRF saldırısı, verileri dolaylı olarak açığa çıkaran veri, hesap ayarı veya güvenlik denetimlerini değiştirebilir; örneğin hesabın e-posta adresini saldırganın kontrolündeki bir adresle değiştirip ardından parola sıfırlama tetiklenebilir.

Content-Type: application/json gövdelerini kabul eden REST API'leri genellikle daha güvenlidir; çünkü çapraz kaynaklı form gönderimleri CORS ön uçuşunu tetiklemeden bu içerik türünü ayarlayamaz. Ancak API aynı zamanda text/plain veya multipart/form-data'yı da kabul ediyorsa ya da CORS politikası aşırı izin vericiyse CSRF hâlâ mümkündür. Yalnızca çerezlerle kimlik doğrulaması yapılan API'ler (örn. bir giriş uç noktası tarafından ayarlanan oturum çerezleri), veri formatından bağımsız olarak CSRF koruması gerektirir. Authorization başlığındaki belirteçlerle (çerezlerde değil, bellekte saklanan Bearer belirteçleri) kimlik doğrulaması yapılan API'ler klasik CSRF'ye karşı savunmasız değildir.

Sensagraph, web uygulama formlarını ve durum değiştiren uç noktaları CSRF belirteçlerinin varlığı ve geçerliliği açısından otomatik olarak inceler, SameSite çerez özniteliklerini kontrol eder ve değiştirme işlemleri gerçekleştiren GET isteklerini belirler.