JWT Güvenlik Zafiyetleri: Tespit ve Çözümler

JWT'nin Anatomisi ve Güven Temeli: Hızlı Bir Hatırlatma

JWT'nin header.payload.signature yapısını ve temel çalışma prensibini zaten biliyorsunuz. Ancak analizimize başlamadan önce, güven modelini tazelemek kritik öneme sahiptir. Header ve payload kısımlarının sadece Base64Url ile kodlandığını, yani şifrelenmediğini ve herkes tarafından okunabildiğini unutmayın. Token'ın bütünlüğü (integrity) ve kimden geldiği (authenticity), yalnızca ve yalnızca signature (imza) kısmı ile güvence altına alınır.

Bu temel konsepti ve JWT'nin mikroservis mimarilerinde neden bu kadar popüler olduğunu hatırlamak için aşağıdaki kısa videoyu izleyebilirsiniz.

Artık temelleri hatırladığımıza göre, bu güven modelinin nasıl kırılabileceğini inceleyelim.

1. Algoritma Karışıklığı (Algorithm Confusion): Güvenin Manipülasyonu

Bu, JWT implementasyonlarındaki en klasik ve en tehlikeli mantık zafiyetlerinden biridir. Saldırgan, sunucunun imza doğrulama mantığını, beklediği algoritmayı değiştirerek manipüle eder. İki ana türü vardır.

a) alg: "none" Saldırısı: İmzanın Yok Sayılması

En basit algoritma karışıklığı saldırısı, başlıkta (header) bulunan alg parametresini "none" olarak değiştirmek ve imza bölümünü tamamen kaldırmaktır.

Eğer sunucu tarafındaki JWT kütüphanesi veya kod, imzasız token'ları kabul edecek şekilde hatalı yapılandırılmışsa, saldırganın sahte token'ı geçerli kabul edilir. Bu, genellikle eski kütüphanelerde veya verify fonksiyonunun yanlış kullanımında ortaya çıkar.

Utku Şen'in videosunda bu saldırının nasıl gerçekleştirildiğine dair pratik bir gösterim bulunmaktadır.

Kod Analizinde Tespiti: JWT doğrulama kodunu incelerken, verify fonksiyonunun her zaman belirli bir algoritma listesini zorunlu kılıp kılmadığını kontrol edin. Algoritma belirtilmemişse veya alg başlığından gelen değere körü körüne güveniyorsa, kod zafiyetlidir.

b) RS256 → HS256 Saldırısı: Asimetrik Güvenin Kırılması

Bu, daha incelikli ve tehlikeli bir saldırı türüdür. Sizin gibi deneyimli bir analistin özellikle dikkat etmesi gereken bir desendir.

Saldırının mantığı şu adımlara dayanır:

1. Normal Durum: Sunucu, asimetrik RS256 algoritmasıyla imzalanmış token'lar bekler. Token'ı doğrulamak için bir public key kullanır. Bu public key genellikle herkes tarafından erişilebilir.
2. Saldırganın Hamlesi: Saldırgan, geçerli bir token'ın kopyasını alır veya yeni bir token oluşturur.
   • Payload'ı istediği gibi değiştirir (örn. "role": "user" yerine "role": "admin" yazar).
   • Header'daki alg parametresini "RS256" yerine "HS256" olarak değiştirir.
3. Kritik Adım: Saldırgan, bu modifiye edilmiş token'ı, simetrik HS256 algoritmasını kullanarak imzalar. Anahtar olarak ne kullanır? Sunucunun public key'ini!
4. Zafiyetin Tetiklenmesi: Sunucu, saldırganın token'ını alır. verify fonksiyonu header'a bakar ve alg'nin "HS256" olduğunu görür. Simetrik bir doğrulama yapması gerektiğini düşünür ve bir "secret key" arar. Eğer kod hatalıysa, RS256 doğrulaması için kullanacağı public key'i alıp, HS256 doğrulaması için "secret key" olarak kullanır.
5. Sonuç: Saldırgan token'ı public key ile imzaladığı ve sunucu da aynı public key ile doğruladığı için, imza geçerli kabul edilir ve sahte token sisteme kabul edilir.

Kod Analizinde Tespiti ve Savunma: Bu zafiyetin tek ve kesin çözümü, verify fonksiyonunu çağırırken kabul edilecek algoritmaları açıkça beyaz listeye almaktır (whitelisting).

// YANLIŞ: Algoritmayı token'dan alıyor, zafiyetli.
jwt.verify(token, publicKey); 

// DOĞRU: Sadece RS256 algoritmasını kabul etmeye zorluyor.
jwt.verify(token, publicKey, {
  algorithms: ['RS256'] 
});

Kod review sırasında, verify fonksiyonuna bu algorithms parametresinin her zaman ve istisnasız bir şekilde verildiğinden emin olmalısınız.

2. Eksik Claim Doğrulaması: İçeriğe Kör Güven

Geçerli bir imza, token'ın değiştirilmediğini ve doğru kaynaktan geldiğini kanıtlar. Ancak token'ın içeriğinin (claims) sizin uygulamanız için kabul edilebilir olduğunu kanıtlamaz. Bu kontrollerin ayrıca yapılması gerekir.

Kod analizi sırasında şu claim'lerin doğrulanıp doğrulanmadığını mutlaka kontrol edin:

• exp (Expiration Time): Token'ın son kullanma tarihi. Bu kontrol edilmezse, çalınan bir token süresiz olarak kullanılabilir.
• iss (Issuer): Token'ı kimin yayınladığı. Mikroservis ortamında, auth-service tarafından yayınlanan bir token'ın, yanlışlıkla billing-service tarafından da kabul edilmesini önler.
• aud (Audience): Token'ın kimin için yayınlandığı. iss ile benzer şekilde, token'ın hedeflenen alıcı tarafından kullanıldığını garantiler.
• Diğer standartlar (nbf, jti): "Not Before" ve "JWT ID" gibi diğer standart claim'lerin de uygulamanın gereksinimlerine göre kontrol edilmesi gerekebilir.

Birçok JWT kütüphanesi, bu kontrolleri verify fonksiyonu içinde opsiyonel parametreler olarak sunar. Geliştiricinin bu opsiyonları kullanmayı unutması, ciddi bir mantık hatasıdır.

3. Anahtar Yönetimi Sorunları: Zayıf Sırlar ve Ele Geçirilen Anahtarlar

Bir JWT sisteminin güvenliği, temelindeki kriptografik anahtarların yönetimi kadar güçlüdür.

a) Zayıf HS256 Sırları ve Brute-Force

HS256 gibi simetrik algoritmalar kullanıldığında, tüm güvenlik tek bir paylaşılan sırra (shared secret) dayanır. Eğer bu sır "password", "secret" gibi zayıf veya tahmin edilebilir bir değerse, bir saldırgan offline olarak kaba kuvvet (brute-force) saldırısı düzenleyerek sırrı ele geçirebilir.

Video kaynağımız, hashcat kullanarak bu saldırının nasıl yapıldığını canlı olarak gösteriyor.

Kod Analizinde Tespiti: Kodda veya konfigürasyon dosyalarında HS256 için kullanılan anahtarları arayın. Bu anahtarlar, yüksek entropiye sahip, rastgele oluşturulmuş dizeler olmalıdır ve asla kodun içine gömülmemelidir. Güvenli bir secret management sisteminden (örn. HashiCorp Vault, AWS Secrets Manager) çekilmelidirler.

b) Saldırgan Kontrolündeki Anahtarlar (jku ve jwk)

Bu, anahtar yönetimiyle ilgili en sinsi saldırılardan biridir. JWT spesifikasyonu, jku (JWK Set URL) ve jwk (JSON Web Key) adında iki opsiyonel header parametresi tanımlar. Bunlar, token'ı doğrulayacak olan sunucuya, imzayı kontrol etmek için kullanması gereken public key'i nereden alacağını söyler.

Saldırı Akışı:

1. Saldırgan, kendi kontrolündeki bir sunucuda bir JSON dosyası yayınlar (https://attacker.com/my_public_key.json). Bu dosya, saldırganın kendi public key'ini içerir.
2. Saldırgan, {"role": "admin"} gibi sahte bir payload ile yeni bir JWT oluşturur.
3. Header'a jku parametresini ekler ve değer olarak kendi URL'sini (https://attacker.com/my_public_key.json) verir.
4. Bu token'ı kendi private key'i ile imzalar.
5. Token'ı sunucuya gönderir.
6. Eğer sunucu, jku başlığına körü körüne güveniyorsa, public key'i saldırganın sunucusundan indirir ve bu key'i kullanarak imzayı doğrular. İmza, saldırganın kendi private key'i ile oluşturulduğu için doğrulama başarılı olur.

Kod Analizinde Tespiti: Public key'in veya JWKS (JSON Web Key Set) endpoint'inin kaynağını arayın. Bu değer, her zaman uygulamanın güvenilir konfigürasyonundan gelmelidir. Token'ın header'ından dinamik olarak okunuyorsa, bu kritik bir zafiyettir.

Sonuç ve Kod Analizi Kontrol Listesi

Bu derste, JWT güvenliğinin sadece imzanın varlığından ibaret olmadığını, aksine doğrulama mantığının ve anahtar yönetiminin her detayında yattığını gördük. Bir kod analizi sırasında JWT doğrulama mantığını incelerken şu kontrol listesini kullanabilirsiniz:

1. Algoritma Zorlaması: verify fonksiyonu, kabul edilebilir algoritmaların bir beyaz listesini (['RS256'] gibi) zorunlu kılıyor mu? Bu, none ve RS256->HS256 saldırılarını engeller.
2. Claim Doğrulaması: exp, iss, aud gibi kritik talepler, uygulamanın iş mantığına göre doğrulanıyor mu?
3. Anahtar Kaynağı (RS256): Public key'ler veya JWKS URL'leri güvenilir bir konfigürasyon kaynağından mı geliyor, yoksa token'ın jku/jwk başlıklarından mı okunuyor?
4. Anahtar Gücü (HS256): Simetrik sırlar yeterli entropiye sahip mi ve güvenli bir şekilde yönetiliyor mu? Kod içinde gömülü veya zayıf sırlar var mı?
5. Oturum Sonlandırma: "Logout" işlevi nasıl ele alınıyor? Token'ların süresi dolmadan önce geçersiz kılınması için bir mekanizma (örn. denylist, token versiyonlama) var mı? Eğer yoksa, bu bir bulgu olabilir.

Bu derste token'ların kendi içindeki zafiyetlere odaklandık. Bir sonraki derste ise bu token'ların sıkça kullanıldığı kimlik doğrulama protokollerine geçeceğiz. "OAuth 2.0 ve OIDC implementasyonlarında state parametresi kötüye kullanımı ve redirect URI doğrulama açıkları" gibi, akışın kendisindeki mantık hatalarını nasıl tespit edeceğimizi analiz edeceğiz.