Cross-Site Request Forgery (CSRF)

1. Giriş

CSRF, adını 2001'de Peter Watkins'ten alan ama mekanizması web'in en temel özelliğinden doğan bir açıktır. Öz olarak: bir saldırgan, kurbanın tarayıcısını kandırarak, kurbanın giriş yapmış olduğu bir siteye — kurbanın niyeti olmadan — durum değiştiren bir istek gönderttirir. Kurban parolasını vermez, bir bağlantıya bile tıklamak zorunda olmayabilir; sadece saldırganın hazırladığı bir sayfayı ziyaret etmesi yeterlidir.

CSRF'in gücü, web'in temel bir davranışından gelir: tarayıcı, bir siteye giden her isteğe o sitenin çerezlerini otomatik ekler — istek nereden başlatılmış olursa olsun. Yani kurban banka.com'a giriş yaptıysa ve sonra kotu-site.com'u ziyaret ederse, kotu-site.com'un banka.com'a başlattığı bir istek de kurbanın banka.com oturum çerezini taşır. Sunucu açısından bu istek, kurbanın kendisinin yaptığı meşru bir istekten ayırt edilemez. İşte CSRF bu ayırt edilemezliği istismar eder.

Bu açığın etkisini ve inceliğini en iyi 2007'deki Gmail filter CSRF'i (Bölüm 11) gösterir: kurban, Gmail'e giriş yapmışken kötü bir sayfayı ziyaret ettiğinde, sayfa Gmail'e sessizce bir "tüm e-postaları saldırgana yönlendir" filtresi ekliyordu — kalıcı, fark edilmesi zor bir hesap ele geçirme.

---

2. Temel Teori

Kök neden — ambient credentials. Web oturumları "ortam kimlik bilgisi" (ambient credential) modeli kullanır: bir kez giriş yapıldığında, oturum çerezi tarayıcıda saklanır ve o siteye giden her istekte otomatik gönderilir. Bu, kolaylık sağlar (her sayfada tekrar giriş gerekmez) ama bir güvenlik açığı yaratır: istek kim tarafından başlatıldı, sunucu bilemez. Çerez geçerliyse istek "meşru" sayılır.

CSRF için üç koşul gerekir: 1. Durum değiştiren bir eylem. Para transferi, e-posta filtresi, parola/e-posta değişimi, ayar güncelleme. (Salt okuma eylemleri CSRF ile doğrudan sızdırılamaz — saldırgan yanıtı okuyamaz.) 2. Çerez tabanlı (ambient) oturum. Tarayıcı çerezi otomatik ekliyorsa. (İstek başına açıkça gönderilen token'lar — ör. Authorization başlığı — otomatik eklenmez, bu yüzden CSRF'e daha dirençlidir.) 3. Öngörülebilir istek. Saldırgan isteğin tüm parametrelerini önceden bilebilmeli; tahmin edilemez bir değer (anti-CSRF token) gerekiyorsa saldırı çöker.

CSRF vs XSS — kritik ayrım. İkisi sık karıştırılır ama temelden farklıdır: - XSS (Bölüm 7): saldırganın kodu kurbanın origin'inde çalışır. Yanıtı okuyabilir, DOM'a erişir, token çalar — her şeyi yapar. - CSRF: saldırgan kod çalıştırmaz; tarayıcıya kör bir istek gönderttirir. Yanıtı okuyamaz (same-origin policy engeller); yalnızca eylemi tetikler.

Bu ayrım savunmayı belirler: CSRF token savunması, "saldırgan isteğin bir parçasını (token'ı) bilemez" varsayımına dayanır. Ama XSS bu varsayımı yıkar — XSS, sayfadaki token'ı okuyabildiği için CSRF token'ını da öğrenir. Bu yüzden XSS "CSRF'in üstünde" bir açıktır (Bölüm 7): bir XSS varsa CSRF savunması anlamsızlaşır.

Dört savunma yaklaşımı:

Savunma	Mekanizma	Not
Senkronizasyon token	Sunucu rastgele token üretir, forma gömer, doğrular	Klasik, sağlam; durum gerektirir
Double-submit cookie	Token hem çerezde hem istekte; karşılaştırılır	Durumsuz; dikkatli kurulmalı
SameSite çerez	Tarayıcı çapraz-site istekte çerezi kısıtlar	Modern; Lax çoğu tarayıcıda varsayılan (Bölüm 16)
Origin/Referer doğrulama	İsteğin kaynağını başlıktan kontrol et	Ek katman; HTTPS'te güvenilir

Güvenli metot ilkesi. GET (ve HEAD) güvenli metotlardır: durum değiştirmemelidirler. Durum değiştiren her eylem POST/PUT/DELETE olmalıdır. Bir GET isteği durum değiştiriyorsa, <img src="..."> gibi en basit yollarla CSRF'e açıktır.

---

3. Mimarisel Bakış

 CSRF AKIŞI:
   1) Kurban → banka.com'a giriş → oturum çerezi tarayıcıda
   2) Kurban → kotu-site.com'u ziyaret eder (giriş HÂLÂ açık)
   3) kotu-site.com'daki gizli form/otomatik istek:
        POST banka.com/transfer  { to: saldirgan, amount: 1000 }
   4) TARAYICI, banka.com'a giden isteğe banka.com ÇEREZİNİ ekler (otomatik)
   5) banka.com: geçerli çerez görür → isteği MEŞRU sanır → transfer yapılır
        ✗ saldırgan yanıtı OKUYAMAZ ama eylem TETİKLENDİ

 SAVUNMA (senkronizasyon token):
   Form üretilirken: sunucu rastgele TOKEN'ı forma gömer + oturuma yazar
   Gönderimde: sunucu, gelen token'ı oturumdakiyle karşılaştırır (hash_equals)
        → kotu-site.com token'ı BİLEMEZ (same-origin okuyamaz) → istek reddedilir

 XSS TOKEN'I ATLATIR (Böl. 7):
   XSS → kurbanın origin'inde çalışır → sayfadaki CSRF token'ını OKUR
        → geçerli token'la istek yapar → CSRF savunması ÇÖKER

Kritik gözlem: CSRF savunması "saldırgan token'ı bilemez" varsayımına yaslanır; bu varsayım yalnızca çapraz-site saldırgan için geçerlidir. Origin içinde çalışan bir XSS için değil.

---

4. Güvensiz Kod

Gerçekçi bir "e-posta/parola değiştir" ve "para transferi" akışı:

<?php
// ⚠️ GÜVENSİZ — CSRF koruması yok
declare(strict_types=1);
session_start();

// 1) Durum değiştiren POST, token yok
if ($_SERVER['REQUEST_METHOD'] === 'POST' && isset($_SESSION['uid'])) {
    $pdo->prepare('UPDATE users SET email = ? WHERE id = ?')
        ->execute([$_POST['email'], $_SESSION['uid']]);
    // saldırganın sayfası bu POST'u tetikleyip e-postayı değiştirebilir
}

// 2) Daha kötüsü: durum değiştiren GET
// GET /transfer?to=X&amount=1000
if (isset($_GET['to'])) {
    transfer($_SESSION['uid'], $_GET['to'], (int)$_GET['amount']);
    // <img src="banka.com/transfer?to=saldirgan&amount=1000"> ile tetiklenir
}
?>
<!-- Form: token yok -->
<form method="POST" action="/change-email">
  <input name="email">
  <button>Güncelle</button>
</form>

Ayrıca oturum çerezinde SameSite ayarı da yok (Bölüm 16), yani tarayıcı seviyesinde de savunma yok.

---

5. Açığın Analizi

Token'sız POST (change-email) — Form ve işleyici hiçbir anti-CSRF token içermiyor. İsteğin tüm parametreleri (email) saldırgan tarafından bilinebilir/öngörülebilir olduğundan, saldırganın sayfası aynı POST'u otomatik oluşturur (gizli form + JS submit). Tarayıcı oturum çerezini ekler, sunucu isteği meşru sanır ve kurbanın e-postasını değiştirir — bu, sonrasında parola sıfırlamayla (Bölüm 12) tam hesap devralmaya tırmanır.

Durum değiştiren GET (transfer) — İki kat tehlikeli. GET durum değiştirdiğinden, saldırgan en basit CSRF vektörünü kullanır: <img src="banka.com/transfer?to=...&amount=...">. Kurban kötü sayfayı görüntülemesi bile — hiçbir tıklama olmadan — isteği tetikler. Güvenli metot ilkesi (GET durum değiştirmez) ihlal edilmiş.

SameSite yok — Oturum çerezinde SameSite ayarı olmadığından, tarayıcı çapraz-site isteklerde de çerezi gönderir; hiçbir tarayıcı-seviyesi savunma yok (Bölüm 16).

Kök sorun: durum değiştiren istekler, "bu isteği gerçekten kurban mı başlattı?" sorusunu sormuyor. Öngörülebilir parametreler + ambient çerez = CSRF. Çözüm, isteğe saldırganın bilemeyeceği bir kanıt (token) eklemek veya tarayıcıyı çapraz-site çerez göndermekten alıkoymaktır (SameSite).

---

6. Hacker Bakış Açısı

Saldırgan CSRF'i nasıl arar?

Durum değiştiren eylemleri haritalar. Para transferi, e-posta/parola değişimi, ayar güncelleme, filtre/kural ekleme, kullanıcı ekleme gibi yan etkili uç noktaları tespit eder. Bunlar CSRF hedefleridir; salt okuma uç noktaları (yanıt okunamadığı için) doğrudan hedef değildir.

Token varlığını ve doğrulamasını yoklar. İsteklerde anti-CSRF token olup olmadığına bakar. Token varsa: (1) gerçekten doğrulanıyor mu, yoksa yalnızca var mı? (2) Token'ı çıkarınca istek yine geçiyor mu? (3) Başka bir kullanıcının token'ı kabul ediliyor mu (oturuma bağlı değil)? (4) Token tahmin edilebilir mi? Birçok uygulama token üretir ama düzgün doğrulamaz.

SameSite'a bakar. Oturum çerezinde SameSite yoksa veya None ise, tarayıcı-seviyesi savunma yoktur. Lax ise, üst düzey GET navigasyonları hâlâ çerez taşır (bu yüzden GET durum değiştirmemeli).

Metot/format oynar. POST korunuyorsa GET denenmemiş olabilir; JSON API'ler Content-Type değişimiyle "basit istek" hâline getirilip CORS ön kontrolü atlatılabilir. Token yalnızca form gönderiminde kontrol ediliyor olabilir, API'de değil.

XSS'i düşünür. Sağlam CSRF token'ı varsa, saldırgan bir XSS (Bölüm 7) arar — çünkü XSS token'ı origin içinden okuyup CSRF savunmasını atlatır. İki açık bu noktada birleşir.

Savunmacı dersi: Saldırgan yalnızca "token var mı?" değil, "token doğru doğrulanıyor mu?" diye sorar. Token üretmek yetmez; oturuma bağlı, sabit-süreli (hash_equals) ve her durum değiştiren istekte zorunlu olmalıdır.

---

7. Exploit Mantığı

Bu bölüm çalıştırılabilir saldırı içermez. CSRF'in neden bu kadar sinsi olduğu kavramsaldır:

• Kurbanın yetkisini ödünç alma. Saldırgan kurbanın kimlik bilgisini çalmaz; kurbanın tarayıcısını, kurbanın kendi yetkisiyle bir eylem yaptırmaya kandırır. Sunucu için istek tümüyle meşrudur.
• Etkileşim gerektirmeyebilir. Durum değiştiren GET veya otomatik gönderilen bir form ile, kurbanın kötü sayfayı görmesi yeter; tıklama bile gerekmeyebilir.
• Kalıcılık. Gmail vakasında olduğu gibi, tek bir CSRF ile kalıcı bir yapı (yönlendirme filtresi, yeni yönetici hesabı) kurulabilir; bu, ilk açık kapatılsa bile etkiyi sürdürür.
• Görünmezlik. Yanıt saldırgana dönmez ve eylem kurbanın oturumunda gerçekleştiğinden, klasik alarmları tetiklemez; kurban ayarlarını kontrol etmedikçe fark etmeyebilir.
• XSS ile zincir. CSRF savunması sağlamsa, bir XSS token'ı okuyarak onu atlatır; iki açık birleşince savunma çöker.

Araştırmacının çerçevesi: (a) eylem durum değiştiriyor mu, (b) çerez ambient mi, (c) öngörülemez bir kanıt (token) gerekiyor ve doğrulanıyor mu, (d) SameSite var mı. Savunma (c) ve (d)'yi uygulayarak isteğin gerçekten kurbandan geldiğini kanıtlatır.

---

8. Güvenli Kod

Senkronizasyon token + SameSite + güvenli metot:

<?php
// ✅ GÜVENLİ — anti-CSRF token (senkronizasyon deseni)
declare(strict_types=1);
session_start();  // (Bölüm 16 ayarlarıyla: SameSite=Lax, Secure, HttpOnly)

/** Oturuma bağlı, rastgele CSRF token üret/getir */
function csrfToken(): string {
    if (empty($_SESSION['csrf'])) {
        $_SESSION['csrf'] = bin2hex(random_bytes(32));   // CSPRNG (Böl. 13)
    }
    return $_SESSION['csrf'];
}

/** Sabit-süreli doğrulama (Böl. 1) */
function csrfCheck(): void {
    $ok = isset($_POST['csrf'], $_SESSION['csrf'])
        && hash_equals($_SESSION['csrf'], (string)$_POST['csrf']);
    if (!$ok) {
        http_response_code(403);
        exit('CSRF doğrulaması başarısız');
    }
}

// Durum değiştiren eylem: yalnızca POST + token zorunlu
if ($_SERVER['REQUEST_METHOD'] === 'POST' && isset($_SESSION['uid'])) {
    csrfCheck();

    // Ek katman: Origin/Referer doğrulama (derinlemesine savunma)
    $origin = $_SERVER['HTTP_ORIGIN'] ?? parse_url($_SERVER['HTTP_REFERER'] ?? '', PHP_URL_HOST);
    if ($origin && !str_ends_with((string)$origin, 'example.com')) {
        http_response_code(403);
        exit('Geçersiz kaynak');
    }

    $pdo->prepare('UPDATE users SET email = ? WHERE id = ?')
        ->execute([$_POST['email'], $_SESSION['uid']]);
}
?>
<form method="POST" action="/change-email">
  <input type="hidden" name="csrf" value="<?= htmlspecialchars(csrfToken(), ENT_QUOTES, 'UTF-8') ?>">
  <input name="email">
  <button>Güncelle</button>
</form>

Framework araçları — elle yazmak yerine:

// Laravel — otomatik: VerifyCsrfToken middleware + @csrf direktifi
// <form>@csrf ... </form>   → token gizli alan olarak eklenir ve doğrulanır

// Symfony — CSRF token yönetimi:
// {{ csrf_token('change_email') }} ve isCsrfTokenValid(...)

Öne çıkan modern kalıplar: - Senkronizasyon token: random_bytes ile üret, oturuma bağla, hash_equals ile doğrula (Bölüm 1, 13). Klasik ve en sağlam yöntem. - SameSite çerez (Bölüm 16): Lax/Strict ile tarayıcı-seviyesi savunma; modern varsayılan. Token'ın tamamlayıcısı, tek başına değil. - Güvenli metot ilkesi: Durum değiştiren her eylem POST/PUT/DELETE; GET asla durum değiştirmez. - Origin/Referer doğrulama: Ek katman (özellikle HTTPS'te güvenilir). - API'ler için özel başlık: X-Requested-With gibi bir başlık, çapraz-origin'den (CORS olmadan) eklenemez; token'a alternatif/ek olabilir. Authorization başlığı tabanlı oturumlar (ambient olmadığı için) CSRF'e doğal dirençlidir. - Hassas eylemlerde re-authentication: Parola/e-posta değişimi gibi kritik işlemlerde tekrar parola/MFA iste.

---

9. Patch Analizi

Neden işe yarar? Senkronizasyon token, isteğe saldırganın bilemeyeceği bir kanıt ekler. Çapraz-site bir saldırgan, same-origin policy nedeniyle kurbanın sayfasındaki token'ı okuyamaz; dolayısıyla geçerli token'lı bir istek üretemez. hash_equals ile oturuma-bağlı doğrulama, token'ın hem gizli hem sabit-süreli karşılaştırılmasını sağlar. SameSite ise tarayıcıyı, çapraz-site isteklerde çerezi hiç göndermemeye yönelterek savunmayı tarayıcı seviyesine taşır. İki katman birlikte derinlemesine savunma oluşturur (Bölüm 1).

Savunmaların karşılaştırması:

Savunma	Güçlü yön	Sınır
Senkronizasyon token	Sağlam, olgun	Durum (oturum) gerektirir; XSS atlatır
Double-submit cookie	Durumsuz	Alt-alan/çerez enjeksiyonuna dikkat
SameSite=Lax	Otomatik, modern varsayılan	Üst-düzey GET; eski tarayıcı; None
SameSite=Strict	En sıkı	UX etkisi (dış linkten gelişte oturum yok)
Origin/Referer	Basit ek katman	Referer bazen ağda kırpılır

Kritik hatırlatma — XSS. Hiçbir CSRF token savunması, bir XSS varlığında geçerli değildir; XSS token'ı okur (Bölüm 7). Bu yüzden CSRF ve XSS savunmaları birlikte düşünülmelidir.

Performans: Token üretimi/doğrulaması bir hash ve karşılaştırmadır; ihmal edilebilir. SameSite ve Origin kontrolleri sıfıra yakın maliyetlidir. Güvenlik kazancı büyüktür.

---

10. Gerçek Hayat Senaryosu

Kurgu — bir kurumsal SaaS yönetim paneli. Panel, "yeni yönetici davet et" ve "fatura e-postasını değiştir" gibi durum değiştiren eylemleri POST ile yapıyor ama CSRF token'ı yok ve oturum çerezinde SameSite ayarlı değil. Bir saldırgan, hedef şirketin bir yöneticisine görünüşte zararsız bir bağlantı (örn. bir "rapor" sayfası) gönderiyor. Yönetici, panele giriş yapmışken bu sayfayı açtığında, sayfadaki gizli form otomatik olarak panele bir "saldırganı yönetici yap" POST'u gönderiyor; tarayıcı yöneticinin oturum çerezini eklediğinden istek başarılı oluyor ve saldırgan kalıcı yönetici erişimi kazanıyor — Gmail filter CSRF'inin kurumsal hâli. Dersler: (1) durum değiştiren her eylem CSRF token ve SameSite ile korunmalı; (2) tek bir CSRF, kalıcı bir arka kapıya (yeni yönetici) dönüşebilir; (3) hassas eylemlerde re-authentication ek bir bariyer kurardı.

---

11. Gerçek Vaka Analizi — Gmail Filter CSRF (2007)

Petko D. Petkov'un (GNUCITIZEN) açıklaması, dönem basını (Computerworld, The Register) ve akademik CSRF literatürüyle doğrulanmıştır. CSRF'in yüksek etkisini kanıtlayan ikonik vakadır.

Özet. Eylül 2007'de güvenlik araştırmacısı Petko Petkov, Gmail'in filtre özelliğini hedefleyen bir CSRF açığı açıkladı. Kurban, Gmail'e giriş yapmışken saldırganın hazırladığı bir sayfayı ziyaret ettiğinde, sayfa Gmail'e sessizce kötü niyetli bir filtre ekliyordu. Örnek filtre: "eki olan tüm e-postaları saldırganın adresine yönlendir." Filtre kalıcı olduğundan, gelecekteki e-postalar da yönlendiriliyordu — fark edilmesi zor, süregelen bir e-posta hırsızlığı.

Teknik neden — CSRF'in özünün kanıtı. Saldırganın sayfası, Gmail'in bir API uç noktasına bir multipart/form-data POST gönderiyordu. Kurban Gmail'e giriş yapmış olduğundan, tarayıcı bu çapraz-site isteğe kurbanın Gmail oturum çerezini otomatik ekledi (ambient credentials). Gmail sunucusu geçerli çerezi görünce isteği meşru sanıp filtreyi kurbanın hesabına ekledi. İstek, o dönem yeterli bir anti-CSRF token doğrulaması içermediğinden, saldırgan isteğin tüm parametrelerini önceden bilebiliyor ve forge edebiliyordu. Bu, "durum değiştiren eylem + ambient çerez + öngörülebilir istek" üçlüsünün (Bölüm 2) ders kitabı örneğidir.

Petkov'un vurguladığı incelik, kalıcılıktı: "Saldırı, filtre kurbanın listesinde kaldığı sürece — ilk açık Google tarafından düzeltilse bile — devam eder." Yani tek bir CSRF, kendi kendine yeten bir arka kapıya dönüşüyordu. Ayrıca kurbanın bunu fark etmesi için Gmail Ayarlar'daki Filtreler'i kontrol etmesi gerekiyordu; çoğu kullanıcı bunu yapmaz.

Etki. Kurbanın Gmail'ine kalıcı, sessiz bir e-posta yönlendirme mekanizması — pratikte hesap ele geçirmeye eşdeğer, çünkü e-posta çoğu servisin parola sıfırlama kanalıdır (Bölüm 12). Google açığı doğrulayıp düzeltti. Olay, CSRF'in "önemsiz" bir açık olmadığını, kalıcı hesap devralmaya varabildiğini gösterdi ve web genelinde anti-CSRF token uygulamalarını hızlandırdı.

Çıkarılacak dersler: 1. CSRF'in kökü ambient çerezdir. Durum değiştiren her eylem, isteğin gerçekten kullanıcıdan geldiğini kanıtlatmalıdır (token/SameSite). 2. CSRF kalıcı etki yaratabilir. Bir filtre/kural/hesap eklemek, ilk açık kapansa bile süren bir arka kapıdır. 3. Yüksek değerli eylemler ekstra korunmalı. E-posta yönlendirme gibi hesap-devralmaya varan işlemler, token'a ek olarak re-authentication gerektirmelidir.

---

12. Detection

Kod incelemede: Durum değiştiren uç noktaların token doğrulaması yapıp yapmadığını arayın:

# Durum değiştiren işlemler + token kontrolü var mı?
grep -rnE '(UPDATE|INSERT|DELETE|transfer|->save\()' src/ | grep -viE 'csrf|token'
grep -rn  'csrf\|VerifyCsrf\|isCsrfTokenValid' src/   # koruma nerede
grep -rnE '\$_GET\[' src/ | grep -iE 'UPDATE|DELETE|transfer'   # durum değiştiren GET
grep -rnE 'samesite' src/ php.ini   # tarayıcı-seviyesi savunma

Her durum değiştiren uç nokta için: token var ve doğrulanıyor mu? Oturuma bağlı mı? GET durum değiştiriyor mu? SameSite ayarlı mı?

SAST: Eksik CSRF koruması (CWE-352) için kurallar; framework-farkında araçlar korumasız durum-değiştiren rotaları işaretler.

DAST: Token'ı çıkararak/değiştirerek isteğin yine geçip geçmediğini; başka oturumun token'ının kabul edilip edilmediğini; durum değiştiren GET'leri test eder.

Loglar/SIEM: CSRF izleri zayıftır (istek meşru görünür); yine de yüksek Referer/Origin uyuşmazlığı olan durum-değiştiren istekler, tek bir dış sayfadan tetiklenen toplu eylemler ve 403 CSRF-red artışları izlenebilir. Origin/Referer loglaması burada değer katar.

---

13. Prevention

• Senkronizasyon token: random_bytes + oturuma bağlı + hash_equals; her durum değiştiren istekte zorunlu.
• SameSite çerez: Lax/Strict (Bölüm 16); token'ın tamamlayıcısı.
• Güvenli metot ilkesi: Durum değiştiren eylem asla GET olmaz.
• Origin/Referer doğrulama: Ek katman.
• Framework koruması: Laravel @csrf/VerifyCsrfToken, Symfony CSRF token; elle yazma.
• Hassas eylemlerde re-authentication: Parola/e-posta değişimi, para transferi gibi işlemlerde tekrar kimlik doğrulama/MFA.
• XSS'i de kapat (Bölüm 7): XSS, CSRF token'ını atlatır; ikisi birlikte savunulur.
• API'ler için: Ambient olmayan Authorization token'ları veya çapraz-origin eklenemeyen özel başlıklar.

---

14. Mitigation

• Acil: Durum değiştiren tüm uç noktalara token doğrulaması ekle; oturum çerezine SameSite=Lax ekle (Bölüm 16); durum değiştiren GET'leri POST'a çevir.
• Geçici: CSRF ile eklenmiş olabilecek kalıcı yapıları (yönlendirme filtreleri, yeni yöneticiler, değişmiş e-postalar) tespit edip temizle; etkilenen hesapları uyar/yeniden doğrula.
• Kalıcı: Framework CSRF korumasını global zorunlu kıl; SameSite'ı standartlaştır; hassas eylemlere re-authentication ekle; XSS savunmasını sıkılaştır; testler ekle.

---

15. Checklist

• [ ] Durum değiştiren her eylem CSRF token ile korunuyor ve token doğrulanıyor mu?
• [ ] Token random_bytes ile üretilip oturuma bağlı ve hash_equals ile mi doğrulanıyor?
• [ ] Oturum çerezinde SameSite=Lax/Strict var mı (Bölüm 16)?
• [ ] Durum değiştiren hiçbir eylem GET ile yapılmıyor mu?
• [ ] Origin/Referer doğrulaması (ek katman) var mı?
• [ ] Hassas eylemlerde (parola/e-posta/transfer) re-authentication var mı?
• [ ] API uç noktaları ambient-olmayan kimlik (Authorization/özel başlık) mı kullanıyor?
• [ ] XSS savunması sağlam mı (yoksa CSRF token atlanır — Bölüm 7)?

---

16. Laboratuvar

Lab 17.1 — Temel CSRF. İzole ortamda token'sız, durum değiştiren bir POST uç noktası kur; ayrı bir "saldırgan" sayfasından otomatik gönderilen bir formla eylemi tetikle. Sonra senkronizasyon token ekleyip saldırının neden başarısız olduğunu (token bilinemez) açıkla.

Lab 17.2 — GET tehlikesi. Durum değiştiren bir GET uç noktası yaz; <img src> ile tıklamasız tetiklendiğini gözlemle. POST + token'a çevirip düzelt.

Lab 17.3 — SameSite. Oturum çerezine SameSite=Lax ekle; çapraz-site bir POST'un çerezi taşımadığını (dolayısıyla oturumsuz kaldığını) gözlemle. None ile farkı gör.

Lab 17.4 — XSS atlatması. Sağlam CSRF token'lı bir sayfaya bir XSS ekle; XSS'in token'ı okuyup geçerli bir istek yapabildiğini göster. "XSS, CSRF savunmasını atlatır" dersini yaz (Bölüm 7).

---

17. Quiz

1. CSRF'in tek cümlelik kök nedeni nedir? "Ambient credentials" ne demektir?
2. CSRF için gereken üç koşul nedir?
3. CSRF ile XSS arasındaki temel fark nedir? Saldırgan CSRF'te yanıtı neden okuyamaz?
4. XSS, CSRF token savunmasını neden atlatır? Bu neden ikisinin birlikte savunulmasını gerektirir?
5. Senkronizasyon token deseni nasıl çalışır ve saldırgan token'ı neden bilemez?
6. SameSite çerez CSRF'e karşı ne sağlar? Lax ve Strict farkı nedir?
7. "Güvenli metot ilkesi" nedir? Durum değiştiren GET neden özellikle tehlikelidir?
8. Double-submit cookie deseni senkronizasyon token'dan nasıl farklıdır?
9. Gmail filter CSRF'i, CSRF'in "ambient çerez" mekanizmasını nasıl örnekler?
10. Bir CSRF neden kalıcı etki yaratabilir? Gmail vakasında bu nasıl oldu?
11. Token'ı "üretmek" ile "doğru doğrulamak" arasındaki fark nedir? Saldırgan hangi doğrulama hatalarını arar?
12. Hangi tür oturumlar (ambient çerez vs Authorization başlığı) CSRF'e doğal olarak daha dirençlidir ve neden?

---

18. Kaynakça

• OWASP, Cross-Site Request Forgery Prevention Cheat Sheet.
• OWASP, CSRFGuard projesi ve Testing for CSRF (WSTG).
• MITRE, CWE-352: Cross-Site Request Forgery.
• Barth, Jackson, Mitchell, Robust Defenses for Cross-Site Request Forgery (CCS 2008) — token, Origin, login CSRF.
• Petko D. Petkov (GNUCITIZEN), Google GMail E-mail Hijack Technique (2007); Computerworld ve The Register haberleri.
• IETF RFC 6265bis (SameSite çerezler); Laravel CSRF Protection ve Symfony CSRF dokümantasyonu.
• PHP Manual, random_bytes, hash_equals referansları (Bölüm 1, 13).