Session Hijacking Nedir? Nasıl Korunalım?

Tarihsel kökenine bakınca, web uygulamalarında kullanıcı kimliğinin oluşturduğu güven zinciri, kullanıcıya özel bir oturum anahtarıyla bağlanır. Bu anahtar, genelde sunucuda bir oturum kimliği olarak saklanır ve tarayıcı ile sunucu arasında gönderilir. Ama bu akışta bazı zayıflıklar ortaya çıkarsa, kötü niyetli biri bu oturumu ele geçirip sizin adınıza hareket edebilir. Bu duruma “session hijacking” veya Türkçesiyle oturum ele geçirme denir. Temel mantık, yetkisiz birinin geçerli bir oturumu devralması ve kullanıcı haklarına erişmesidir.

Kritik noktalar ve tipik senaryolar

• Oturum kimliği ele geçirme: Bir kullanıcının oturum anahtarını ele geçirmek için man-in-the-middle saldırısı, trafikleri dinleme ya da zararlı eklentiler kullanılır. Özellikle güvenli olmayan bağlantılar veya zayıf şifrelemeler bu riski artırır.
• Oturum sabitleme (session fixation): Saldırgan, hedefin oturum kimliğini önceden belirler ve kullanıcının bu sabit kimlikle oturum açmasını sağlar. Kullanıcı normal şekilde giriş yaptıktan sonra saldırgan o kimlik üzerinden müdahale edebilir.
• Çerez güvenliği: Oturum kimliği çoğu tarayıcıda çerez olarak saklanır. HttpOnly ve Secure bayrakları olmadan çerezler kolayca yakalanabilir. Aynı alan adına sahip farklı istemcilerde çerezlerin paylaşımı da risk doğurabilir.
• Kimlik doğrulama sonrası akış hataları: Oturum sonlandırılmaması, oturumlar arası kalan yetkilerin yanlış yönetilmesi veya oturum süresinin aşırı uzun tutulması da ele geçirme ihtimalini artırır.

Güvenlik önlemleri ve uygulama pratikleri

• Ücretsiz ve açık protokoller yerine TLS kullanımı: Trafiğin şifreli olması, araçsal dinlemeyi önemli ölçüde azaltır. HTTP üzerindeki oturum kimliklerinin iletimi yerine HTTPS zorunlu olmalıdır.
• Oturum kimliği yönetimi: Oturum kimliklerini güvenli üretmek için rastgele ve yeterince uzun değerler kullanmalı, sabitleme karşıtı önlemler alınmalıdır. Ayrıca oturumlar zaman aşımı ile otomatik olarak sona ermeli.
• HttpOnly ve Secure çerezleri: Oturum kimliklerini içeren çerezler için HttpOnly ile JavaScript erişimini engellemek ve Secure ile sadece HTTPS üzerinden iletimi sağlamak kritik.
• Oturum yenileme (refresh) politikası: Kullanıcı hareketleri sırasında belirli aralıklarla oturum kimliği yenilenebilir, gerektiğinde yeniden doğrulama istenebilir. Uzun oturumlar için yeniden doğrulama, kritik işlemler öncesi veya belirli güvenlik duyarlılığında tetiklenmelidir.
• Koruma katmanları: CSRF koruması, güvenlik başlıkları (Content-Security-Policy gibi), ve sunucu tarafında oturum denetimi ile çok aşamalı güvenlik sağlanabilir.
• Ağ güvenliği: Yönlendirme ve VPN gibi ağ güvenliğinin kullanıcı tarafında da düşünülmesi gerekir. Güvenli ağa bağlı olmayan cihazlarda ek kontroller uygulanabilir.

Bu konuya dair pratik bir örnekle durumu somutlaştıralım: http üzerinden iletilen OTURUM Kimliği, ağ üzerinde kolayca yakalanabilir. Bir kullanıcı güvenli sitenin giriş yaptığı anda bile bu açıkta oturum açılırsa, saldırgan aynı oturumu ele geçirip işlemlere devam edebilir. Ancak TLS ile korunmuş bir site ve HttpOnly/Secure ayarlı çerezler bu tür riskleri ciddi oranda azaltır.

Çalışan güvenlik yaklaşımları ve güncel öneriler

• Tarayıcı tarafı güvenlik çözümleriyle uyumlu tasarım: Farklı tarayıcı güvenlik özellikleri ve API’ler, oturum yönetimini güçlendirir.
• Uygulama mimarisi tarafında oturumlar için merkezi yönetim ve yenileme politikaları oluşturulmalıdır. Mikroservis mimarilerinde her servis için ayrı oturum yönetimi veya merkezi bir token hizmeti kullanımı dikkat gerektirir.
• Geliştirme ve operasyon ekipleri, güvenlik testlerini düzenli olarak yapmalı; özellikle oturum yönetimi zayıflıkları için dinamik testler uygulanmalıdır.

Bu alanda deneyimleriniz neler? Kullandığınız çerez güvenlik tercihleri, oturum yenileme politikası veya oturum ele geçirme ile karşılaştığınız gerçek senaryolar varsa paylaşın. Sizce en etkili önlem hangi katmanda uygulanmalı?