· kaynak dev.to (home feed)
Doğrulanmayan JWT kid parametresi SQL injection ve path traversal saldırılarına kapı arıyor
Bir dev.to yazısı, imza doğrulamasından önce işlenen JWT kid başlığının, saldırganlara doğrulama anahtarının kontrolünü veren SQL injection ve path traversal payload'ları taşıyabileceğini belgeliyor.

dev.to'da yayımlanan bir yazı, hiçbir kriptografik kırılma gerektirmeyen bir JWT zafiyet sınıfını ele alıyor: token'ın kid başlık parametresi sanitizasyondan geçmeden veritabanı sorgularına veya dosya sistemi okumalarına ulaştığında, saldırganlar anahtar seçimini kendi kontrolündeki değerlere yönlendirip doğrulamadan geçen sahte token'lar üretebiliyor.
Spesifikasyonun hiç korumadığı bir arama ipucu
Yazıya göre RFC 7517 Bölüm 4.5, kid'yi yapısı tamamen geliştiriciye bırakılmış, büyük/küçük harfe duyarlı bir dizi (string) olarak tanımlıyor — zorunlu bir format, karakter allowlist'i ya da bir zorlama mekanizması yok. Kritik olan zamanlama. JWT başlıkları Base64url ile çözülüp yorumlanır ve imza doğrulaması çalışmadan önce işlenir; yani sunucu, token'a güvenmek için hiçbir nedeni yokken kid değerine göre hareket eder. Bu değer ham girdi olarak bir anahtar aramasına ulaşırsa saldırgan anahtarı kırmak yerine onu değiştirir ve çoğu HMAC kütüphanesi aramanın döndürdüğü herhangi bir diziyle doğrulama yapar.
Anahtar aramasında SQL injection
Zafiyetli örüntü, concatenation ile oluşturulmuş bir sorgudur: sunucu, kid'nin ham başlık dizesine eşit olduğu bir tablodan doğrulama anahtarını seçer. Saldırgan, veritabanının kendi seçtiği bir literal dizeyi döndürmesini sağlayan bir UNION payload'ı enjekte eder; sunucu bu dizeyi HMAC anahtarı olarak kullanır. Anahtarı saldırgan seçtiği için, sahte bir payload'ı bu anahtarla yeniden imzalayabilir ve kontrol başarıyla geçer — imza matematiksel olarak doğrudur ve hem anahtar hem imza saldırgandan gelir. Daha basit bir OR tabanlı payload, anahtarlar tablosunun ilk satırını döndürür; yazı, bunun ORDER BY ile öngörülebilir hale getirilebileceğini belirtiyor. Yazar, bu zafiyet sınıfına ilişkin Invicti'nin değerlendirmesine atıf yapıyor: CWE-89 ve CWE-287'yi birleştiren, ağ üzerinden ve ön kimlik doğrulaması olmadan istismar edilebilen CVSS 3.1 7.5 High.
Sıfır baytlık anahtara giden path traversal
Dosya sistemi varyantında kid, herhangi bir basename temizliği veya allowlist olmadan bir anahtar dosya yoluna birleştirilir. Saldırgan bunu /dev/null'a — her zaman boş okunan Linux pseudo-device'ına — yönlendirir, böylece sunucu sıfır baytlık bir HMAC anahtarı türetir. Saldırgan daha sonra token'ını tek bir null bayttan oluşan, Base64url ile AA== olarak kodlanan bir anahtarla imzalar ve iki taraf farklı yollardan aynı anahtara ulaşır: hiçbir şey. Yazı, tüm zinciri belgeleyen bir PortSwigger lab'ına işaret ediyor — kid içinde bir traversal payload'ı, sub claim'inin administrator olarak değiştirilmesi, null baytlık bir imzalama anahtarı — ve sonuç yönetici erişimi. Bu varyant da CWE-287 kapsamında 7.5 High olarak derecelendirilmiştir.
jku zincirinin giriş noktası olarak kid
Parametre, sunucuya anahtar setini bir URL'den indirmesini söyleyen jku başlığıyla birlikte de kullanılabilir. Bu URL'de bir domain allowlist'i yoksa saldırgan kendi JWKS endpoint'ini barındırır, jku'yu ona ayarlar, kid'yi o setteki bir anahtara ayarlar ve ilgili private key ile imzalar. dev.to, node-jose'un 0.11.0 öncesini 8.1 CVSS ile etkileyen CVE-2018-0114'e bir paralellik çizer: kütüphane, token başlığının içine gömülü bir JWK'ye güveniyordu. Yapısal hata aynıdır — anahtar seçiminin saldırgan kontrolündeki girdiye devredilmesi.
WAF'lar neden kaçırıyor
Yazıya göre çoğu web application firewall varsayılan olarak JWT başlıklarını incelemez ve kid Base64url ile kodlanmış olarak geldiğinden, ../, %2F veya UNION gibi örüntülerin eşleşebilmesi için tespit kurallarının önce başlığı çözmesi gerekir. Yazar, kid değerlerini çıkarıp kontrol eden MAGO Intel adlı bir keşif aracından söz eder ve HS256 kurulumlarının RS256'dan daha açık olduğunu belirtir — ancak taramanın kod içindeki doğrulamanın yerine geçmediğini, onu tamamladığını vurgular.
Boşluğu kapatan üç kontrol
Yazı üç düzeltme öneriyor:
- Parametreli sorgular, böylece kid SQL metnine eklenmek yerine veri olarak bağlanır.
- Path normalizasyonu artı bir allowlist: bir basename'e indirin, eğik çizgi veya nokta-nokta dizileri içeren değerleri reddedin ve bilinen bir anahtar kimliği kümesine karşı doğrulayın — UUID formatı ya da ^[a-zA-Z0-9_-]{1,64}$ gibi muhafazakâr bir örüntü. Uyuşmazlıkta reddedin ve asla varsayılan bir anahtara geri düşmeyin; o da başlı başına bir saldırı yüzeyidir.
- Algoritma sabitleme: anahtar aramasından önce alg başlığını kontrol edin. RS256 ve ES256, saldırganın bir public key ile asimetrik imza sahteleyememesi nedeniyle boş-HMAC varyantına bağışıktır. AWS KMS veya HashiCorp Vault gibi yönetilen anahtar depoları ham SQL ve dosya yollarını tamamen ortadan kaldırır ve kid'yi bir anahtar alias'ına eşler.
Neden önemli
Bu saldırılar kriptografiyi yenmek yerine onu devre dışı bırakır: imza kontrolü geçer, veritabanı veya dosya sistemi normal davranır ve uygulamaya anomalmiş gibi görünmez. kid alanı sayısız üretim JWT akışının standart bir parçasıdır ve spesifikasyon onun nasıl işleneceğini açıkça geliştiricilere bırakmıştır — üstelik yazıya göre çoğu kütüphane hiçbir şeyi doğrulamamakta ve çoğu WAF varsayılan olarak hiçbir şeyi incelememektedir. Riskleri azaltan önlemler sıradan bir mühendislik hijyenidir — parametreli sorgular, allowlist'ler, sabitlenmiş algoritmalar — bu da onu düşük maliyetli ama yüksek getirili bir düzeltme ve anahtarları dinamik olarak çözen her JWT doğrulama yolunda denetlenmeye değer bir örüntü haline getirir.
- #jwt
- #security
- #sql-injection
- #path-traversal
- #authentication
İlgili yazılar
- Kötü niyetli SDK paketleri testleri ve import kontrollerini geçerken kimlik bilgilerini çalıyor
- Önde Gelen Framework'ler Origin Kontrollerini Varsayılan Olarak Atlayınca Cross-Site WebSocket Hijacking Varlığını Sürüdürüyor
- OpenAI ajanları harici wikiye ~18.000 gönderi yazarak gizli mesaj panosu oluşturdu, olay açıklanmadı