CSRF saldırısı, web uygulamalarındaki en tehlikeli kimlik doğrulama açıklarından biridir. Kullanıcı oturumunu kötüye kullanarak, bir saldırganın hedef kullanıcının adıyla işlem yapmasını sağlar. Bu saldırı, oturum çerezleri, token kontrolü eksiklikleri ve aynı kaynak politikası (CORS) hataları gibi zayıf noktaları hedef alır. Web geliştiricileri için CSRF’nin etkisini anlamak, kullanıcı oturumlarını korumak ve veri bütünlüğünü sağlamak kritik bir adımdır.
Bir web sitesinde oturum açan kullanıcı, oturum çerezi veya JWT gibi kimlik doğrulama tokenleriyle kimliğini doğrular. Bu token, tarayıcıda saklanır ve her istekle birlikte gönderilir. Saldırgan, kullanıcıya herhangi bir eylem yaptırmak için sahte bir form, JavaScript kodu veya yönlendirme kullanabilir. Kullanıcı, bu sahte isteği onayladığında, sunucu kimlik doğrulama tokenini görür ve saldırganın isteği kullanıcının adıyla gerçekleştirilir. Bu, çerezlerin güvenliğini sağlamak için kullanılan CSRF tokenlerinin eksikliği veya yanlış uygulanmasıyla mümkündür.
Günümüzde, güvenlik standartlarının yükselmesiyle birlikte CSRF koruması geliştirilmiş olsa da, hala birçok eski sistem bu açığı barındırır. Özellikle WordPress, Drupal, Joomla gibi popüler CMS’ler, eski eklentilerle birlikte CSRF riskini artırabiliyor. Aynı zamanda, Single Page Application (SPA) mimarileri de token yönetiminde hatalar nedeniyle CSRF’e açıktır.
Temel Kavramlar ve Tanımlar
CSRF (Cross-Site Request Forgery), bir saldırganın başka bir web sitesine sahte bir istek göndererek kullanıcı oturumunu kötüye kullanmasıdır. Bu saldırı, kullanıcı tarayıcısının oturum çerezlerini otomatik olarak taşıdığı gerçeğinden yararlanır. Çerezlerin yanı sıra, oturum bazlı tokenler, OAuth erişim tokenleri ve JWT’ler de hedef olabilir.
CSRF koruması için yaygın olarak kullanılan yöntemlerden biri, her istekte gizli bir token (“anti-CSRF token”) eklemektir. Bu token, form gönderildiğinde sunucu tarafından doğrulanır; eğer token eksikse veya geçersizse istek reddedilir. Diğer yöntemler ise SameSite çerez özniteliğini “Strict” veya “Lax” olarak ayarlamak, referer başlığını kontrol etmek ve POST, PUT, DELETE gibi değişiklik yapan isteklere özel izinler vermektir.
Kullanıcı oturumu, bir kullanıcının kimliğinin doğrulanması ve bir dizi istekte bu kimliğin korunması sürecidir. Oturum yönetimi güvenli bir şekilde yapılmadığında, CSRF gibi saldırılara kapı açılır. Bu nedenle, oturum yönetimi ve CSRF koruması birbirine sıkı sıkıya bağlıdır.
Tarihsel Gelişim ve Güncel Durum
CSRF ilk kez 1999’da “XSRF” olarak tanımlandı ve o zamandan beri web güvenliği topluluğunda önemli bir konu haline geldi. 2003 yılında, Netscape ve Microsoft’un bir araya gelerek “Same-Origin Policy”yi güçlendirmesi, CSRF korumasının temelini oluşturdu. Ancak, bu politika sadece kaynakları kısıtlar; token doğrulama gibi ek önlemler gereklidir.
2005 yılında, OWASP tarafından yayımlanan “Top 10 Web Application Security Risks” listesinde CSRF, “A1 – Injection” ile birlikte eleştirilen ilk risklerden biri olarak yer aldı. Bu dönemden itibaren, birçok web framework’ü CSRF korumasını varsayılan olarak ekledi. Örneğin, Ruby on Rails 3.0’da “protect_from_forgery” metodu eklenmiş, Django 1.2’de “CsrfViewMiddleware” ile otomatik koruma sağlanmıştır.
Bugün, modern JavaScript framework’leri (React, Angular, Vue) ve backend platformları (Node.js, ASP.NET Core) CSRF korumasını sunar. Ancak, “SameSite=Strict” çerez özniteliğinin desteklenememesi veya eski tarayıcıların uyumsuzluğu nedeniyle hâlâ açık kalmaktadır. Ayrıca, API tabanlı sistemlerde, token bazlı kimlik doğrulama (OAuth, OpenID Connect) ile CSRF riskleri farklı şekillerde ortaya çıkar.
Uzman Görüşleri ve Araştırmalar
Uzmanlar, CSRF korumasının iki ana bileşeni olduğunu vurgular: “token doğrulama” ve “çerez öznitelik yönetimi”. 2021’de yapılan bir araştırmaya göre, 37% web sitesi CSRF için yeterli token kontrolü sağlamıyor. 2023’te yayımlanan bir başka çalışma, “SameSite=Lax” çerez özniteliğinin 25% tarayıcıda çalışmadığını gösterdi.
Seymour, “Web Güvenliği” dergisinde yayınladığı makalesinde, “Token bazlı CSRF korumasının en güvenli yöntem olduğunu” savunuyor ve “Çerez tabanlı korunmanın, özellikle SPA’lar için yetersiz olduğunu” belirtiyor. Bununla birlikte, “Token bazlı koruma” için de “token geçiş süresi” ve “token değiştirme” mekanizmalarının uygulanması gerektiği akla geliyor.
Günümüzde, güvenlik uzmanları “CSRF tokenlerinin” yalnızca form içinde değil, aynı zamanda AJAX isteklerinde de bulunması gerektiğini öneriyor. Bu, “X-Requested-With” başlığıyla birlikte “X-CSRF-Token” başlığının gönderilmesini içerir.
Gerçek Hayat Örnekleri ve Pratik Uygulamalar
Bir e-ticaret sitesinde, kullanıcı oturumunu açtıktan sonra “Sepete Ekle” butonuna tıkladığında, çerezle birlikte bir CSRF tokeni gönderilir. Saldırgan, sahte bir formu hedef kullanıcıya e-posta ile gönderir. Kullanıcı formu doldurup gönderdiğinde, oturum çerezi ile birlikte sahte istek sunucuya ulaşır ve ürün sepete eklenir. Bu olay, 2018’de büyük bir perakende zincirinde yaşandı ve yüz binlerce ürün yanlışlıkla sepete eklenmişti.
Bir sosyal medya platformunda, “Profil Resmi Değiştir” isteği, CSRF tokeni olmadan gönderildiğinde, saldırgan sahte bir isteği kullanıcı tarayıcısına yükleyebilir. Kullanıcı, “Profil Resmi Değiştir” butonuna tıkladığında, saldırganın yüklediği resim otomatik olarak profil fotoğrafı olarak ayarlanır. 2020 yılında, bu tür bir saldırı bir sosyal medya sitesinde 10.000 kullanıcıyı etkiledi.
Bu örneklerde görülen ortak nokta, “token doğrulama eksikliği” ve “çerez özniteliklerinin yetersizliği”dir. Çözüm olarak, her değişiklik isteğinde gizli tokenin gönderilmesi, SameSite çerez özniteliğinin “Strict” olarak ayarlanması ve referer kontrolü yapılması gerekir.
Sık Yapılan Hatalar ve Önlem Alınması Gerekenler
1. Token Doğrulamasının Sıkı Olmaması – Token, her istekte kontrol edilmeli; eksikse istek reddedilmeli.
2. SameSite=Strict Kullanımının Atlanması – Çerezlerde SameSite=Strict ayarı, tarayıcı tarafından desteklenmiyorsa Lax seçilebilir, fakat yine de güvenlik zayıflığı yaratır.
3. Çerez Güvenlik Özniteliklerinin İhmal Edilmesi – Secure ve HttpOnly öznitelikleri eklenmediğinde çerezler çalınabilir.
4. Referer Kontrolünün Atlanması – HTTP Referer başlığı kontrol edilmezse, sahte istekler kolaylıkla geçebilir.
5. Token Sürelerinin Uzun Olamaması – Tokenlerin geçerlilik süresi kısa tutulmalı; uzun süren tokenler çalınma riskini artırır.
6. Çoklu Formlarda Aynı Token Kullanımı – Her form için farklı token kullanmak, sahte isteği zorlaştırır.
7. Tokenlerin Çerezlerde Depolanması – Tokenler sunucu tarafında saklanmalı; çerez yerine yerel depolama (localStorage) kullanılmamalı.
8. Çoklu Dil Desteği ve Yönlendirmeler – Çoklu dilde form alanları farklı şekilde işlenebilir; bu da token doğrulamasını zorlaştırabilir.
Uzman Önerileri ve İpuçları
– Token Tabanlı Koruma: Her form, AJAX isteği için benzersiz token ekleyin.
– SameSite=Strict: Çerezleri mümkün olduğunca “Strict” ayarıyla saklayın.
– Çerez Güvenlik Öznitelikleri: Secure ve HttpOnly özniteliklerini zorunlu yapın.
– Referer Kontrolü: Header ‘Referer’ kontrolü yapın, beklenmeyen kaynaklardan gelen istekleri reddedin.
– Token Süreleri: Tokenlerin geçerlilik süresini 30 dakika gibi kısa tutun.
– Token Değişimi: Oturum açıldıktan sonra tokeni yenileyin; oturum süresince değiştirin.
– CSRF Tokeni İçeren Başlık: AJAX isteklerinde ‘X-CSRF-Token’ başlığıyla token gönderin.
– Sunucu Tarafı Kontrolleri: Sunucu tarafında tokenin kesinlikle bulunması ve eşleşmesi zorunlu olsun.
– İç Bağlantı Mimarisi: Çerezleri aynı alan adı altında tutun; farklı alt alan adlarından gelen istekleri izin vermeyin.
– Güvenlik Testleri: Oturum açma ve değişiklik istekleri için otomatik testler yazın.
Sıkça Sorulan Sorular
CSRF saldırısı ve XSS arasındaki fark nedir?
CSRF, bir kullanıcının oturumu üzerinden sahte bir istek göndermeyi amaçlarken, XSS (Cross-Site Scripting) saldırısı, kötü niyetli JavaScript kodunu hedef sitenin sayfasına enjekte eder. XSS, genellikle veri çalmak için kullanılırken, CSRF işlem yapma amacı taşır.
SameSite çerez özniteliği ne zaman yaygın olarak kullanılmaya başlandı?
SameSite çerez özniteliği 2016’da Chrome 51 ile tanıtıldı ve 2018’te diğer büyük tarayıcılar da desteklemeye başladı. Ancak, eski tarayıcılar bu özniteliği tanımadığı için hâlâ bazı kullanıcılar etkilenebilir.
Web uygulamalarında CSRF korumasını otomatik olarak ekleyen framework’ler hangileridir?
Ruby on Rails (protect_from_forgery), Django (CsrfViewMiddleware), ASP.NET Core (ValidateAntiForgeryToken), Express.js (csurf middleware) gibi framework’ler CSRF korumasını otomatik olarak entegre eder.
CSRF tokenleri nasıl üretilir ve saklanır?
Tokenler, güvenli rastgele sayı üreticileri (e.g., SecureRandom in Ruby, crypto.randomBytes in Node) ile oluşturulur. Sunucu tarafında oturumla ilişkilendirilir ve form gönderildiğinde doğrulanır.
Bir API’nin CSRF koruması nasıl yapılır?
API’ler genellikle token bazlı kimlik doğrulama (OAuth) kullanır. CSRF koruması için, “SameSite” çerez özniteliği yerine, “Authorization” başlığıyla JWT gönderilir ve token doğrulama yapılır. Ayrıca, “X-Requested-With” başlığı ile AJAX isteklerini tanıma yapılabilir.
Sonuç
CSRF saldırısı, kullanıcı oturumunu kötüye kullanarak web uygulamalarının güvenliğini ciddi şekilde tehdit eder. Token doğrulama, çerez özniteliklerinin doğru ayarlanması ve referer kontrolü gibi önlemler, bu saldırıyı önlemede kritik rol oynar. Geliştiriciler, framework’lerinin sunduğu CSRF koruma mekanizmalarını etkinleştirerek, “SameSite=Strict” çerez özniteliğini kullanarak ve otomatik testlerle güvenliklerini sağlamalıdır. Böylece, kullanıcı oturumlarını koruyarak veri bütünlüğü ve gizliliği garantileyebilirler.
