Cookie, zaman aşımı ve çıkış için oturum yönetimi kontrolleri

Kullanıcı giriş yaptıktan sonra session ID, uygulamanın kullandığı en güçlü kimlik doğrulama yöntemine geçici olarak eşdeğer hale gelir. Bu yöntem parola, tek kullanımlık kod, istemci sertifikası, akıllı kart ya da parmak izi olabilir. Saldırgan bu ID'yi tahmin edebilir, ele geçirebilir veya kullanıcıya dayatabilirse kullanıcının kendisi olur ve giriş formunun devreye girmesine gerek kalmaz. Bu nedenle oturum testi; ID'nin kendisini, onu taşıyan cookie'yi ve sunucunun bu ID'yi girişte, boşta kalma süresinin ardından ve çıkışta nasıl ele aldığını test etmek demektir.

Bu kontrol listesi, OWASP Session Management Cheat Sheet ve cookie spesifikasyonu olan RFC 6265 esas alınarak hazırlanmıştır.

Session ID'nin kendisi

Önce ID'nin nasıl üretildiğine bakın. Cheat sheet, kriptografik olarak güvenli bir rastgele sayı üreticisinden en az 64 bit entropi şart koşar. Bu boyutta, saniyede 10.000 tahmin ve aynı anda 100.000 geçerli oturum varsayıldığında geçerli bir ID'yi tahmin etmenin yaklaşık 585 yıl süreceği hesaplanır. Framework'ün ürettiği ID'ler yerine kendi ID'lerinizi üretiyorsanız en az 128 bit ve her oturum için benzersiz bir değer önerilir.

Sabit veya tahmin edilebilir kısımlara dikkat edin. Yarısı sabit olan 16 karakterlik bir hexadecimal ID yalnızca 32 bit entropiye sahiptir ve bu yeterli değildir. Değer, istemci açısından da hiçbir anlam taşımamalıdır: içinde kullanıcı ID'si, rol veya e-posta bulunmamalıdır. Bu bilgiler sunucuda tutulmalıdır.

İsme de bakın. PHPSESSID, JSESSIONID, CFID/CFTOKEN ve ASP.NET_SessionId gibi varsayılan isimler saldırgana hangi teknoloji yığınını kullandığınızı söyler. Cheat sheet, id gibi genel bir isim kullanılmasını önerir.

ID'yi asla URL içinde kabul etmeyin. URL'de taşınan ID'ler bağlantılar, loglar, tarayıcı geçmişi, yer imleri, Referer header'ı ve arama motorları üzerinden sızar; ayrıca fixation saldırılarını kolaylaştırır.

Tehdit modelinizde session store'a okuma erişimi varsa ham token'lar risk oluşturur. Cheat sheet bölünmüş bir tasarım anlatır: cookie bir tanımlayıcı (identifier) ile gizli bir doğrulayıcı (verifier) taşır, sunucu ise tanımlayıcıyı ve doğrulayıcının SHA-256 hash'ini saklar ve karşılaştırmayı sabit zamanlı (constant time) yapar. Tanımlayıcı tek başına asla kabul edilmez.

Cookie öznitelikleri

RFC 6265, bir Set-Cookie header'ı için şu öznitelikleri tanımlar: Expires, Max-Age, Domain, Path, Secure ve HttpOnly.

• Secure, cookie'yi güvenli bağlantılar için işaretler. RFC, aktif bir ağ saldırganına karşı bütünlük sağlamadığı konusunda uyarır; bu nedenle onu böyle bir saldırgana karşı koruma olarak görmeyin.
• HttpOnly her session cookie'sinde bulunmalıdır. Bayrağı tarayıcı geliştirici araçlarında doğrulayın.
• Domain ve Path kapsamı belirler. İkisini de uygulamanın ihtiyacından geniş tutmayın.
• Expires ve Max-Age, tarayıcıya cookie'yi ne kadar süre saklayacağını bildirir. Bunları zaman aşımınız olarak kullanmayın.

Diğer response header'larınızı güvenlik header aracımızla inceleyin.

Giriş, zaman aşımları ve çıkış

Tarayıcının girişten önce sahip olduğu ve girişten sonra da kullanmaya devam ettiği bir session ID, fixation saldırılarının dayandığı şeydir. Kullanıcı kimlik doğruladığında yeni bir ID verin; böylece önceki ID geçerliliğini yitirir.

Zaman aşımı için iki sınır gerekir. Boşta kalma zaman aşımı (idle timeout), kimsenin kullanmadığı oturumları sonlandırır. Mutlak zaman aşımı (absolute timeout) ise sürekli etkin kalan oturumları sonlandırır; bu da çalınan bir ID'nin ne kadar süre işe yarayacağını sınırlar. Süreleri yazılı hale getirin, yönetim ve ödeme işlemleri için daha kısa tutun ve cookie'nin son kullanma tarihine değil, saklanan oturum kaydına bakarak sunucu tarafında uygulayın.

Çıkış (logout), sunucu taraflı oturumu yok etmelidir. Cookie'yi tarayıcıda silmek yeterli değildir, çünkü kimlik bilgisi tanımlayıcının kendisidir: onu daha önce kopyalayan herkes hâlâ gönderebilir. Çıkıştan sonra eski ID hiçbir şeyle eşleşmemelidir. Cheat sheet'te ayrıca web içeriği önbellekleme ve Clear-Site-Data üzerine bir bölüm vardır; çıkıştan sonra tarayıcının neleri sakladığını anlamak için okumaya değer.

Mümkün olduğunda framework'ün yerleşik oturum yönetimini kullanın. Cheat sheet, bu implementasyonlarda da zafiyetler görüldüğünü belirtir; bu yüzden en güncel sürümü çalıştırın ve varsayılan ayarları gözden geçirin.

Neler test edilmeli

1. Cookie'yi girişten önce ve sonra yakalayın. İlk istek gerçekten bir session cookie'si atamalıdır, bu yüzden before.txt dosyasının boş olmadığını kontrol edin. Kimlik bilgilerini shell geçmişinde kalmaması için bir dosyada tutun (user=test&pass=... içeren creds.txt). İki ID birbirinden farklı olmalıdır.

curl -i -c before.txt https://app.example/login curl -i -b before.txt -c after.txt -d @creds.txt https://app.example/login

1. Kimliği doğrulanmış cookie ile çıkış yapın, ardından after.txt dosyasının son sütunundaki eski değeri tekrar gönderin. İstek reddedilmelidir. Çıkış bir POST ise ilk komuta -d '' ekleyin.

curl -i -b after.txt https://app.example/logout curl -i -b 'id=VALUE_FROM_AFTER_TXT' https://app.example/account

1. Giriş yapın, boşta kalma zaman aşımını aşacak kadar bekleyin, sonra bir istek gönderin. Yeniden kimlik doğrulaması istenmelidir.
2. Bir oturumu mutlak zaman aşımını geçecek kadar etkin tutun. Yine de sonlanmalıdır.
3. Giriş yanıtındaki Set-Cookie header'ını Secure, HttpOnly ile ihtiyaçtan geniş olmayan Domain ve Path açısından inceleyin.
4. Birkaç yüz ID toplayıp karşılaştırın. Sabit bölümler ve ardışık değerler bulgudur. Cookie adını yukarıdaki framework varsayılanlarıyla karşılaştırın.
5. Uygulamada, loglarda ve bağlantılarda URL içinde geçen session ID'leri arayın.

Bulguları OWASP ASVS üzerinden, sürüm bilgisiyle birlikte raporlayın: v5.0.0-<chapter>.<section>.<requirement>. ASVS 5.0.0, 30 Mayıs 2025'te yayımlandı ve gereksinimleri CSV olarak sunuluyor. Test tablonuza her test için ilgili tanımlayıcıyı içeren bir sütun ekleyin; böylece başarısız bir test, ilgili gereksinime atıf yapan bir bulgu olarak okunur.

Nereden başlamalı

1. Önce staging ortamında 1 ve 2 numaralı testleri çalıştırın: girişten önceki ve sonraki ID karşılaştırması, ardından çıkış sonrası tekrar gönderme (replay) testi.
2. Session cookie'niz için Set-Cookie header'ını yakalayın; eksik veya fazla geniş olan öznitelikleri düzeltin.
3. ID'lerin nasıl üretildiğini kontrol edin. Kendi üreticinizi yazdıysanız framework'ün üreticisine geçin veya en az 128 bit ile güvenli bir rastgele kaynak kullandığını doğrulayın.
4. Boşta kalma ve mutlak zaman aşımlarını yazılı hale getirin, sunucu tarafında uygulayın ve biri bunları kaldırırsa başarısız olacak testler ekleyin.
5. Çıkışın sunucu taraflı oturum kaydını silmesini sağlayın ve replay testlerini regresyon paketinize ekleyin.