JWS'nin kodunu çözmek neden sadece giriş noktasıdır?
Modern kimlik mimarisinde -özellikle OAuth 2.0 ve OpenID Connect- imzalı tokenlar sıklıkla hizmetler arasında aktarılabilen "güvenilir konteynerler" olarak değerlendirilir. Ancak güvenlik mühendisleri, kırmızı ekip çalışanları ve yapay zeka güvenlik araştırmacıları için JWS, kriptografi ve iş mantığının kesiştiği noktada yer alan kompakt, saldırgan kontrollü bir girdi olarak daha iyi anlaşılmaktadır. Ham bir işlem gerçekleştirme yeteneği json web imzası kod çözme amaç değildir; doğrulayıcının ne yaptığı hakkında akıl yürütmenizi sağlayan enstrümantasyondur. düşünüyor doğruluyor, uygulamanın ne Aslında ve belirtecin hangi bölümlerinin güvenilmeyen veriler yerine yapılandırma olarak ele alındığını belirtir.
Bu ayrım önemlidir çünkü "token güvenliği" token formatının bir özelliği değildir. Bu bir özelliktir doğrulama ve talep doğrulama boru hattı-Algoritma seçimi, anahtar seçimi, düzenleyen/izleyici kontrolleri, zamana dayalı talepler ve kritik olarak, alt kodun talepleri aldıktan sonra nasıl kullandığı. Bir sistem, doğrulama tamamlanmadan (hatta çalışmadan) önce kodu çözülmüş talepleri "gerçek" olarak ele aldığı anda, token bir güvenlik sınırı olmaktan çıkar ve kullanıcı kontrollü bir parametre haline gelir.
Dizenin arkasındaki mühendislik: Dolgusuz Base64url
İnsanlar "bir JWS'nin kodunu çöz" dediklerinde, genellikle yaptıkları şey bir base64url kodlama adımını tersine çevirmektir. JWS Kompakt Serileştirmede, üç segmentin her biri URL-güvenli alfabe kullanılarak base64url ile kodlanır ve genellikle = dolgu. RFC 7515 kompakt formatı tanımlar ve açıkça BASE64URL(...) ile birleştirir, ardından başlık ve yük yapısı için . ayırıcılar. (RFC Editörü)
"Dolgu yok" kuralı, araç oluşturana veya yakalanan trafiği büyük ölçekte analiz edene kadar önemsiz görünmektedir. Birçok genel base64 rutini dolgunun mevcut olduğunu varsayar ve dolgu eksik olduğunda ya hata verir ya da belirsiz çıktılar üretir. Sağlam bir kod çözücü, dolguyu deterministik olarak yeniden eklemeli ve base64url farkındalığına sahip bir kod çözme rutini kullanmalıdır, aksi takdirde analiziniz tekrarlanamaz hale gelir - özellikle de bulanıklaştırma sırasında hatalı biçimlendirilmiş veya kasıtlı olarak bozulmuş belirteçlerle uğraşırken.
JWS vs JWT: her bir noktanın gerçekte ne anlama geldiği
Bir JWS Compact belirteci her zaman:
BASE64URL(başlık) . BASE64URL(yük) . BASE64URL(imza)
Bu üçüncü bölüm "hex" değildir. İmza (veya MAC) baytlarının base64url'üdür. Doğrulama veya kriptografik önceliklendirme yapmadığınız sürece bunu opak olarak değerlendirin.
JWT (RFC 7519), genellikle JWS yükünün içinde taşınan bir talep kümesi konvansiyonudur, bu nedenle insanlar "JWT" ile "JWS "yi gelişigüzel karıştırırlar. RFC 7519 aşağıdaki gibi kayıtlı talepleri tanımlar iss, alt, aud, expve nbfve bu taleplerin bir JSON nesnesi olarak nasıl temsil edildiğini açıklar. (IETF Datatracker)
Pratikte bu, yalnızca kod çözme adımının size belirtecin ne olduğunu söyleyebileceği anlamına gelir iddialarancak bu iddiaların doğru olup olmadığını size söyleyemez. gerçek. Hakikat ancak imza doğrulama ve talep onaylama başarılı olduktan sonra ortaya çıkar.
Başlık, saldırı yüzeyidir: alg, Çocuk, jku güvenilmeyen girdiler olarak
İyi tasarlanmış sistemlerde token başlığı, doğrulayıcının bilinen iyi bir doğrulama stratejisi seçmesine yardımcı olan meta verilerdir. Kötü tasarlanmış sistemlerde başlık, saldırgan tarafından kontrol edilen bir yapılandırma kanalı haline gelir. Bu nedenle, bir json web imzası kod çözmebirçok profesyonel önce başlığa odaklanır.
Bu alg değeri özellikle hassastır çünkü hangi doğrulama yönteminin çağrılacağını etkileyebilir. Algoritma karışıklığı (anahtar karışıklığı olarak da adlandırılır), bir saldırganın sunucuyu geliştiricinin amaçladığından farklı bir algoritma kullanarak bir JWT'yi doğrulamaya zorlayabildiği ve sunucunun imzalama anahtarını bilmeden potansiyel olarak sahte belirteçleri etkinleştirebildiği durumlarda ortaya çıkar. PortSwigger'ın Web Güvenlik Akademisi bu sınıfı net bir şekilde açıklamakta ve algoritma seçimlerinin yanlış yapılandırılması veya hatalı kullanımına bağlamaktadır. (PortSwigger)
Bu Çocuk parametresi kriptografi değildir; anahtar alma işlemidir. Eğer Çocuk dosya yollarını, veritabanı sorgularını, önbellek anahtarlarını veya katı izin listesi olmayan dinamik çözümleyicileri etkilediğinde, anahtar yönetimi sınırı içinde genel bir enjeksiyon yüzeyi haline gelir.
Bu jku parametresi kötüye kullanıldığında daha da tehlikelidir. Bir sunucu JWKS'yi token başlığı tarafından belirtilen bir URL'den (veya yeterince kısıtlanmamış bir varyanttan) alırsa, saldırgan doğrulayıcıyı saldırganın kontrolündeki anahtarlara yönlendirerek güven çapasını değiştirmeye çalışabilir. Bir sistem "yalnızca HTTPS'den getirse" bile, sıkı izin listeleri, veren bağlama, önbelleğe alma politikası ve denetim izlerinin olmaması, anahtar alımını bir kripto sorununa değil, bir tedarik zinciri sorununa dönüştürür.
Python'da üretim sınıfı bir çevrimdışı kod çözücü (yalnızca kod çözme, dolgu güvenli)
Web tabanlı token hata ayıklayıcıları kullanışlıdır, ancak profesyonel güvenlik çalışmalarında genellikle kötü bir fikirdir. Belirteçler hassas tanımlayıcılar, e-postalar, dahili kiracı kimlikleri ve hatta gömülü PII içerebilir. Çevrimdışı, komut dosyası yazılabilir, deterministik ve hatalı biçimlendirilmiş girdilere karşı güvenli araçlar istersiniz. Aşağıdaki uygulama kasıtlı olarak hiçbir şeyi "doğrulamaz"; yalnızca mevcut olanı deşifre eder ve hata modlarını gözlemlenebilir hale getirir.
base64 içe aktar
import json
from typing import Any, Dict, Tuple, Optional
def _b64url_decode(data: str) -> bytes:
# RFC 7515 base64url genellikle "=" dolgusunu atlar; deterministik olarak geri yükleyin.
pad = (-len(data)) % 4
return base64.urlsafe_b64decode((data + "=" * pad).encode("ascii"))
def _parse_json(b: bytes) -> Tuple[Optional[Dict[str, Any]], Optional[str]]:
try:
return json.loads(b.decode("utf-8")), None
except Exception as e:
return None, f"{type(e).__name__}: {e}"
def jws_decode(token: str) -> Dict[str, Any]:
parts = token.split(".")
if len(parts) != 3:
return {"hata": "Geçersiz JWS kompakt formatı (3 parça bekleniyor).", "parts": len(parts)}
header_b = _b64url_decode(parts[0])
payload_b = _b64url_decode(parts[1])
header, he = _parse_json(header_b)
payload, pe = _parse_json(payload_b)
out: Dict[str, Any] = {
"header_raw": header_b.decode("utf-8", errors="replace"),
"payload_raw": payload_b.decode("utf-8", errors="replace"),
"signature_b64url_sample": parts[2][:16] + "..."
}
eğer header None değilse:
out["header"] = header
else:
out["header_error"] = he
eğer payload None değilse:
out["payload"] = payload
else:
out["payload_error"] = pe
geri dön
Bu, RFC 7515'in base64url kullanımıyla (ve kompakt JWS'nin URL/HTTP başlık bağlamları için tasarlandığı gerçeğiyle) uyum sağlarken, belirteç hatalı biçimlendirildiğinde, kesildiğinde veya kasıtlı olarak bulanıklaştırıldığında size kararlı davranış sağlar (RFC Editörü)
Kritik boşluk: kod çözme ve doğrulama (ve gerçek hata modeli)
JWS/JWT ile ilgili en kalıcı güvenlik yanılgısı, kod çözme ile doğrulamayı birbirine karıştırmaktır. Kod çözme tersine çevrilebilir biçimlendirmedir; doğrulama ise kriptografik doğrulama artı politika uygulamasıdır.
Gerçek olaylarda, yaygın hata modeli gerçek bir yarıştan ziyade "doğrulamadan önce kullan" şeklindedir. Bir uygulama belirteci çözer, okur rol, kullanıcı_id, kiracıveya kapsamve imza doğrulama ve talep doğrulama kesin olarak uygulanmadan önce yetkilendirme kararları verir. JWT testine ilişkin OWASP kılavuzu, algoritma beklentilerinin ve doğrulama mantığının yanlış ele alınmasının, asimetrik ve simetrik doğrulama akışları arasındaki karışıklık da dahil olmak üzere yüksek etkili saldırılara nasıl olanak sağladığını vurgulamaktadır. (OWASP Vakfı)
İmza geçerli olsa bile, bir belirtecin yine de talep doğrulamasına ihtiyacı vardır. RFC 7519 şunları tanımlar aud olarak tanımlar ve belirteci işleyen müdürün kendisini amaçlanan hedef kitle olarak tanımlamaması durumunda belirtecin aşağıdaki durumlarda reddedilmesi gerektiğini belirtir aud mevcut. (IETF Datatracker) Bu, kriptografik geçerliliğin bağlamsal geçerliliğe eşdeğer olmadığını hatırlatır.
Gelişmiş istismar: "alg: none" ötesinde
"alg: none" anlatısı tarihsel olarak önemlidir, ancak çoğu modern kütüphane varsayılan olarak bunu engeller. Günümüzde daha ilginç hatalar iki grupta toplanıyor: kripto sağlayıcılarındaki uygulama kusurları ve esnek doğrulama işlem hatlarının neden olduğu karmaşık mantık atlamaları.
Psişik İmzalar (CVE-2022-21449): ECDSA doğrulaması yalan söylediğinde
"Psişik İmzalar" olarak popüler olan CVE-2022-21449, etkilenen Java sürümlerinde (özellikle Java 15'te tanıtılan ve Nisan 2022 CPU'da düzeltilen) ECDSA imza doğrulamasının belirli koşullar altında atlanabildiği ciddi bir Java kriptografi güvenlik açığıdır. Analizler, ECDSA imzalı JWT'ler veya WebAuthn mekanizmalarını içeren senaryolar da dahil olmak üzere ECDSA imzalarına dayanan sistemleri ne kadar önemli ölçüde zayıflattığını vurgulamaktadır. (Neil Madden)
Token güvenliği için en önemli ders, bypass'ın zekice olması değil; "ES256'yı seçtim" ifadesinin bir garanti olmadığı operasyonel gerçekliğidir. Çalışma zamanı sürümünüz, güvenlik sağlayıcısı uygulamanız ve yama durumunuz tehdit modelinizin bir parçasıdır. Güvenlik ekipleri, açık yama SLA'ları ve hatalı biçimlendirilmiş imzalara karşı doğrulama uygulayan regresyon testleri ile "kripto sağlayıcı regresyonlarını" birinci sınıf riskler olarak ele almalıdır.
Algoritma karmaşası / anahtar karmaşası: sunucu belirtecin kuralları seçmesine izin verdiğinde
Algoritma karışıklığı saldırıları, doğrulayıcı belirtecin doğrulama için hangi algoritmanın kullanılacağını etkilemesine izin verdiğinde ve anahtar işleme asimetrik ve simetrik modlar arasında temiz bir şekilde ayrılmadığında ortaya çıkar. PortSwigger, bu durum düzgün bir şekilde ele alınmazsa, saldırganların sunucunun gizli imzalama anahtarını bilmeden rastgele değerler içeren geçerli JWT'leri taklit edebileceğini belirtiyor. (PortSwigger)
Uygulamada, savunma kavramsal olarak basittir ancak sıklıkla gözden kaçırılır: kimlik doğrulama kararlarının verildiği sınırda "algoritma çevikliğine" asla izin vermeyin. Hizmetiniz RS256 bekliyorsa, RS256'yı zorlarsınız. "Başlıktaki alg ne olursa olsun kabul edin ve doğrulanıp doğrulanmadığına bakın" demezsiniz.
Başlık güdümlü anahtar alma: Çocuk/jku doğrulama tedarik zinciri olarak
Başlığın saldırgan girdisi olduğunu kabul ettiğinizde, anahtar seçiminin saldırı yüzeyinizin bir parçası olduğunu da kabul etmiş olursunuz. A Çocuk çalışma zamanında getirilen, yüklenen veya oluşturulan rastgele anahtar materyaliyle değil, önceden tanımlanmış bir anahtar izin listesiyle eşleşmelidir. A jku bir belirtecin güven çapalarının nereden geldiğini yeniden tanımlamasına asla izin vermemelidir. OIDC için JWKS getirmeyi destekliyorsanız, güvenilir bir veren yapılandırmasına bağlı olmalı ve izin listeleri, önbelleğe alma ve izleme ile güçlendirilmelidir.
Üretim sapmalarından kurtulan sertleştirme stratejileri
JWS doğrulamasına yönelik derinlemesine savunma yaklaşımı kağıt üzerinde sıkıcı görünebilir, ancak token hatalarının çoğunu önleyen şey tam olarak budur.
Kabul edilen algoritmaları açıkça belirtir ve doğrulayıcının beklenen algoritmanın kullanıldığını zorunlu kılmasını istersiniz. OWASP'ın Java için JWT kılavuzu bu noktayı doğrudan önleyici bir tedbir olarak ortaya koymaktadır. (OWASP Hile Sayfası Serisi)
Düzenleyen ve hedef kitleyi tutarlı bir şekilde doğrularsınız. RFC 7519'un kayıtlı talepler için tanımları akademik değildir; "geçerli imza, yanlış bağlam" yaygın bir hata sınıfı olduğu için vardırlar. Özellikle kitle uyuşmazlıkları, farklı bir hizmet için basılmış bir jetonu yanlışlıkla kabul etmenin en kolay yollarından biridir. (IETF Datatracker)
Anahtar kimliklerini bir arama sorgusu olarak değil, veri olarak ele alırsınız. A Çocuk bir dosya sistemi yolu veya güvenilmeyen girdiden oluşturulan bir veritabanı sorgusu değil, sınırlı bir eşleme-KMS takma adı, statik anahtar kayıt defteri veya sıkı bir şekilde kontrol edilen anahtar deposu aracılığıyla çözümlemelidir.
Kripto çalışma zamanlarını agresif bir şekilde yamalayın ve bilinen felaket sınıflarına karşı test edin. CVE-2022-21449, "doğru algoritma seçiminin" bozuk doğrulama uygulamalarını telafi edemeyeceğini hatırlatmak için mevcuttur. (Neil Madden)
Aktif problamaya işaret eden anomalileri izlersiniz. Büyük miktarlarda base64url dolgu hataları, tekrarlanan geçersiz belirteçler veya Çocuk değerleri devam eden fuzzing veya karışıklık girişimlerini gösterebilir. İzleme hatayı düzeltmez, ancak tespit süresini kısaltabilir ve şüpheli etkinliği belirli uç noktalar ve doğrulayıcılarla ilişkilendirmenize yardımcı olabilir.
Doğrulama mantığı denetiminin otomatikleştirilmesi: Penligent'ın uygun olabileceği yerler
Gerçek ortamlarda, işin zor kısmı bir jetonun kodunu bir kez çözmek değildir. Bu, belirteçlerin nerede kabul edildiğini keşfetmek, hangi hizmetlerin hangi doğrulama kurallarını uyguladığını belirlemek ve aşağı akış yetkilendirmesinin zamanından önce kodu çözülmüş taleplere bağlı olup olmadığını kanıtlamaktır. Bu "kod çözme → yorumlama → mutasyona uğratma → etkiyi doğrulama" döngüsü tekrarlayıcıdır ve tam da modern yapay zeka destekli güvenlik platformlarının sanayileşmeye yardımcı olabileceği türden bir iştir.
Penligent gibi bir platform, token merkezli testler için bir otomasyon katmanı olarak güvenilir bir şekilde konumlandırılabilir: tokenları sınıflandırmak ve yüksek sinyalli alanları (veren, hedef kitle, kapsamlar, roller) çıkarmak için çevrimdışı kod çözme gerçekleştirebilir, yanıt davranışından ve hizmet parmak izlerinden olası doğrulama yığınlarını çıkarabilir ve ardından politika kayması-algoritma izin listesi hatalarını, mikro hizmetler arasında tutarsız veren / hedef kitle uygulamasını ve güvenli olmayan anahtar seçim modellerini sistematik olarak test edebilir. Değer, "sihirli kırma belirteçleri" değil, tekrarlanabilir kanıt üretimi ve ince doğrulama gerilemelerini gönderilmeden önce yakalayan sürekli regresyon kontrolleridir.
JWS doğrulamasını güvenlik açısından kritik bir API sınırı olarak ele alıyorsanız, yapay zeka odaklı bir iş akışı bu sınırın sürümler, ortamlar ve hizmet sahipleri arasında tutarlı kalmasını sağlamanıza yardımcı olduğunda çok güçlüdür.
Sonuç
Şu komutu verin json web imzası kod çözme başlangıç çizgisidir, bitiş çizgisi değil. Kod çözme size gözlemlenebilirlik sağlar, ancak güvenlik sıkı doğrulama ve talep doğrulama, disiplinli anahtar yönetimi ve esnek çalışma zamanı hijyeninden gelir.
"Psişik İmzalar" (CVE-2022-21449) gibi yıkıcı kripto sağlayıcı hatalarından algoritma karmaşasına ve başlık odaklı anahtar tedarik zinciri risklerine kadar JWS güvenliği bir sistem özelliğidir. Dikkatli manuel analizi doğrulama sapmasını tespit eden otomasyonla birleştiren ekipler, ekosistemler gelişse ve yeni hata modları ortaya çıksa bile kimlik doğrulama katmanlarını sağlam tutabilir.
Güvenilir kaynaklar ve daha fazla okuma
RFC 7515: JSON Web İmzası (JWS). (RFC Editörü)
RFC 7519: JSON Web Belirteci (JWT). (IETF Datatracker)
PortSwigger: Algoritma karışıklık saldırıları. (PortSwigger)
OWASP WSTG: JSON Web Belirteçlerinin Test Edilmesi (OWASP Vakfı)
OWASP Hile Sayfası: Java için JSON Web Belirteci. (OWASP Hile Sayfası Serisi)
Neil Madden: Java'da Psişik İmzalar. (Neil Madden)
CVE-2022-21449'un JFrog analizi. (JFrog)
CVE-2022-21449'un kriptomatik açıklaması. (Kriptomatik)
