Bölüm 16

Session & Cookie Security

14 dk okuma2.832 kelimePHP 8.1+

Ön koşul

Bölüm 1 (randombytes, güven sınırı), Bölüm 12 (sessionregenerateid, fixation), Bölüm 13 (CSPRNG). İleri referanslar: Bölüm 7 (HttpOnly/XSS), Bölüm 17 (SameSite/CSRF).

Bu bölümün kazanımı

Oturumu, sunucunun durumu tuttuğu ve istemcinin yalnızca bir "anahtar" (session ID) taşıdığı bir mekanizma olarak kavrayacak; o anahtarın çalınması (hijacking), sabitlenmesi (fixation) ve tahmin edilmesi (prediction) saldırılarını; ve çerez bayraklarının (HttpOnly, Secure, SameSite) her birinin hangi saldırıyı kapattığını göreceksiniz.

1. Giriş

Kimlik doğrulama (Bölüm 12) "sen kimsin?" sorusunu bir kez yanıtlar; ama HTTP durumsuz (stateless) bir protokoldür — her istek birbirinden bağımsızdır. Peki bir kullanıcı giriş yaptıktan sonra, sonraki isteklerinde onu nasıl tanırız? Cevap oturumdur (session): sunucu, giriş yapmış kullanıcının durumunu saklar ve istemciye bu duruma erişim veren bir anahtar — session ID — verir. İstemci bu anahtarı bir çerezde taşır ve her istekte geri gönderir.

Bu tasarımın güvenlik sonucu kritiktir: session ID, hesabın anahtarıdır. Onu ele geçiren, parolayı hiç bilmeden kullanıcının yerine geçer. Bu yüzden oturum ve çerez güvenliği, kimlik doğrulamanın devamı ve tamamlayıcısıdır: en güçlü giriş bile, oturum anahtarı korunmazsa anlamsızdır.

Bu gerçeği tüm sektöre kanıtlayan olay 2010'daki Firesheep'ti (Bölüm 11): açık bir WiFi ağında, HTTP üzerinden gönderilen oturum çerezlerini yakalayıp tek tıkla başkasının Facebook/Twitter hesabına giren bir Firefox eklentisi. Parola çalmaya gerek yoktu — sadece çereze. Firesheep, "çerezi koru" dersini herkese öğretti ve web'in HTTPS'e geçişini hızlandırdı.

2. Temel Teori

Oturum mekanizması. Klasik akış: kullanıcı giriş yapar → sunucu bir oturum oluşturur ve rastgele bir session ID üretir → ID istemciye bir çerezle gönderilir → istemci her istekte çerezi geri gönderir → sunucu ID'yi kullanarak oturumu bulur ve kullanıcıyı tanır. Oturum verisi sunucuda (dosya, Redis, DB) tutulur; istemci yalnızca ID'yi taşır.

Session ID'nin iki temel gereksinimi: 1. Yüksek entropi / tahmin edilemezlik. ID kriptografik rastgelelikle (CSPRNG) üretilmeli; tahmin/sıralı olmamalı. Zayıf ID → session prediction (Bölüm 13, random_bytes). 2. Gizlilik. ID, aktarımda (ağ) ve depolamada (tarayıcı, sunucu) korunmalı; sızarsa hesap ele geçirilir.

Üç temel oturum saldırısı:

Saldırı	Mekanizma	Ana savunma
Hijacking (çalma)	ID'yi ele geçir (XSS, sniffing/sidejacking)	HttpOnly, Secure/HTTPS
Fixation (sabitleme)	Kurbanı bilinen bir ID'yle giriş yaptır	Girişte `session_regenerate_id`, strict mode
Prediction (tahmin)	Zayıf ID'yi tahmin et	CSPRNG, yüksek entropi

Çerez güvenlik bayrakları — her biri bir saldırıyı kapatır:

Bayrak	Ne yapar	Kapattığı saldırı
HttpOnly	JS'in `document.cookie` ile okumasını engeller	XSS ile çerez çalma (Bölüm 7)
Secure	Çerezi yalnızca HTTPS üzerinden gönderir	Sidejacking/sniffing (Firesheep)
SameSite	Çapraz-site isteklerde çerez gönderimini kısıtlar	CSRF (Bölüm 17)
Domain/Path	Çerezin kapsamını daraltır	Aşırı paylaşım
`__Host-` öneki	Çerezi tek host'a + Secure + Path=/ zorlar	Alt alan/kapsam kaçakları

PHP'ye özgü tuzak — session fixation ve use_strict_mode. PHP tarihsel olarak, istemcinin kendi belirlediği bir session ID'yi "benimseyebiliyordu" (session adoption). Saldırgan kurbana bilinen bir ID verip, kurban o ID ile giriş yaptığında oturumu devralabiliyordu (fixation). Çözüm iki katmanlı: (1) session.use_strict_mode = 1 — PHP, başlatılmamış/bilinmeyen ID'leri reddeder ve yenisini üretir; (2) girişte ve yetki değişiminde session_regenerate_id(true) — ID'yi yenileyip eski oturumu geçersiz kılar.

3. Mimarisel Bakış

 OTURUM AKIŞI:
   Giriş → sunucu: oturum oluştur + rastgele SID (CSPRNG)
        → Set-Cookie: PHPSESSID=...; HttpOnly; Secure; SameSite=Lax
   Sonraki istekler → Cookie: PHPSESSID=... → sunucu oturumu bulur → kullanıcı tanınır
   Çıkış → sunucu oturumu YOK ET + çerezi sil

 HIJACKING (Firesheep türü):
   Kurban  → HTTP (şifresiz) → SID ağda açıkta
        ↓  saldırgan aynı ağda paket dinler
   SID ele geçirilir → saldırgan aynı SID ile → hesap devralınır
        ✗ Secure bayrağı + HTTPS bunu kapatır

 FIXATION:
   Saldırgan → kurbana bilinen SID'yi verir (link/çerez enjeksiyonu)
        ↓  kurban o SID ile GİRİŞ yapar
   Saldırgan aynı SID'yi kullanır → kurbanın oturumunu devralır
        ✗ Girişte session_regenerate_id + use_strict_mode bunu kapatır

 XSS ile çalma:
   XSS (Böl. 7) → document.cookie okunur → SID dışarı sızdırılır
        ✗ HttpOnly bunu kapatır (JS çerezi okuyamaz)

Kritik gözlem: her saldırının ayrı bir savunması var ve bunlar birbirini tamamlar (derinlemesine savunma, Bölüm 1). Tek bir bayrak tüm saldırıları kapatmaz.

4. Güvensiz Kod

Gerçekçi bir oturum kurulumu ve giriş/çıkış akışı:

<?php
// ⚠️ GÜVENSİZ — çoklu oturum/çerez hatası
declare(strict_types=1);

session_start();   // varsayılan ayarlar; HttpOnly/Secure/SameSite yok, strict mode yok

// Giriş — ID yenilenmiyor (fixation)
if (password_verify($_POST['password'], $storedHash)) {
    $_SESSION['uid'] = $userId;     // aynı SID korunur → fixation açık
}

// "Beni hatırla" — hassas veriyi çerezde saklama
setcookie('user', $userId);         // HttpOnly/Secure yok; kimlik çerezde açıkça

// Çıkış — oturum gerçekten yok edilmiyor
function logout(): void {
    unset($_SESSION['uid']);        // sadece bir anahtar siliniyor; oturum + çerez duruyor
}

// Zaman aşımı yok — oturum süresiz açık kalır

Ayrıca php.ini'de tipik güvensiz varsayımlar: session.cookie_secure = 0, session.cookie_httponly = 0, session.use_strict_mode = 0.

5. Açığın Analizi

session_start() (çıplak) — Varsayılan çerez bayrakları eksik. HttpOnly yoksa, bir XSS (Bölüm 7) document.cookie ile SID'yi çalabilir. Secure yoksa, SID HTTP üzerinden açıkta gider (Firesheep). SameSite yoksa, CSRF (Bölüm 17) kolaylaşır. use_strict_mode kapalıysa fixation mümkündür.

Girişte ID yenilenmemesi — Session fixation. Kullanıcı giriş yaptığında SID değişmediğinden, saldırgan önceden kurbana verdiği bir SID'yi giriş sonrası kullanarak oturumu devralır. Girişte session_regenerate_id(true) yapılmalıydı (Bölüm 12).

setcookie('user', $userId) — Kimlik/durum istemci çerezinde açıkça saklanıyor. İstemci çerezi değiştirebildiğinden (Bölüm 1), kullanıcı user değerini başkasınınkiyle değiştirip kimlik taklidi yapabilir. Durum sunucuda tutulmalı; çerez yalnızca opak, imzalı/rastgele bir referans taşımalı.

logout() yetersiz — Yalnızca bir oturum anahtarı siliniyor; oturum sunucuda ve çerez tarayıcıda duruyor. Gerçek çıkış: session_destroy() + oturum çerezini silme + $_SESSION = []. Aksi hâlde eski SID hâlâ geçerli olabilir.

Zaman aşımı yok — Oturum süresiz açık kaldığından, çalınan bir SID sonsuza dek kullanılabilir. Boşta (idle) ve mutlak (absolute) zaman aşımı gerekir.

Kök sorun: oturum anahtarı yeterince korunmuyor (bayraklar), yenilenmiyor (fixation), yok edilmiyor (logout) ve süresiz (timeout). Her biri ayrı bir savunma gerektirir.

6. Hacker Bakış Açısı

Saldırgan oturumu nasıl hedefler?

Anahtarı çalmaya çalışır. Üç yol arar: (1) Ağ dinleme — trafik HTTP ise (ya da HTTPS'e karışmış HTTP varsa) SID'yi yakalar (Firesheep). (2) XSS — bir script enjekte edip document.cookie ile SID'yi dışarı sızdırır (Bölüm 7); çerez HttpOnly değilse başarır. (3) Yan kanal — Referer başlığı, loglar, tarayıcı geçmişi, URL'de taşınan SID (use_trans_sid).

Fixation dener. Kurbana bilinen bir SID "yerleştirmeye" çalışır: bir bağlantıya SID gömer, bir alt alan üzerinden çerez enjekte eder veya use_trans_sid açıksa URL'e ekler. Kurban o SID ile giriş yaptığında, giriş sonrası SID değişmiyorsa oturumu devralır.

Tahmin edilebilirliği yoklar. SID'lerin biçimini inceler; kısa, sıralı veya öngörülebilir (zaman/sayaç tabanlı) ID'ler tahmin edilebilir. Yeterli entropi yoksa, geçerli oturumları kaba kuvvetle bulmayı dener.

Kalıcılığı test eder. Çıkış yaptıktan sonra eski SID'nin hâlâ geçerli olup olmadığını, zaman aşımının çalışıp çalışmadığını kontrol eder. Sunucuda yok edilmeyen oturum, çalınmış bir SID'yi süresiz kılar.

Kapsam kaçaklarını arar. Çerez Domain fazla genişse (alt alanlara yayılıyorsa), bir alt alandaki daha zayıf bir uygulama (veya XSS) ana oturumu ele geçirebilir. __Host- öneki ve dar kapsam bunu kapatır.

Savunmacı dersi: Saldırgan oturum anahtarına ulaşmanın her yolunu dener — ağ, JS, tahmin, kalıcılık, kapsam. Savunma bu yolların her birini ayrı bir bayrak/ayarla kapatmalıdır.

7. Exploit Mantığı

Bu bölüm çalıştırılabilir saldırı içermez. Oturum ele geçirmenin neden bu kadar güçlü olduğu kavramsaldır:

Anahtar = tam erişim. Session ID bir "taşıyıcı token"dır (bearer token): onu sunan herkes, kim olduğuna bakılmaksızın oturumun sahibi sayılır. Parola, MFA, hiçbir şey tekrar sorulmaz. Bu yüzden SID'nin çalınması, kimlik doğrulamanın tümüyle atlanmasıdır.
Sessizlik. Çalınan bir SID ile yapılan istekler meşru görünür; Firesheep'te "birinin sizi dinlediğini tespit etmenin bir yolu yoktu". Hijacking, klasik alarmları tetiklemez.
Fixation'ın inceliği. Fixation'da saldırgan SID'yi çalmaz, kurbanın onu benimsemesini sağlar. Kurban kendi kimlik bilgileriyle giriş yapar ama saldırganın bildiği bir oturuma girer — bu yüzden tespiti zordur.
Kalıcılık. Zaman aşımı ve düzgün logout yoksa, bir kez çalınan anahtar süresiz kullanılır.

Araştırmacının çerçevesi: (a) SID nasıl korunuyor (bayraklar, HTTPS), (b) girişte yenileniyor mu (fixation), (c) yeterli entropi var mı (prediction), (d) yok ediliyor/süreli mi. Savunma bu dördünü kapatarak anahtarı hem korur hem de ele geçirilse bile ömrünü sınırlar.

8. Güvenli Kod

Oturum ve çerezleri baştan sona sağlamlaştıran sürüm:

<?php
// ✅ GÜVENLİ — sağlamlaştırılmış oturum
declare(strict_types=1);

// 1) Oturum çerezi parametreleri — start'tan ÖNCE
session_set_cookie_params([
    'lifetime' => 0,            // tarayıcı oturumu boyunca
    'path'     => '/',
    'domain'   => '',           // yalnızca mevcut host (alt alanlara yayma)
    'secure'   => true,         // yalnızca HTTPS (Firesheep savunması)
    'httponly' => true,         // JS okuyamaz (XSS savunması, Böl. 7)
    'samesite' => 'Lax',        // CSRF savunması (Böl. 17)
]);
ini_set('session.use_strict_mode', '1');   // fixation: bilinmeyen ID reddedilir
ini_set('session.use_only_cookies', '1');  // URL'de SID taşıma (use_trans_sid) kapalı
ini_set('session.sid_length', '48');       // yeterli entropi
ini_set('session.sid_bits_per_character', '6');
session_name('__Host-sess');               // __Host- öneki: sıkı kapsam
session_start();

// 2) Giriş — ID'yi YENİLE (fixation savunması, Böl. 12)
if (password_verify($_POST['password'], $storedHash)) {
    session_regenerate_id(true);           // eski SID geçersiz kılınır
    $_SESSION['uid']        = $userId;      // durum SUNUCUDA
    $_SESSION['created_at'] = time();
    $_SESSION['last_seen']  = time();
}

// 3) Her istekte: zaman aşımı (idle + absolute)
$now = time();
if (isset($_SESSION['uid'])) {
    if ($now - $_SESSION['last_seen'] > 1800          // 30 dk boşta
        || $now - $_SESSION['created_at'] > 28800) {  // 8 saat mutlak
        logout();
        exit('Oturum süresi doldu');
    }
    $_SESSION['last_seen'] = $now;
    // Yetki değişiminde (ör. rol yükseltme) tekrar regenerate
}

// 4) Çıkış — oturumu GERÇEKTEN yok et
function logout(): void {
    $_SESSION = [];
    if (ini_get('session.use_cookies')) {
        $p = session_get_cookie_params();
        setcookie(session_name(), '', time() - 42000,
                  $p['path'], $p['domain'], $p['secure'], $p['httponly']);
    }
    session_destroy();
}

Öne çıkan modern PHP kalıpları: - Çerez bayrakları: secure + httponly + samesite üçlüsü — her biri farklı bir saldırıyı (sidejacking / XSS-çalma / CSRF) kapatır. - use_strict_mode = 1: Session fixation'ın PHP-özgü kök nedenini kapatır. - use_only_cookies = 1: SID'nin URL'de (Referer/loglara) sızmasını engeller. - session_regenerate_id(true): Girişte ve yetki değişiminde; fixation savunması (Bölüm 12). - __Host- öneki: Çerezi tek host'a, Secure'e ve Path=/'e zorlar; kapsam kaçaklarını kapatır. - Zaman aşımı: Boşta (idle) + mutlak (absolute); çalınan anahtarın ömrünü sınırlar. - Gerçek logout: session_destroy() + çerez silme + $_SESSION = []. - Durum sunucuda: Kimlik/rol çerezde açıkça saklanmaz; çerez yalnızca opak SID taşır. - Güvenli depolama: Oturum dosyaları dar izinli dizinde ya da Redis/DB'de (paylaşımlı sunucuda /tmp riski, Bölüm 1).

9. Patch Analizi

Neden işe yarar? Her ayar bir saldırı vektörünü kapatır: Secure + HTTPS ağ dinlemeyi (Firesheep) imkânsız kılar; HttpOnly XSS ile çerez çalmayı engeller; SameSite CSRF'i kısıtlar; use_strict_mode + session_regenerate_id fixation'ı kapatır; yüksek entropi tahmini önler; zaman aşımı + logout ömrü sınırlar. Bu, tek bir kontrol değil, katmanlı savunmadır (Bölüm 1) — biri atlansa da diğerleri tutar.

Bayrakların saldırı-savunma haritası:

Saldırı	Onu kapatan ayar
Ağ dinleme (sidejacking)	`Secure` + site geneli HTTPS
XSS ile çerez çalma	`HttpOnly`
CSRF	`SameSite` (Bölüm 17)
Session fixation	`use_strict_mode=1` + `session_regenerate_id(true)`
Session prediction	CSPRNG + yeterli `sid_length`
URL'de SID sızıntısı	`use_only_cookies=1`
Kapsam kaçağı	`__Host-` / dar Domain
Çalınan anahtarın kalıcılığı	idle + absolute timeout, logout

Performans: Tüm bu ayarların çalışma zamanı maliyeti yok denecek kadar azdır (birkaç çerez bayrağı, bir regenerate). HTTPS'in bir maliyeti vardır ama modern donanımda ihmal edilebilir ve zaten zorunludur. Güvenlik kazancı devasadır.

10. Gerçek Hayat Senaryosu

Kurgu — bir kurumsal SaaS gösterge paneli. Uygulama HTTPS kullanıyor ama oturum çerezinde SameSite ve Secure bayrakları eksik ve use_strict_mode kapalı. Çalışanlar sık sık kafelerin/otellerin açık WiFi'lerinden bağlanıyor. Bir saldırgan, ağa karışan tek bir HTTP isteğinde (örneğin bir alt kaynak ya da yönlendirme) Secure olmayan oturum çerezini yakalayıp yöneticinin oturumunu devralıyor — Firesheep senaryosunun kurumsal hâli. Ek olarak, use_strict_mode kapalı olduğundan bir fixation saldırısı da mümkün. Dersler: (1) HTTPS "kullanmak" yetmez; oturum çerezi Secure işaretlenmeli ki hiçbir koşulda HTTP'ye düşmesin; (2) her çerez bayrağı farklı bir saldırıyı kapatır, hepsi gerekir; (3) use_strict_mode fixation'a karşı temel bir PHP ayarıdır.

11. Gerçek Vaka Analizi — Firesheep (2010)

Eric Butler'ın açıklamaları, Netcraft, Schneier ve dönem basınıyla doğrulanmıştır. Oturum güvenliğinin dönüm noktası vakasıdır.

Özet. 24 Ekim 2010'da, ToorCon 12 konferansında, programcı Eric Butler Firesheep adlı bir Firefox eklentisi yayımladı. Eklenti, açık (şifresiz) WiFi ağlarında HTTP üzerinden gönderilen oturum çerezlerini yakalıyor ve tek çift-tıklamayla o kullanıcının hesabına giriş yapmayı sağlıyordu — parolayı hiç bilmeden. Butler bunu bir saldırı aracı olarak değil, yaygın ama görmezden gelinen bir zafiyete dikkat çekmek için yayımladı. Facebook, Twitter, Flickr, Tumblr, WordPress dahil dönemin birçok büyük sitesi etkilendi.

Teknik neden — "sadece girişi şifrelemek" hatasının kanıtı. O dönem yaygın uygulama şuydu: siteler giriş sayfasını HTTPS ile koruyor (parolayı şifreliyor), ama giriş sonrası oturumun geri kalanını HTTP üzerinden sürdürüyordu — HTTPS'in "hesaplama maliyeti" gerekçesiyle. Sonuç: parola şifreli gitse de, sonraki her istekte oturum çerezi düz metin olarak ağda uçuyordu. Aynı açık ağdaki bir saldırgan, bir paket dinleyiciyle (Firesheep bunu WinPcap/libpcap ile otomatikleştiriyordu) bu çerezi yakalayıp aynen sunarak kurbanın oturumunu devralıyordu — "sidejacking". Kök neden, oturum çerezinin ne Secure bayrağıyla korunması ne de site genelinde HTTPS kullanılmasıydı.

Firesheep'in dâhiyane yanı yeni bir zafiyet bulması değildi — sidejacking yıllardır biliniyordu — onu herkesin yapabileceği kadar kolaylaştırmasıydı. Bu erişilebilirlik, sektörü harekete geçirdi.

Etki. Firesheep, oturum ele geçirmeyi "uzman işi" olmaktan çıkarıp bir eklenti tıklamasına indirgeyerek büyük yankı uyandırdı. Sonuç kalıcı oldu: Facebook, Twitter ve birçok büyük servis, kısa süre içinde site geneli HTTPS'i varsayılan yaptı; EFF'in "HTTPS Everywhere" hareketi ivme kazandı. Bugünkü "her yerde HTTPS + Secure çerez" normunun oluşmasında Firesheep bir dönüm noktasıdır.

Çıkarılacak dersler: 1. Yalnızca girişi şifrelemek yetmez; tüm oturum HTTPS olmalı. Oturum çerezi bir kez bile HTTP'ye düşerse ele geçirilebilir. 2. Secure bayrağı zorunludur. Çerezin hiçbir koşulda şifresiz gönderilmemesini garanti eder. 3. Session ID hesabın anahtarıdır. Parolayı kusursuz korumak, anahtarı korumadıkça anlamsızdır — güvenlik en zayıf halkası kadardır.

12. Detection

Kod incelemede: Oturum yapılandırmasını ve yaşam döngüsünü arayın:

grep -rn  'session_start\|session_set_cookie_params\|setcookie' src/
grep -rn  'session_regenerate_id'  src/   # girişte var mı?
grep -rnE 'cookie_secure|cookie_httponly|cookie_samesite|use_strict_mode' src/ php.ini
grep -rn  'session_destroy'         src/   # gerçek logout var mı?

Kontroller: Secure/HttpOnly/SameSite ayarlı mı? use_strict_mode=1 mi? Girişte regenerate var mı? Logout gerçekten yok ediyor mu? Kimlik çerezde açıkça mı?

SAST: Eksik çerez bayrakları (CWE-614/1004), fixation (CWE-384), zayıf SID (CWE-330) için kurallar. Konfigürasyon taraması (php.ini) da önemlidir.

DAST: Set-Cookie başlıklarını inceleyerek eksik bayrakları; girişten önce/sonra SID'nin değişip değişmediğini (fixation); çıkış sonrası SID'nin geçerliliğini test eder.

Loglar/SIEM: Aynı SID'nin farklı IP/User-Agent'lardan kullanılması (hijacking işareti — oturum ile ağ/istemci uyuşmazlığı); çok sayıda geçersiz/bilinmeyen SID denemesi (prediction/brute); coğrafi olarak imkânsız oturum kullanımı ("impossible travel"). Oturum anomalileri, hesap ele geçirme tespitinin en değerli sinyallerindendir.

13. Prevention

Site geneli HTTPS + Secure çerez: Oturum asla HTTP'ye düşmesin (Firesheep dersi). HSTS ekle.
HttpOnly: XSS ile çerez çalmayı kes (Bölüm 7).
SameSite=Lax/Strict: CSRF'i kısıtla (Bölüm 17).
use_strict_mode=1 + girişte session_regenerate_id(true): Fixation savunması (Bölüm 12).
use_only_cookies=1: SID'yi URL'den uzak tut.
Yüksek entropi SID: CSPRNG + yeterli uzunluk (prediction savunması).
__Host- öneki / dar kapsam: Kapsam kaçaklarını kapat.
Zaman aşımı (idle + absolute) + gerçek logout: Anahtarın ömrünü sınırla.
Durumu sunucuda tut: Kimlik/rol çerezde açıkça saklanmaz.
Güvenli depolama: Oturum deposu (dosya izinleri / Redis / DB) korunur (Bölüm 1, 28).

14. Mitigation

Acil: Oturum çerezine Secure+HttpOnly+SameSite ekle; use_strict_mode'u aç; girişte regenerate ekle; HTTPS/HSTS'i zorunlu kıl.
Geçici: Çalınmış olabilecek oturumları toplu geçersiz kıl (tüm SID'leri döndür); anomali loglarından ele geçirilen hesapları tespit et; kritik hesaplara yeniden kimlik doğrulama/MFA zorla.
Kalıcı: Oturum yapılandırmasını merkezî ve güvenli kalıba taşı; zaman aşımı + gerçek logout ekle; oturum anomali izlemesini kur; testler + konfigürasyon taraması ekle.

15. Checklist

[ ] Site geneli HTTPS + HSTS var ve oturum çerezi Secure mi?
[ ] Oturum çerezi HttpOnly mi (XSS-çalma savunması)?
[ ] SameSite ayarlı mı (CSRF savunması, Bölüm 17)?
[ ] session.use_strict_mode = 1 mi (fixation)?
[ ] Girişte ve yetki değişiminde session_regenerate_id(true) çağrılıyor mu?
[ ] session.use_only_cookies = 1 mi (URL'de SID yok)?
[ ] SID yeterli entropiye sahip mi (CSPRNG, uzunluk)?
[ ] Boşta + mutlak zaman aşımı var mı?
[ ] Çıkış oturumu gerçekten yok ediyor mu (session_destroy + çerez silme)?
[ ] Kimlik/rol çerezde açıkça saklanmıyor mu (durum sunucuda)?
[ ] Oturum deposu (dosya izinleri/Redis/DB) güvenli mi?

16. Laboratuvar

Lab 16.1 — Çerez bayrakları. İzole ortamda oturum çerezini önce bayraksız, sonra Secure+HttpOnly+SameSite ile kur. document.cookie'nin HttpOnly ile ne döndürdüğünü (Bölüm 7'ye bağla) ve tarayıcının Secure çerezi HTTP'de gönderip göndermediğini gözlemle.

Lab 16.2 — Fixation. Girişte regenerate yapmayan bir akış kur; giriş öncesi ve sonrası SID'nin aynı kaldığını gözlemle. session_regenerate_id(true) + use_strict_mode ekleyip fixation'ın kapandığını doğrula.

Lab 16.3 — Logout. Yalnızca unset($_SESSION['uid']) yapan bir logout yaz; eski SID ile oturumun hâlâ geçerli olduğunu göster. session_destroy + çerez silme ekleyip gerçek yok etmeyi doğrula.

Lab 16.4 — Zaman aşımı. Idle + absolute timeout uygula; süresi dolmuş bir oturumun reddedildiğini gözlemle.

17. Quiz

Session ID neden "hesabın anahtarı" ve bir "bearer token"dır? Bunun güvenlik sonucu nedir?
Session hijacking, fixation ve prediction arasındaki farkları açıklayın. Her birinin ana savunması nedir?
HttpOnly, Secure ve SameSite bayraklarının her biri hangi farklı saldırıyı kapatır?
Firesheep neden çalışıyordu? "Sadece girişi şifrelemek" neden yetersizdi?
Secure bayrağı olmadan HTTPS "kullanmak" neden yeterli bir savunma değildir?
PHP'de session fixation'ın kök nedeni nedir? use_strict_mode ve session_regenerate_id nasıl çözer?
use_only_cookies=1 neden önemlidir (SID nereye sızabilir)?
Kimlik/rolü istemci çerezinde saklamak neden tehlikelidir? Doğrusu nedir?
__Host- çerez öneki ne sağlar?
Neden hem idle hem absolute timeout gerekir? Çalınan bir anahtara karşı ne sağlarlar?
"Gerçek" bir logout nelerden oluşur? Yalnızca unset neden yetmez?
SIEM'de session hijacking'i gösteren iki anomali kalıbı nedir?

18. Kaynakça

OWASP, Session Management Cheat Sheet; Cookie Theft / Session Hijacking rehberleri.
OWASP, Top 10:2021 — A07 Identification and Authentication Failures (oturum yönetimi dahil).
MITRE, CWE-384: Session Fixation; CWE-614: Sensitive Cookie Without Secure; CWE-1004: Sensitive Cookie Without HttpOnly; CWE-613: Insufficient Session Expiration.
PHP Manual, session_set_cookie_params, session_regenerate_id, session_destroy ve Session Security (session.use_strict_mode, use_only_cookies) referansları.
Eric Butler, Firesheep (codebutler.com); Netcraft ve Bruce Schneier, Firesheep analizleri.
IETF RFC 6265 (HTTP State Management — çerezler); RFC 6265bis (SameSite, çerez önekleri).