İçeriğe geç

JWT'yi doğru kullanmak: sık görülen güvenlik hataları

JWT'nin şifreli değil yalnızca imzalı olduğu, imzanın her istekte doğrulanması, alg ve süre alanları, depolama yeri ve iptal sorunu: API tasarlarken kaçınılacak sekiz hata.

2 dk okumaJWT · Güvenlik · API · Kimlik doğrulama

JWT (JSON Web Token), kimlik ve yetki bilgisini API'ler arasında taşımanın yaygın yoludur. Basit görünür: üç parça, noktalarla ayrılmış. Hataların çoğu bu görünür basitlikten gelir. Aşağıdaki liste, belirteçleri üreten ve doğrulayan her ekibin gözden geçirmesi gereken noktaları toplar; ayrıntılı öneriler için JWT güvenlik en iyi uygulamalarını anlatan RFC 8725'e bakın.

1. JWT şifreli değildir

İmzalı bir JWT'nin başlığı ve yükü yalnızca base64url kodludur; herkes okuyabilir. Parola, kimlik numarası ya da gizli iş verisi yüke konmamalıdır. Gizlilik gerekiyorsa şifreli biçim (JWE) ya da belirteçte yalnızca bir başvuru numarası taşıyıp veriyi sunucuda tutmak gerekir.

2. Çözmek doğrulamak değildir

Yükü çözüp "kullanıcı: ayşe, rol: yönetici" okumak, belirtecin gerçek olduğunu göstermez. Güven, ancak imza anahtarla doğrulandıktan sonra doğar. Sunucuda yalnızca çözüp alanlara güvenen kod, herkesin kendi belirtecini yazmasına izin verir.

3. "alg": "none" ve algoritma karışıklığı

Başlıktaki alg alanı belirtecin kendisinden gelir; saldırgan onu değiştirebilir. Doğrulayıcı, hangi algoritmayı kabul edeceğini kendi yapılandırmasından almalıdır, başlıktan değil. "none" hiçbir koşulda kabul edilmemeli; genel anahtarla imzalanan (RS) belirtecin, aynı anahtar gizli parola gibi kullanılarak HS ile "doğrulanmasına" izin verilmemelidir.

4. Süre ve hedef alanlarını denetlememek

  • exp (bitiş) alanı denetlenmezse belirteç sonsuza dek geçerli kalır.
  • iss (veren) ve aud (hedef kitle) denetlenmezse bir başka hizmet için üretilmiş belirteç sizin API'nizde de geçer.
  • nbf (başlangıç) ve saat sapması: sunucular arasında birkaç dakikalık hoşgörü yeterlidir, saatlerce değil.

5. Uzun ömürlü erişim belirteci

Erişim belirteci kısa ömürlü olmalı (dakikalar düzeyi), oturumu uzatmak için ayrı bir yenileme belirteci kullanılmalıdır. Çalınan uzun ömürlü belirteç, çalındığı fark edilene kadar tam yetkiyle kullanılabilir.

6. Depolama yeri

Tarayıcıda localStorage içindeki belirteç, sayfaya sızan her betiğin (XSS) eline geçer. Çerez, HttpOnly ve Secure bayraklarıyla ve uygun SameSite ayarıyla tutulduğunda betikler tarafından okunamaz; ancak çerez kullanıyorsanız CSRF'yi de ayrıca düşünmelisiniz. Hiçbir seçenek tek başına yeterli değildir.

7. İptal edememek

JWT kendi kendine yeten bir belirteçtir; sunucu bitiş süresinden önce iptal etmek için ek bir mekanizmaya ihtiyaç duyar (kara liste, oturum sürümü, kısa ömür). Çıkış yapan ya da yetkisi alınan kullanıcının belirteci, süresi dolana kadar geçerli kalabilir; bunu tasarımda kabul edin ya da kapatın.

8. Zayıf HMAC anahtarı

HS256 gibi paylaşılan anahtarlı algoritmalarda tahmin edilebilir ya da kısa bir anahtar çevrimdışı olarak denenerek kırılabilir. Anahtar rastgele üretilmiş, yeterince uzun ve koddan ayrı saklanmalıdır.

Aracı nasıl kullanmalı?

Bir belirteci JWT çözümleyici ile tarayıcınızda açıp başlığı, yükü, zaman alanlarını ve zayıf ayarları görebilirsiniz; belirteç hiçbir yere gönderilmez. Araç çözer, doğrulamaz: gerçek doğrulama sunucunuzda anahtarla yapılmalıdır. İmza mantığını denemek için webhook HMAC imza doğrulama, anahtar için parola gücü ve entropi hesaplayıcı işinize yarar. API güvenliğini gözden geçirmek için bize yazın.

Bu konuyu kendi tesisiniz için konuşalım