Mobil geliştirmede CSRF: nedir, saldırı türleri ve koruma yöntemleri

CSRF Saldırısı Nedir?

CSRF (Cross-Site Request Forgery), saldırganın sahte bir istek oluşturduğu ve kurbanın tarayıcısını bunu hedef sunucuya göndermeye zorladığı bir saldırıdır. Sunucu, kullanıcının mevcut oturumundan geçerli çerez kimlik bilgilerini aldığı için isteği yerine getirir. Saldırı mümkündür çünkü tarayıcı, isteğin hangi sayfadan gönderildiğine bakılmaksızın, hedef alana yapılan her isteğe otomatik olarak çerez ekler. Kullanıcı, saldırganın sayfasını görmeyebilir bile — kötü amaçlı bir URL'ye sahip gizli bir <img>, <form> veya <iframe> yüklemek yeterlidir. CSRF doğrudan veri çalmaz — saldırı, kurban adına işlemler gerçekleştirir (durum değiştiren işlemler), örneğin para transferi, şifre değiştirme veya hesap silme.

Hangi İşlemler En Savunmasızdır?

CSRF saldırıları yalnızca durum değiştiren işlemleri hedef alır — yan etkileri olan GET istekleri, POST, PUT ve DELETE. Örneğin, kişisel hesapta e-posta adresini değiştirme isteği: sunucu isteği kaynağını doğrulamadan kabul ederse, saldırgan kendi e-postasını koyabilir ve şifre sıfırlama başlatabilir. Saldırı, tek bir eylemin ciddi sonuçları olduğu banka sistemleri, yönetici panelleri ve sosyal ağlar için özellikle tehlikelidir. Kimlik doğrulama için çerez kullanan mobil uygulama API'leri de ek kontroller yapmazlarsa CSRF'ye karşı savunmasızdır.

Kimler Risk Altında?

Kimlik doğrulamanın çerezlere dayandığı ve sunucunun istek kaynağını doğrulamadığı herhangi bir web uygulaması veya API savunmasızdır. Web formları aracılığıyla kimlik doğrulama için WebView kullanan mobil uygulamalar da risk altındadır: tarayıcı bileşeni otomatik olarak çerez gönderir ve saldırgan arka plan yüklemesi yoluyla kötü amaçlı bir istek enjekte edebilir. HackerOne (2025)'e göre, web uygulamalarındaki tüm güvenlik açığı raporlarının yaklaşık %12'si CSRF koruması eksikliğiyle ilgilidir.

CSRF'yi Tehlikeli Yapan Nedir?

CSRF'nin ana özelliği kurban için görünmez olmasıdır. Kullanıcı bir saldırının gerçekleştiğini fark etmeyebilir bile: sahte istek arka planda yürütülür ve uygulama arayüzü herhangi bir tehlike belirtisi göstermez. CSRF'yi tespit etmenin tek yolu, sunucu günlüklerini izlemek veya hesapta ani değişiklikler fark etmektir. Ayrıca, CSRF, XSS veya açık yönlendirmeler gibi diğer güvenlik açıklarıyla kolayca birleştirilebilir ve bu da hasarı katlayarak artırır.

CSRF Saldırısı Nasıl Çalışır?

Bir CSRF saldırısı üç koşul gerektirir: kurban hedef sitede kimlik doğrulaması yapmıştır, sunucu çerez kimlik doğrulaması kullanır ve saldırganın isteği bir işlem URL'sine yönlendirilir. Saldırgan, src özelliği hedef URL'yi gösteren bir form, komut dosyası veya görsel içeren bir HTML sayfası oluşturur. Kurbanın tarayıcısı bu sayfayı yükler ve otomatik olarak mevcut oturum çereziyle birlikte sunucuya bir istek gönderir. Sunucu geçerli çerezleri alır, isteğin kaynağını doğrulamaz ve işlemi gerçekleştirir.

<!-- Gizli form üzerinden CSRF saldırısı örneği -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

Sayfa yüklendikten sonra, komut dosyası formu hemen gönderir. Tarayıcı, bank.example.com'a yapılan POST isteğine kullanıcının oturum çerezini ekler. Bankanın sunucusu çerezi kontrol eder, kullanıcının kimliğinin doğrulandığını onaylar ve saldırganın hesabına transferi gerçekleştirir. Kurban boş veya meşru bir sayfa görür, ancak para çoktan gitmiştir.

CSRF'de Tarayıcının Rolü

HTTP protokolünün temel bir özelliği, isteğin kaynağının yerleşik olarak doğrulanmamasıdır. Tarayıcı, istek alanı çerez alanıyla eşleşirse isteğe çerez ekler. Saldırganın çerezin içeriğini bilmesi gerekmez — tarayıcı bunu otomatik olarak yapar. Aynı kaynak politikası CSRF'ye karşı koruma sağlamaz çünkü saldırı sunucuyu hedef alır, yanıtı okumayı değil. CORS gibi mekanizmalar da etkisizdir: CSRF isteklerinin hasar vermek için genellikle yanıtı okuması gerekmez.

CSRF Saldırılarının Ana Türleri

CSRF saldırıları, kötü amaçlı isteğin iletilme yöntemine göre sınıflandırılır. Her tür, isteği göndermek için farklı bir HTML öğesi kullanır, ancak hepsi tarayıcının otomatik çerez göndermesine dayanır. Yöntem seçimi saldırganın hedeflerine bağlıdır: GET tabanlı saldırılar daha az kod gerektirir, POST tabanlı saldırılar bazı savunmaları daha güvenilir şekilde atlar ve XMLHttpRequest tabanlı saldırılar başlık manipülasyonuna izin verir.

GET Tabanlı CSRF

En basit yöntem: saldırgan, istek parametrelerini içeren bir URL'ye sahip <img> öğesini bir sayfaya yerleştirir. Tarayıcı görseli yükler ve sunucuya bir GET isteği gönderir. Örneğin, <img src="https://api.example.com/delete?postId=123" />, sunucu DELETE'yi GET üzerinden işliyorsa bir kaydı siler. Açık tehlikeye rağmen, bazı API'ler hala silme veya güncelleme işlemleri için GET kullanır.

POST Tabanlı CSRF

Sunucu yalnızca POST isteklerini kabul ediyorsa, saldırgan POST yöntemiyle gizli bir form oluşturur ve JavaScript aracılığıyla otomatik olarak gönderir. Form ekranda görünmez (tüm <input> öğeleri type="hidden" olarak ayarlanmıştır) ve autofocus + .submit() kullanıcı tıklaması olmadan çalışır. Sunucu Content-Type başlığını kontrol ediyorsa POST tabanlı saldırılar çalışmaz, ancak çoğu API standart application/x-www-form-urlencoded biçimini kabul eder.

XHR Tabanlı CSRF (CORS ile)

XMLHttpRequest veya Fetch API, rastgele başlıklarla istek göndermeye izin verir. Sunucu CORS'u çok geniş yapılandırmışsa (Access-Control-Allow-Origin: *), saldırgan herhangi bir isteği gönderebilir ve yanıtı okuyabilir. Ancak bir CSRF saldırısı için yanıtı okumak gerekli değildir — eylemi gerçekleştirmek yeterlidir. Modern tarayıcılar, standart olmayan isteklerden önce bir preflight isteği OPTIONS gönderir; bu, sunucu doğru yapılandırılmışsa XHR tabanlı CSRF'yi engelleyebilir.

Mobil Uygulamalarda CSRF

Mobil uygulamalar, web sitelerine göre CSRF'ye karşı daha az savunmasızdır çünkü yerel uygulamalar nadiren çerez kimlik doğrulaması kullanır. Bunun yerine, mobil API'ler daha çok Authorization başlığında (Bearer token'lar, JWT) token'lar kullanır. Ancak, CSRF saldırısının mümkün olduğu senaryolar vardır: web girişi olan WebView, hibrit uygulamalar ve çerez tabanlı oturumları olan API'ler. TechCrunch (2025)'e göre, halka açık mobil uygulama API'lerinin yaklaşık %18'i hala oturum çerezlerini desteklemektedir.

WebView Üzerinden CSRF

Birçok uygulama web sayfalarını WebView içinde açar — OAuth yetkilendirmesi, ödeme formları, içerik görüntüleme. WebView, oturum çerezlerini depolayan uygulama içindeki tam teşekküllü bir tarayıcıdır. Saldırgan, URL'sini WebView'da yüklemenin bir yolunu bulursa (açık yönlendirme veya Deep Link aracılığıyla), normal bir tarayıcıdaki gibi bir CSRF saldırısı gerçekleştirebilir. Koruma — kritik işlemler için WebView yerine Chrome Custom Tabs veya SFSafariViewController kullanın.

JWT Kimlik Doğrulaması Olan API'lerde CSRF

JWT token'ları genellikle localStorage içinde veya uygulama belleğinde saklanır ve otomatik olarak gönderilmez — geliştirici her isteğe açıkça Authorization başlığını ekler. Bu, klasik bir CSRF saldırısını imkânsız hale getirir. Ancak uygulama JWT'yi bir çerezde saklıyorsa (nadir ancak mümkün), risk geri döner. Ek koruma — azp veya aud talebi aracılığıyla JWT'yi belirli bir istek kaynağına bağlamak, token'ın farklı bir alanda kullanılmasını önler.

// Express'te sunucu tarafı CSRF token doğrulaması örneği
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// Girişte CSRF token'ı oluşturma
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

CSRF'den Korunma Yöntemleri

Modern CSRF koruması üç düzeyde oluşturulur: sunucu tarafı CSRF token'ları, çerezler için SameSite özelliği ve Origin başlığının kontrolü. Bu yöntemlerin kombinasyonu, kullanıcı deneyimini önemli ölçüde etkilemeden CSRF saldırılarının %99'una karşı koruma sağlar. Yaklaşım seçimi uygulama mimarisine bağlıdır: bir web sitesi yalnızca SameSite=Lax'a ihtiyaç duyabilirken, bir mobil uygulama API'si başlıklarda token'lar gerektirir.

CSRF Token'ları (Senkronize Edici)

Standart yöntem: sunucu benzersiz bir token oluşturur, bunu kullanıcının oturumuna bağlar ve istemciye gönderir. İstemci, her durum değiştiren isteğe (gizli bir form alanında veya X-CSRF-Token başlığında) token'ı dahil eder. Sunucu, alınan token'ı oturumda saklananla karşılaştırır. Token şifreleme açısından güçlü, rastgele, en az 32 bayt uzunluğunda olmalı ve her oturumda veya işlemde değişmelidir. Token'ın ömrü birkaç saati geçmemelidir.

SameSite Çerezi

Çerezler için SameSite özelliği, çerezlerin alanlar arası isteklerde gönderilmesini kısıtlar. Lax değeri, çerezlere yalnızca üst düzey gezinme GET istekleri için izin verir — çoğu web sitesi için yeterlidir. Strict, gezinme dahil tüm alanlar arası istekler için çerezleri engeller: kullanıcı başka bir siteden geldiğinde yeniden kimlik doğrulaması yapmak zorunda kalır. Chrome Platform Status (2026)'ya göre, SameSite=Lax tüm modern tarayıcılarda varsayılan olarak etkindir ve bu, CSRF saldırılarını %67 oranında azaltmıştır.

Origin ve Referer Kontrolü

Sunucu, gelen isteklerin Origin veya Referer başlıklarını kontrol edebilir. İstek farklı bir alandan geliyorsa engellenir. Origin, Referer'dan daha güvenilirdir çünkü POST isteklerinde her zaman bulunur ve tarayıcı politikaları tarafından devre dışı bırakılamaz. Uygulama: izin verilen kaynakların beyaz listesi, geçerli başlık değeriyle karşılaştırma. Bu yöntem etkilidir ancak Origin başlıklarının bulunmadığı veya sahte olabileceği mobil uygulamalarda zordur.

// Spring Boot'ta CSRF token doğrulaması örneği
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

Sunucuda token depolaması gerektirmeyen bir yöntem: sunucu rastgele bir değerle bir çerez ayarlar, istemci çerezden değeri okur ve bir başlık veya istek gövdesinde geri gönderir. Sunucu her iki değeri karşılaştırır. Saldırgan çerezi okuyamazsa (aynı kaynak politikası), token'ı taklit edemez. Bu yöntem senkronize ediciden daha basittir ancak çerezi ele geçirilmekten korumak için HTTPS gerektirir.

• CSRF token'ları — altın standart: güvenilir, zaman içinde kanıtlanmış, tüm çerçeveler tarafından desteklenir
• SameSite=Lax — web uygulamaları için asgari koruma: ücretsiz, otomatik, kod gerektirmez
• Origin kontrolü — ek bir katman: token doğrulamasından önce saldırıları engeller
• Double Submit — sunucu tarafı oturumları olmayan REST API'ler için: HTTPS üzerinde etkilidir
• Özel başlıklar — X-Requested-With: XMLHttpRequest basit CSRF formlarını engeller

CSRF ve XSS Arasındaki Fark

CSRF ve XSS, sıklıkla karıştırılan farklı saldırı türleridir. CSRF, sunucunun kullanıcının tarayıcısına olan güvenini sömürür: istek geçerli çerezlerle geldiği için sunucu, saldırganın komutunu yerine getirir. XSS, tarayıcının sunucunun içeriğine olan güvenini sömürür: tarayıcı, saldırgan tarafından sayfaya enjekte edilen bir komut dosyasını çalıştırır. CSRF, hedef siteye kod enjekte etmeyi gerektirmez — başka bir alandan istek göndermek yeterlidir. XSS ise sayfanın HTML koduna JavaScript enjekte etmenin bir yolunu bulmayı gerektirir. Ancak XSS, CSRF korumasını atlayabilir: enjekte edilen komut dosyası, CSRF token'ını sayfadan okur ve istekle birlikte gönderir.

CSRF ve XSS arasındaki farkı anlamak, çok katmanlı koruma oluşturmak için kritiktir. CSRF token'ları XSS'ye karşı koruma sağlamaz ve CSP (Content Security Policy) CSRF'ye karşı koruma sağlamaz. Yalnızca yöntemlerin bir kombinasyonu, uygulama güvenliğini her iki saldırı türüne karşı sağlar. WebView içeren mobil uygulamalarda riskler iki katına çıkar, bu nedenle geliştiricilerin API istekleri için en azından CSRF token'ları ve web içeriği için Content Security Policy uygulaması önerilir.