Son altı ayda üç farklı müşteride birbirine benzeyen bir kimlik doğrulama zaafı raporladık. Üçünde de JWT kütüphanesi güncel sürümdeydi, üçünde de sorun kütüphanede değil, ona verilen doğrulama seçeneklerindeydi. Bu yazıda zaafın kaynağını, üretimde neye benzediğini ve kalıcı çözümü savunma tarafından anlatıyoruz.
Kısa özet
JSON Web Token (JWT), sunucunun ürettiği ve imzaladığı bir oturum bileti gibidir. Sunucu her istekte imzayı doğrular ve biletin içindeki kullanıcı kimliğine güvenir. Bu modelin tek dayanağı imza doğrulamasının her koşulda ve doğru anahtarla yapılmasıdır. Doğrulama zayıfladığında, biletin içeriğine güvenilemez hale gelir.
En sık karşılaştığımız üç yapılandırma hatası şunlar oldu.
1. Algoritmanın token'dan okunması
Doğrulama yapan kod, hangi algoritmayı kullanacağına token'ın kendi başlığına bakarak karar veriyordu. Güvenli yaklaşım bunun tersidir: sunucu beklediği algoritmayı kendi sabitler, token ne söylerse söylesin onu uygular.
Kural: doğrulama fonksiyonuna kabul edilen algoritmaları açıkça bir liste olarak verin. Token'ın önerdiği algoritmaya asla güvenmeyin.
2. Simetrik ve asimetrik anahtarın karışması
Bazı uygulamalarda doğrulama, asimetrik bir açık anahtarla yapılıyordu ama kod simetrik doğrulamaya da izin verecek şekilde gevşek bırakılmıştı. Açık anahtar zaten herkese açıktır; simetrik doğrulamaya izin verildiğinde bu açık değer, imza sırrı yerine geçebilecek bir konuma düşer.
Çözüm nettir: bir uç yalnızca tek bir aileyi kabul etsin. RS/ES ailesi kullanıyorsanız HS ailesini doğrulama katmanında tümüyle reddedin.
3. Süre ve iptal kontrolünün eksikliği
İmza doğru olsa bile, süresi geçmiş ya da çıkışta iptal edilmiş bir biletin kabul edilmesi ayrı bir sorundur. exp alanının kontrol edilmediği, çıkış yapıldığında token'ın sunucu tarafında geçersiz sayılmadığı durumlar gördük.
Nasıl kapattık?
Her üç müşteride de düzeltme küçük ama belirleyiciydi:
- Doğrulama çağrısına kabul edilen algoritmalar açık liste olarak verildi.
- Beklenen dışındaki her algoritma ailesi reddedildi.
exp,issveaudalanları zorunlu doğrulama kapsamına alındı.- Kritik yetki değişimlerinde token yeniden üretildi ve eskisi sunucu tarafında geçersiz sayıldı.
Kendi ekibiniz için kontrol listesi
- Doğrulama fonksiyonuna algoritma listesini siz mi veriyorsunuz, yoksa token mı belirliyor?
- Açık anahtarla imzalıyorsanız, doğrulama katmanı simetrik aileyi kesin olarak reddediyor mu?
- Süre, veren ve hedef alanları her istekte kontrol ediliyor mu?
- Çıkış ve şifre değişiminde eski oturum biletleri gerçekten geçersiz oluyor mu?
Bu dört sorunun tamamına "evet" diyemiyorsanız, kimlik doğrulama katmanınız hedefli bir incelemeyi hak ediyor. Biz de sızma testlerinde tam olarak bu zinciri gözden geçiriyoruz.