JWT imzalama anahtarları: oluşturma ve rotasyon nasıl işler ve alg başlığına neden güvenilmez

Bir dev.to yazısı, JSON Web Token (JWT) güvenliğinin ardındaki mekanikleri inceliyor: imzalama anahtarları nasıl oluşturulur ve yayınlanır, canlı oturumları geçersiz kılmadan nasıl döndürülmeli ve bir token'ın başlığındaki algorithm alanının doğrulayıcıların asla yüzeyde kabul etmemesi gereken bir şey olmasının nedeni.

Bir token'ı gerçekten doğrulayan nedir

Yazı bir benzetmeyle açılıyor: mağazanızın düzenlediğine tıpatıp benzeyen ama sahte olan bir kupon. JWT'nin de aynı zayıflığı var. Bir token'ın özgünlüğü içeriğine değil, imzasını kimin üretebildiğine dayanır.

Bir JWT üç parçadan oluşur — header, payload ve signature. İmza, header ve payload birlikte hesaplandığından, ikisinden birindeki tek bir baytı değiştirmek bile eşleşmeyi bozar. Ancak bu bütünlük kontrolü ancak doğrulama, yalnızca yayıncının kontrolündeki bir anahtara bağlandığında anlam taşır.

Tek anahtar imzalar, herkes doğrular

JWT imzalama asimetrik anahtar çiftleri kullanır. Private key token'ları imzalar ve yayıncının elinden asla çıkmaz; yalnızca tek bir kopyası vardır. Public key ise herkesin imzaları kontrol edebilmesi için yayınlanır. Asimetri meselelerin özüdür: bir public key imzayı doğrulayabilir ama sahte imza üretmez.

Yayın, genellikle /.well-known/jwks konumunda bulunan bir JSON Web Key Set (JWKS) endpoint'i üzerinden yapılır. Kümedeki her anahtar bir kid (key ID) taşır ve yayınlanan her token, onu imzalayan kid'i belirtir. Bu eşleştirme, birden fazla anahtar dolaşımda olduğunda doğrulayıcının doğru public key'i seçmesini sağlar.

Rotasyon bir çakışma penceresi gerektirir

Baştan savma yapılırsa anahtar rotasyonu her şeyi aynı anda bozar. Yazının önerisi, önce yeni public key'i yayınlamak ve eski anahtarla imzalanmış tüm token'lar过期 edene kadar eski anahtarı yanında listelemeye devam etmek. Eski anahtarı erkenden çekerseniz, hâlâ geçerli olan tüm token'lar aynı anda doğrulama hatası verir — fiilen toplu bir oturum kapatma.

Geçişi işler hale getiren kid mekanizmasıdır: çakışma süresince JWKS her iki anahtarı da sunar ve her token hangisinin onu doğruladığını gösterir.

alg başlığı güvenilmeyen girdidir

Merkezî uyarı, JWT başlığındaki alg alanıyla ilgilidir. Yazı, doğrulayıcıların imzaları yalnızca açık bir algoritma izin listesinden kabul etmelerini — örneğin RS256 veya ES256 — ve asla token'ın kendisinin nasıl doğrulanacağını belirlemesine izin vermemelerini öneriyor.

Token'ın beyan ettiği algoritmaya güvenmek, iki klasik saldırının köküdür: token'ın hiç imza gerekmediğini iddia ettiği alg=none hilesi ve değiştirilen bir alg değerinin doğrulayıcıyı anahtar malzemesini hiç amaçlanmadığı bir şekilde kullanmaya ittiği algoritma karışıklığı. JWT Best Current Practices belgesi olan RFC 8725 bunu açıkça belirtir.

Sızdırılmış bir imzalama anahtarı bir maym anahtarıdır

Yazı ibret vakası olarak Storm-0558'e atıfta bulunuyor. 2023'te tek bir sisteme kapsamlandırılmış olması gereken bir imzalama anahtarı saldırganların eline geçti ve sahte token'lar üretmek için kullanıldı; makaleye göre, Microsoft'un 2023 açıklamasına ve 2024 CISA Cyber Safety Review Board raporuna atıfta bulunarak, bu saldırganlara 20'den fazla kuruluşta e-posta erişimi sağladı. Sızan tek bir private key, ona güvenen her şeyi tehlikeye atar.

Pratik kontrol listesi

Yazı önerilerini dört uygulamada özetliyor:

• Anahtarları çiftler halinde üretin (RSA-2048 veya eliptik eğri) ve private key'i imzalama servisinin içinde tutun.
• Anahtarları JWKS üzerinden her birinde bir kid ile yayınlayın ve kid'i her token'ın içine damgalayın.
• Çakışmayla döndürün: eski token'lar过期 edene kadar eski ve yeni public key'ler bir arada var olur.
• Algoritma beyaz listesini sabitleyin, "none"'ı reddedin ve asla bir token'ın kendi doğrulama yöntemini seçmesine izin vermeyin.

Neden önemli

JWT'ler modern web uygulamalarının büyük bir kısmının kimlik doğrulama yolunun altında yer alır ve hata modları sessizdir. Bozuk bir rotasyon herkesi aynı anda oturumdan çıkarır; güvenilen bir alg başlığı ya da sızan bir private key, saldırgana görünür bir kırılma olmadan hesap erişimi verebilir. Düzeltmeler ucuz — bir algoritma listesini sabitlemek az miktarda konfigürasyondur — ama ancak geliştiriciler yazının temel noktasını içselleştirdiğinde uygulanır: bir token'ın içindeki her şey, başlık dahil, imzası doğrulayıcının kendisinin seçtiği bir anahtar ve algoritmaya göre doğrulanana dek güvenilmeyen girdidir.