Web Uygulamalarında Jwt Kimlik Doğrulama Zafiyetleri Nasıl Tespit Edilir?

Web Uygulamalarında JWT Kimlik Doğrulama Zafiyetleri Nasıl Tespit Edilir?

Modern web mimarilerinde oturum yönetimi ve kimlik doğrulama süreçlerinin merkezinde yer alan JSON Web Token (JWT), doğru yapılandırılmadığında ciddi güvenlik açıklarına kapı aralamaktadır. Web uygulamalarında JWT kimlik doğrulama zafiyetleri nasıl tespit edilir sorusu, özellikle 2026 yılı siber güvenlik standartlarında, hem geliştiriciler hem de sızma testi uzmanları için kritik bir yetkinlik haline gelmiştir. Bir tokenin sadece taşınması değil, imza doğrulaması ve içerik güvenliği, uygulamanın bütününe yönelik yetkisiz erişim risklerini doğrudan etkiler.

Bu rehberde, JWT yapısının zayıf noktalarını analiz etme, imza manipülasyonlarını test etme ve yanlış yapılandırılmış kimlik doğrulama mekanizmalarını ortaya çıkarma yöntemlerini adım adım ele alacağız. Güvenlik testleri sırasında izlenecek metodolojiler, saldırganların bir token üzerinde değişiklik yaparak "admin" yetkilerine nasıl erişebileceğini anlamanızı sağlayacaktır. Unutmayın ki, bu işlemler yalnızca yetkili olduğunuz sistemler üzerinde gerçekleştirilmelidir; aksi durum yasal sorumluluklar doğurabilir.

JWT Yapısını ve Bileşenlerini Anlama

JWT, üç ana bölümden oluşur: Header (Başlık), Payload (Yük) ve Signature (İmza). Bu bölümler noktalarla birbirine bağlanır ve Base64Url ile kodlanır. Zafiyet tespiti yapabilmek için öncelikle bu yapının her bir parçasının ne işe yaradığını ve nerede hata yapılabileceğini bilmeniz gerekir.

Header Bölümündeki Kritik Parametreler

Header, tokenin türünü ve kullanılan imzalama algoritmasını belirtir. "alg" parametresi, sunucunun tokeni doğrulamak için hangi algoritmayı kullanacağını söyler. Test aşamasında, sunucunun "none" algoritmasını kabul edip etmediğini kontrol etmek, ilk adımınız olmalıdır. Eğer sunucu, algoritma belirtilmediğinde veya "none" olarak ayarlandığında tokeni onaylıyorsa, bu durum tam yetki kaybına yol açar.

Payload İçeriğinin Güvenlik Analizi

Payload, kullanıcı kimliği (sub), rol (role) ve tokenin geçerlilik süresi (exp) gibi bilgileri taşır. Geliştiriciler bazen hassas verileri bu alana eklerler. Base64Url kodlaması bir şifreleme değil, sadece bir formatlama yöntemidir. Bu nedenle, payload içindeki verilerin manipüle edilebilir olduğunu varsayarak testlerinizi kurgulamalısınız.

İmza Doğrulama Zafiyetlerinin Tespiti

İmza bölümü, tokenin bütünlüğünü korur. Sunucu, kendi gizli anahtarını kullanarak tokenin değiştirilip değiştirilmediğini kontrol eder. Ancak imza doğrulama süreci hatalı kurgulanmışsa, saldırganlar token içeriğini diledikleri gibi değiştirebilirler.

Algoritma Değiştirme (Algorithm Confusion) Saldırıları

En yaygın zafiyetlerden biri, "alg" parametresini HS256'dan (simetrik) RS256'ya (asimetrik) değiştirmektir. Eğer uygulama, imza doğrulaması yaparken kullanılan anahtarı yanlış yönetiyorsa, saldırgan kendi oluşturduğu anahtar ile tokeni imzalayabilir.

• Tokeni ele geçirin ve Base64Url kısmını decode edin.
• "alg" değerini RS256 olarak değiştirin.
• Payload kısmında "admin" veya "user_id" gibi değerleri değiştirin.
• Sunucunun açık anahtarını (public key) kullanarak yeni bir imza oluşturun.
• Uygulamanın bu yeni imzalı tokeni kabul edip etmediğini gözlemleyin.

Zayıf Gizli Anahtar (Brute Force) Analizi

Eğer sunucu HS256 algoritmasını kullanıyorsa, imza doğrulaması paylaşılan bir gizli anahtar ile yapılır. Eğer bu anahtar tahmin edilebilir veya kısa ise, kaba kuvvet saldırılarıyla (brute force) kırılabilir. Hashcat veya John the Ripper gibi araçlar, zayıf gizli anahtarları tespit etmek için kullanılır.

Uyarı: İmza doğrulaması bypass yöntemlerini denerken, sunucunun hata mesajlarını dikkatle inceleyin. "Invalid Signature" hatası alıyorsanız imza mekanizması çalışıyordur, ancak hiçbir hata almadan yetki yükseltme yapabiliyorsanız, imza doğrulama mekanizması hiç yok demektir.

JWT İçerik Manipülasyonu ve Yetki Yükseltme

JWT üzerinde yapılan değişikliklerin sunucu tarafından nasıl yorumlandığını anlamak, zafiyet tespitinin en önemli aşamasıdır. Yetki yükseltme (privilege escalation) saldırıları, genellikle token içindeki rol bilgilerinin değiştirilmesiyle gerçekleşir.

Rol Temelli Erişim Kontrolü (RBAC) Testleri

Uygulamanın "user" rolüne sahip bir tokeni kabul edip etmediğini kontrol ettikten sonra, bu değeri "admin" olarak güncelleyin. Eğer sunucu, tokenin imzasını doğrulamak yerine sadece payload içindeki rol bilgisine güveniyorsa, yetki yükseltme başarılı olacaktır.

Kullanıcı Kimliği (Sub) Değiştirme

Token içindeki "sub" veya "uid" alanlarını başka bir kullanıcının ID'si ile değiştirerek, başka bir kullanıcının hesabına erişip erişemediğinizi test edin. Bu durum, "Insecure Direct Object Reference" (IDOR) zafiyetinin JWT ile birleşmiş bir türüdür.

Sunucu Tarafı Yapılandırma Hataları

Bazen sorun JWT'nin kendisinde değil, sunucunun JWT'yi işleme biçimindedir. Sunucu tarafındaki yapılandırma hataları, tokenin geçerlilik süresinin kontrol edilmemesi veya kara liste (blacklist) mekanizmasının olmaması gibi sorunları kapsar.

Süresi Geçmiş Tokenlerin Kabul Edilmesi

Tokenin "exp" (expiration) alanı, tokenin ne kadar süre geçerli olacağını belirler. Test sırasında, süresi dolmuş bir tokeni kullanarak sunucuya istek gönderin. Eğer sunucu hala kabul ediyorsa, oturum yönetimi zafiyeti mevcuttur.

Kara Liste Mekanizmasının Eksikliği

JWT'ler "stateless" (durumsuz) yapıdadır. Bu nedenle bir tokeni iptal etmek zordur. Uygulamanın çıkış yaptıktan sonra tokeni geçersiz kılıp kılmadığını kontrol edin. Eğer çıkış yapsanız bile eski token hala çalışıyorsa, bu bir güvenlik zafiyetidir.

Güvenlik Testlerinde Kullanılan Araçlar ve Metodoloji

JWT zafiyetlerini manuel olarak tespit etmek mümkün olsa da, profesyonel araçlar süreci hızlandırır. Burp Suite gibi proxy araçları, tokenleri yakalayıp modifiye etmek için standarttır. Ayrıca JWT Editor eklentisi, imza oluşturma ve algoritma değiştirme süreçlerini kolaylaştırır.

Adım Adım Test Süreci

1. Uygulamanın trafiğini bir proxy aracı (Burp Suite) üzerinden geçirin.
2. Login olduktan sonra üretilen JWT'yi yakalayın.
3. JWT'yi decode ederek içeriğini analiz edin.
4. Payload üzerinde "role", "admin", "user_id" gibi alanları tespit edin.
5. JWT Editor eklentisi ile algoritmayı "none" yaparak veya imza kısmını boş bırakarak isteği tekrarlayın.
6. Sunucunun yanıtını (200 OK veya 403 Forbidden) inceleyerek zafiyeti doğrulayın.

Sıkça Sorulan Sorular

JWT'de "none" algoritması neden tehlikelidir?

Sunucu, "none" algoritmasını kabul ettiğinde imza kontrolünü tamamen devre dışı bırakır. Bu, saldırganın tokenin içeriğini istediği gibi değiştirmesine ve sunucunun bu sahte tokeni geçerli kabul etmesine neden olur.

JWT'nin Base64Url ile kodlanmış olması bir şifreleme midir?

Hayır, Base64Url sadece bir kodlama formatıdır. Veri gizliliğini sağlamaz. Bu nedenle JWT içerisine asla şifre, kredi kartı bilgisi veya kişisel veriler eklenmemelidir.

İmza doğrulaması neden başarısız olur?

İmza doğrulaması, sunucudaki gizli anahtar ile tokenin oluşturulduğu anahtarın eşleşmemesi durumunda başarısız olur. Eğer uygulama doğru yapılandırılmışsa, tokenin tek bir karakterini bile değiştirmek imzanın geçersiz olmasına neden olmalıdır.

JWT zafiyetlerini önlemek için geliştiriciler ne yapmalı?

Geliştiriciler her zaman güçlü bir imzalama algoritması (RS256 gibi) kullanmalı, "none" algoritmasını devre dışı bırakmalı ve gizli anahtarlarını güvenli bir şekilde (env dosyaları veya kasa sistemleri) saklamalıdır.

Süresi dolan tokenler nasıl iptal edilir?

JWT'ler doğası gereği iptal edilemez. Bu sorunu çözmek için sunucu tarafında bir "blacklist" (kara liste) tutulmalı veya kısa ömürlü tokenler ile birlikte "refresh token" mekanizması kullanılmalıdır.

Sonuç

Web uygulamalarında JWT kimlik doğrulama zafiyetleri, sistemin en temel savunma hattını hedef alır. Tespit süreci, token yapısının derinlemesine incelenmesini, imza mekanizmalarının sınırlarının zorlanmasını ve sunucunun hata paylarının analiz edilmesini gerektirir. 2026 yılı itibarıyla, sadece tokeni kullanmak değil, tokenin yaşam döngüsünü ve imza bütünlüğünü korumak, siber güvenlik profesyonellerinin öncelikli görevidir. Bu rehberde belirtilen adımları takip ederek ve etik kurallar çerçevesinde testlerinizi gerçekleştirerek, uygulamalarınızdaki kritik güvenlik açıklarını erkenden tespit edebilir ve gerekli önlemleri alabilirsiniz.

JWT Güvenlik Testlerinde İleri Düzey Senaryolar ve Analiz Yöntemleri

JWT (JSON Web Token) tabanlı kimlik doğrulama mekanizmalarını test ederken, sadece temel zafiyetleri değil, uygulamanın mimari tasarımındaki mantıksal hataları da incelemek gerekir. Aşağıdaki bölümlerde, profesyonel siber güvenlik uzmanlarının kullandığı gelişmiş test teknikleri ve yaygın yapılandırma hataları detaylandırılmıştır.

Kritik Zafiyetlerin Karşılaştırmalı Analizi

JWT uygulamalarında karşılaşılan en yaygın zafiyetler ve bunların risk seviyeleri, güvenlik testlerinde önceliklendirme yapmanıza yardımcı olur.

'kid' (Key ID) Parametresi Üzerinden Path Traversal

Header bölümünde yer alan kid parametresi, sunucunun imza doğrulama için hangi anahtarı kullanacağını seçmesini sağlar. Eğer bu parametre doğrudan dosya sistemine erişim için kullanılıyorsa, ciddi bir zafiyet oluşur.

• Senaryo: Sunucu, kid değerini bir dosya yolu olarak kabul eder.
• Test: {"kid": "../../dev/null"} şeklinde bir başlık göndererek sunucunun boş bir dosya ile imza doğrulamaya çalışıp çalışmadığını gözlemleyin.
• Sonuç: Eğer sunucu imza doğrulamayı atlıyorsa veya hata veriyorsa, sistemde bir "Path Traversal" açığı var demektir.

JWK (JSON Web Key) Enjeksiyonu

Bazı uygulamalar, imza anahtarını doğrudan JWT header'ı içerisinde jwk (JSON Web Key) parametresiyle alabilir. Eğer sunucu, gelen token içindeki jwk değerine güveniyorsa, saldırgan kendi genel anahtarını (public key) buraya ekleyerek sunucuyu kandırabilir.

Dikkat: Her zaman sunucunun imza doğrulaması için yalnızca güvenilir, sabit bir anahtar setini kullandığından emin olun. Gelen token içindeki anahtar verisine asla güvenmeyin.

JWT İçerik Manipülasyonunda Sık Yapılan Hatalar

Güvenlik testlerinde en çok karşılaşılan "mantıksal" hatalardan biri, token içeriğinin sunucu tarafından yeterince doğrulanmamasıdır. Test sürecinde şu adımları izleyin:

1. Payload Değiştirme: {"role": "user"} olan bir payload'u {"role": "admin"} olarak değiştirin.
2. İmza Yenileme: Eğer gizli anahtarı ele geçirdiyseniz, yeni bir imza oluşturun.
3. İmza Olmadan Gönderme: İmza kısmını tamamen silerek (veya boş bırakarak) sunucunun "none" algoritmasını kabul edip etmediğini kontrol edin.
4. Süresi Geçmiş Token: exp (expiration) değerini gelecekteki bir tarihe çekerek tokenin geçerliliğini test edin.

Güvenlik Testlerinde Kullanılan Araç Seti

Etik hackerlar, JWT analizlerini hızlandırmak ve otomatize etmek için belirli araçları tercih ederler:

• Burp Suite (JWT Editor Extension): JWT'leri decode etmek, modify etmek ve imza oluşturmak için standarttır.
• Hashcat: Zayıf gizli anahtarları brute-force ile kırmak için kullanılır.
• JWT-Tool: JWT zafiyetlerini otomatize bir şekilde tarayan açık kaynaklı bir Python aracıdır.
• CyberChef: Base64Url kodlamalarını hızlıca çözmek ve manipülasyon yapmak için idealdir.

Sunucu Tarafı Yapılandırma Hataları: "Audience" ve "Issuer" Kontrolü

Sadece imza kontrolü yeterli değildir. Bir JWT'nin aud (audience) ve iss (issuer) alanları da doğrulanmalıdır.

Neden Önemlidir?

Bir token, başka bir uygulama için üretilmiş olabilir. Eğer hedef uygulama iss (yayınlayan) alanını kontrol etmiyorsa, saldırgan kendi kontrolündeki bir uygulamadan aldığı geçerli bir tokeni, hedef uygulamaya karşı "cross-service" saldırısı olarak kullanabilir.

Token İptal Mekanizması ve "Refresh Token" Güvenliği

JWT'ler stateless (durumsuz) oldukları için sunucu üzerinde bir oturum kaydı tutmazlar. Ancak bu durum, çalınan bir tokenin süresi dolana kadar kullanılabileceği anlamına gelir.

Güvenlik İpuçları:

• Refresh Token Rotation: Her refresh token kullanımında eski olanı geçersiz kılın ve yenisini verin.
• Database Blacklist: Kullanıcı "çıkış" yaptığında, o tokenin jti (JWT ID) değerini veritabanında bir kara listeye ekleyin.
• Kısa Ömürlü Tokenler: Erişim tokenlerinin ömrünü 5-15 dakika ile sınırlandırın.

Örnek Senaryo: İmza Doğrulama Bypass

Bir web uygulamasında /api/profile endpoint'ine giden istekte şu JWT kullanılıyor:

Adım 1: Tokeni decode edin. Header'da HS256 algoritmik imza olduğunu görün.

Adım 2: Algoritmayı none olarak değiştirin ve payload'u {"sub": "admin"} yapın.

Adım 3: Tokeni Base64Url ile tekrar kodlayın ve imza kısmını (son nokta sonrası) boş bırakarak isteği gönderin.

Adım 4: Eğer sunucu "200 OK" dönüyorsa ve sizi admin olarak yetkilendiriyorsa, imza doğrulama mekanizması hatalıdır.

Geliştiriciler İçin Güvenlik Kontrol Listesi

Uygulamanızı yayına almadan önce şu maddelerin doğruluğunu teyit edin:

1. Tüm JWT isteklerinde alg parametresini sıkı bir şekilde beyaz listeden (whitelist) geçirin.
2. Gizli anahtar (Secret Key) uzunluğunun en az 256 bit olduğundan emin olun.
3. Token içerisinde hassas verileri (şifre, TC kimlik no vb.) asla düz metin olarak barındırmayın.
4. Tokenleri güvenli olmayan ortamlarda (localStorage gibi) değil, HttpOnly ve Secure flag'li çerezlerde saklayın.

Bu ileri düzey teknikler, bir web uygulamasının JWT mimarisindeki zayıf noktaları ortaya çıkarmak için gereklidir. Her zaman sistemin bütünlüğünü koruyacak şekilde, "en az ayrıcalık" prensibine uygun yapılandırmalar tercih edilmelidir.

JWT Güvenlik Testlerinde İleri Düzey Senaryolar ve Analiz Yöntemleri

Web uygulamalarında JWT (JSON Web Token) kullanımı yaygınlaştıkça, saldırganların bu token yapısını manipüle etmek için kullandığı teknikler de karmaşıklaşmaktadır. Temel imza bypass yöntemlerinin ötesinde, sunucu tarafındaki mantıksal hataları hedef alan ileri düzey analizler, güvenlik testlerinin vazgeçilmez bir parçasıdır.

Kritik Zafiyetlerin Karşılaştırmalı Analizi

JWT zafiyetlerini kategorize etmek, bir sızma testi uzmanının hangi vektöre odaklanması gerektiğini belirlemesi açısından kritiktir. Aşağıdaki tablo, yaygın JWT zafiyetlerini ve bunların etki düzeylerini özetlemektedir:

'kid' (Key ID) Parametresi Üzerinden Path Traversal

JWT başlığında bulunan kid parametresi, sunucunun imza doğrulaması için hangi anahtarı kullanacağını belirtir. Eğer geliştirici, bu parametreyi bir dosya yolu olarak doğrudan kullanıyorsa, saldırganlar sistemdeki kritik dosyaları okuyabilir.

Test Yöntemi:

• Header kısmına "kid": "../../dev/null" gibi bir değer ekleyin.
• Sunucunun bu anahtarı yüklemeye çalışırken hata verip vermediğini kontrol edin.
• Eğer sunucu hata mesajında dosya yolunu sızdırıyorsa veya belirli dosyaları okumaya çalışıyorsa, Path Traversal zafiyeti mevcuttur.

JWK (JSON Web Key) Enjeksiyonu

Bazı JWT kütüphaneleri, imza doğrulaması için gereken açık anahtarı doğrudan token başlığındaki jwk parametresinden alabilir. Bu, sunucunun kendi anahtarı yerine saldırganın sağladığı anahtarı kullanmasına yol açar.

Adım Adım Saldırı:

1. Saldırgan bir RSA anahtar çifti oluşturur (Public ve Private).
2. Token başlığına "jwk": { ... public key ... } ekler.
3. Token'ı kendi private anahtarıyla imzalar.
4. Sunucu, token'ı doğrulamak için başlıkta sağlanan sahte public anahtarı kullanır ve imza geçerli kabul edilir.

Sunucu Tarafı Yapılandırma Hataları: "Audience" ve "Issuer" Kontrolü

JWT'nin aud (audience) ve iss (issuer) alanları, token'ın hangi uygulama veya servis için üretildiğini belirtir. Bu alanların doğrulanmaması, bir servise ait token'ın başka bir serviste kullanılmasına (Cross-Service Replay Attack) neden olabilir.

Güvenlik Analizi:

Test sırasında, token'daki aud değerini değiştirerek isteği farklı bir uç noktaya (endpoint) gönderin. Eğer sunucu token'ı reddetmiyorsa, uygulama "Audience" doğrulamasını yapmıyor demektir. Bu durum, özellikle mikroservis mimarilerinde yatay yetki yükseltme saldırılarına kapı aralar.

Token İptal Mekanizması ve "Refresh Token" Güvenliği

JWT'lerin doğası gereği "stateless" (durumsuz) olması, iptal edilmelerini zorlaştırır. Çoğu uygulama, token'ın süresi dolana kadar yetkili kalmasına izin verir. Ancak, refresh token kullanımı bu süreci daha riskli hale getirir.

Dikkat Edilmesi Gerekenler:

• Refresh Token Rotasyonu: Her kullanımda yeni bir refresh token üretilmelidir. Eski token'ın tekrar kullanılması durumunda tüm oturumlar sonlandırılmalıdır.
• Kara Liste (Blacklist): İptal edilen token'lar veritabanında veya Redis gibi hızlı erişimli bir bellekte tutulmalıdır.
• İptal Testi: Kullanıcı şifresini değiştirdiğinde veya çıkış yaptığında, elinizdeki eski JWT ile istek göndererek token'ın hala geçerli olup olmadığını kontrol edin.

Örnek Senaryo: İmza Doğrulama Bypass

Aşağıdaki örnek, imza doğrulamasının zayıf olduğu bir senaryoda nasıl manipülasyon yapılacağını gösterir:

Header: {"alg": "HS256", "typ": "JWT"}
Payload: {"sub": "user_123", "role": "user"}
İmza: [Geçerli bir imza]

Saldırgan, payload kısmını {"sub": "admin", "role": "admin"} olarak değiştirir. Eğer sunucu, imza kontrolü sırasında hata verip "fail-open" (hata durumunda erişime izin ver) moduna geçiyorsa veya imza kontrolünü tamamen atlıyorsa, yetki yükseltme gerçekleşmiş olur.

Güvenlik Testlerinde Kullanılan Araç Seti

JWT analizlerinde profesyonel bir yaklaşım için şu araçlar standart kabul edilir:

• Burp Suite (JWT Editor Extension): Token'ları decode etmek, değiştirmek ve yeniden imzalamak için en güçlü araçtır.
• JWT.io: Hızlı token incelemeleri ve format kontrolü için kullanılır.
• Hashcat: Zayıf secret key'leri kırmak için GPU gücünden faydalanan bir araçtır.
• CyberChef: Base64Url kodlaması ve manipülasyonu için kullanılır.

Bu araçlar, manuel test süreçlerini hızlandırırken, karmaşık imza bypass senaryolarının daha kolay simüle edilmesini sağlar. Güvenlik uzmanları, bu araçları kullanırken her zaman "En Az Ayrıcalık" prensibine uygun test senaryoları geliştirmelidir.

JWT Güvenlik Analizinde İleri Düzey Saldırı Vektörleri

JWT (JSON Web Token) yapısı, modern web uygulamalarında durumsuz (stateless) kimlik doğrulama için standart haline gelmiştir. Ancak, uygulamanın mimarisindeki küçük bir hata, tüm güvenlik katmanının çökmesine neden olabilir. İleri düzey analizlerde, sadece imza kontrolü değil, token'ın yaşam döngüsü ve sunucu tarafındaki işleme mantığı da hedef alınmalıdır.

'kid' (Key ID) Parametresi Üzerinden Path Traversal ve Enjeksiyon

kid parametresi, sunucunun imza doğrulaması için hangi anahtarı kullanacağını belirten bir başlık alanıdır. Eğer sunucu bu parametreyi doğrudan dosya sisteminden bir anahtar okumak için kullanıyorsa, ciddi bir güvenlik açığı oluşur.

• Path Traversal: Saldırgan, kid değerini ../../../../etc/passwd gibi bir yola çevirerek sunucudaki hassas dosyaları anahtar olarak okumaya zorlayabilir.
• Dosya Okuma: Sunucu, saldırganın belirttiği dosyayı "public key" olarak kabul ederse, imza doğrulama süreci manipüle edilebilir.

JWK (JSON Web Key) Enjeksiyonu

Bazı uygulamalar, imza doğrulama anahtarını doğrudan JWT başlığı içinde jwk parametresiyle kabul eder. Bu, sunucunun anahtarı merkezi bir yerden almak yerine, saldırganın gönderdiği anahtara güvenmesi anlamına gelir.

1. Saldırgan kendi RSA anahtar çiftini oluşturur.
2. Payload'u istediği gibi değiştirir.
3. jwk parametresine kendi oluşturduğu "public key" değerini yerleştirir.
4. Sunucu, imzayı saldırganın gönderdiği public key ile doğrular ve token'ı geçerli kabul eder.

Sunucu Tarafı Yapılandırma Hataları: "Audience" ve "Issuer" Kontrolü

JWT standartları, token'ın kime ait olduğunu (aud - audience) ve kim tarafından oluşturulduğunu (iss - issuer) belirten alanlar içerir. Birçok geliştirici, bu alanların kontrolünü atlayarak sadece imza geçerliliğine odaklanır.

Token İptal Mekanizması ve "Refresh Token" Güvenliği

JWT'lerin en büyük dezavantajı, süreleri dolana kadar iptal edilememeleridir. Profesyonel bir güvenlik testinde, "Blacklist" (kara liste) mekanizmasının varlığı ve etkinliği mutlaka sorgulanmalıdır.

Önemli Not: Refresh token'lar, access token'lara göre çok daha uzun ömürlüdür. Eğer bir saldırgan refresh token'ı ele geçirirse, sistemde kalıcılık sağlar. Testler sırasında refresh token'ların veritabanında "rotate" (her kullanımda yenilenme) edilip edilmediği kontrol edilmelidir.

Örnek Senaryo: İmza Doğrulama Bypass

Aşağıdaki senaryo, sunucunun alg parametresini kontrol etmediği durumlarda gerçekleşen tipik bir "Algorithm Confusion" örneğidir:

// Orijinal Token (RS256 - Asimetrik)
Header: {"alg": "RS256", "typ": "JWT"}

// Saldırganın Manipülasyonu
Header: {"alg": "HS256", "typ": "JWT"}
// Saldırgan, public key'i secret key olarak kullanarak HS256 ile imzalar.

Sunucu, RS256 beklerken gelen HS256 algoritmasını, public key'i "secret" anahtarı olarak kullanarak doğrulamaya çalışırsa bypass gerçekleşir.

Geliştiriciler İçin Güvenlik Kontrol Listesi

Uygulama güvenliğini artırmak için geliştirme aşamasında şu adımlar izlenmelidir:

• Algoritma Kısıtlaması: Uygulamanız sadece beklenen algoritmaları (örneğin sadece RS256) kabul etmeli; none veya beklenmedik algoritmalar reddedilmelidir.
• Anahtar Yönetimi: Gizli anahtarlar (secret keys) asla kod içinde saklanmamalı, güçlü bir Key Management Service (KMS) kullanılmalıdır.
• Süre Sınırı: Access token ömürleri mümkün olduğunca kısa (5-15 dakika) tutulmalıdır.
• Kapsamlı Doğrulama: Sadece imza değil; exp (expiration), nbf (not before), iss ve aud alanları da mutlaka doğrulanmalıdır.

Bu rehberdeki yöntemler, siber güvenlik profesyonelleri tarafından yetkilendirilmiş ortamlarda (pentest) kullanılmak üzere hazırlanmıştır. İzinsiz yapılan denemeler yasal sorumluluk doğurabilir. Güvenlik testlerinde her zaman etik kurallara bağlı kalınmalı ve bulgular ilgili kurumun güvenlik politikalarına uygun şekilde raporlanmalıdır.