Warum die Entschlüsselung von JWS nur der Einstieg ist
In modernen Identitätsarchitekturen - insbesondere bei OAuth 2.0 und OpenID Connect - werden signierte Token häufig als "vertrauenswürdige Container" behandelt, die zwischen Diensten weitergegeben werden können. Für Sicherheitsingenieure, Red-Teamer und KI-Sicherheitsforscher ist ein JWS jedoch besser als kompakte, vom Angreifer kontrollierte Eingabe zu verstehen, die sich an der Schnittstelle zwischen Kryptografie und Geschäftslogik befindet. Die Fähigkeit zur Durchführung einer rohen json web signatur dekodieren ist nicht das Ziel; es ist die Instrumentierung, die es ermöglicht, zu verstehen, was der Prüfer denkt was der Antrag prüft, was die Anwendung eigentlich für die Autorisierung verwendet, und welche Teile des Tokens als Konfiguration und nicht als nicht vertrauenswürdige Daten behandelt werden.
Diese Unterscheidung ist wichtig, weil die "Token-Sicherheit" keine Eigenschaft des Token-Formats ist. Sie ist eine Eigenschaft des Pipeline für die Überprüfung und Validierung von Anträgen-Algorithmusauswahl, Schlüsselauswahl, Aussteller-/Publikumsüberprüfungen, zeitbasierte Ansprüche und, was besonders wichtig ist, wie der nachgelagerte Code Ansprüche verwendet, sobald er sie hat. In dem Moment, in dem ein System dekodierte Ansprüche als "Wahrheit" behandelt, bevor die Überprüfung abgeschlossen ist (oder überhaupt läuft), hört der Token auf, eine Sicherheitsgrenze zu sein, und wird zu einem vom Benutzer kontrollierten Parameter.
Die Technik hinter der Zeichenkette: Base64url ohne Füllung
Wenn man von "JWS dekodieren" spricht, bedeutet das in der Regel, dass man einen base64url-Kodierungsschritt umkehrt. Bei der kompakten JWS-Serialisierung wird jedes der drei Segmente base64url-kodiert, wobei das URL-sichere Alphabet verwendet und in der Regel Folgendes weggelassen wird = Auffüllen. RFC 7515 definiert das kompakte Format und verwendet ausdrücklich BASE64URL(...) für die Konstruktion von Header und Payload, dann verkettet mit . Trennzeichen. (RFC-Editor)
Die Konvention "kein Padding" hört sich unbedeutend an, bis Sie Werkzeuge entwickeln oder den erfassten Datenverkehr in großem Umfang analysieren. Viele generische base64-Routinen gehen davon aus, dass Padding vorhanden ist und geben entweder Fehler aus oder produzieren mehrdeutige Ausgaben, wenn Padding fehlt. Ein robuster Decoder muss Padding deterministisch wieder einfügen und eine base64url-fähige Dekodierroutine verwenden, andernfalls wird Ihre Analyse nicht reproduzierbar - insbesondere wenn Sie während des Fuzzings mit missgebildeten oder absichtlich beschädigten Token zu tun haben.
JWS vs. JWT: was die einzelnen Punkte tatsächlich bedeuten
Ein JWS Compact Token ist immer:
BASE64URL(Kopfzeile) . BASE64URL(Nutzdaten) . BASE64URL(Signatur)
Das dritte Segment ist nicht "hex". Es ist die base64url der Signatur (oder MAC) Bytes. Behandeln Sie es als undurchsichtig, es sei denn, Sie verifizieren es oder führen eine kryptografische Triage durch.
JWT (RFC 7519) ist eine Claim-Set-Konvention, die üblicherweise in der JWS-Nutzlast enthalten ist, weshalb "JWT" mit "JWS" verwechselt wird. RFC 7519 definiert registrierte Ansprüche wie Ausgabe, unter, aud, expund nbfund beschreibt, wie diese Ansprüche als JSON-Objekt dargestellt werden. (IETF Datatracker)
In der Praxis bedeutet dies, dass ein reiner Dekodierschritt Ihnen sagen kann, was das Token Ansprücheaber sie kann Ihnen nicht sagen, ob diese Ansprüche wahr. Die Wahrheit kommt erst dann ans Licht, wenn Unterschriftenprüfung und Anspruchsprüfung erfolgreich sind.
Der Header ist die Angriffsfläche: alg, Kind, jku als nicht vertrauenswürdige Eingaben
In gut konzipierten Systemen ist der Token-Header eine Metadatei, die dem Prüfer hilft, eine bekannt gute Prüfstrategie auszuwählen. In schlecht konzipierten Systemen wird der Header zu einem vom Angreifer kontrollierten Konfigurationskanal. Aus diesem Grund wird während einer json web signatur dekodierenViele Fachleute konzentrieren sich zunächst auf die Kopfzeile.
Die alg Wert ist besonders sensibel, da er beeinflussen kann, welche Verifizierungsmethode aufgerufen wird. Algorithmus-Verwirrung (auch Schlüssel-Verwirrung genannt) liegt vor, wenn ein Angreifer den Server dazu zwingen kann, ein JWT mit einem anderen Algorithmus zu verifizieren als vom Entwickler beabsichtigt, was möglicherweise gefälschte Token ermöglicht, ohne den Signierschlüssel des Servers zu kennen. In der Web Security Academy von PortSwigger wird diese Klasse klar beschrieben und mit einer Fehlkonfiguration oder einer fehlerhaften Handhabung der Algorithmusauswahl in Verbindung gebracht. (PortSwigger)
Die Kind Parameter ist keine Kryptographie, sondern eine Schlüsselabfrage. Wenn Kind Dateipfade, Datenbankabfragen, Cache-Schlüssel oder dynamische Resolver ohne strenge Zulässigkeitsliste beeinflussen, wird es zu einer allgemeinen Injektionsfläche innerhalb der Schlüsselverwaltungsgrenze.
Die jku Parameter ist sogar noch gefährlicher, wenn er missbraucht wird. Wenn ein Server einen JWKS von einer im Token-Header angegebenen URL (oder von einer unzureichend eingeschränkten Variante) abruft, kann der Angreifer versuchen, den Vertrauensanker zu ersetzen, indem er die Prüfstelle auf vom Angreifer kontrollierte Schlüssel verweist. Selbst wenn ein System "nur von HTTPS abruft", wird der Schlüsselabruf durch das Fehlen von strengen Zulässigkeitslisten, Emittentenbindung, Cache-Richtlinien und Prüfpfaden zu einem Problem der Lieferkette und nicht zu einem Kryptoproblem.
Ein produktionsgerechter Offline-Decoder in Python (nur Dekodierung, padding-safe)
Webbasierte Token-Debugger sind zwar praktisch, aber in der professionellen Sicherheitsarbeit sind sie oft eine schlechte Idee. Token können sensible Identifikatoren, E-Mails, interne Mieter-IDs oder sogar eingebettete PII enthalten. Sie benötigen ein skriptfähiges Offline-Tool, das deterministisch und sicher ist, wenn es um missgebildete Eingaben geht. Die folgende Implementierung "verifiziert" absichtlich nichts; sie dekodiert nur, was vorhanden ist, und macht Fehlermodi beobachtbar.
base64 importieren
importiere json
von typing import Any, Dict, Tuple, Optional
def _b64url_decode(daten: str) -> bytes:
# RFC 7515 base64url lässt üblicherweise "=" Padding aus; stellen Sie es deterministisch wieder her.
pad = (-len(Daten)) % 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 {"error": "Ungültiges JWS-Kompaktformat (erwartet 3 Teile).", "Teile": len(Teile)}
Kopfzeile_b = _b64url_decode(Teile[0])
Nutzdaten_b = _b64url_decode(Teile[1])
header, he = _parse_json(header_b)
Nutzlast, pe = _parse_json(Nutzlast_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] + "..."
}
wenn header nicht None ist:
out["header"] = header
sonst:
out["header_error"] = he
wenn payload nicht None ist:
out["payload"] = payload
else:
out["payload_error"] = pe
return out
Dies entspricht der Verwendung von base64url nach RFC 7515 (und der Tatsache, dass kompakte JWS für URL/HTTP-Header-Kontexte konzipiert sind), während Sie gleichzeitig ein stabiles Verhalten erhalten, wenn das Token missgebildet, abgeschnitten oder absichtlich gefuzzt wird. (RFC-Editor)
Die kritische Lücke: Dekodierung vs. Verifizierung (und das wahre Fehlerbild)
Der hartnäckigste Sicherheitsirrtum im Zusammenhang mit JWS/JWT ist die Verwechslung von Decodierung und Verifizierung. Dekodierung ist umkehrbare Formatierung; Verifizierung ist kryptographische Validierung plus Durchsetzung von Richtlinien.
Bei realen Vorfällen ist das übliche Fehlermuster eher "use-before-verify" als ein buchstäblicher Wettlauf. Eine Anwendung entschlüsselt das Token, liest Rolle, Benutzer_id, Mieter, oder Umfangund trifft Autorisierungsentscheidungen, bevor Signaturprüfung und Anspruchsprüfung endgültig durchgesetzt sind. Der OWASP-Leitfaden zur JWT-Prüfung hebt hervor, wie ein falscher Umgang mit Algorithmenerwartungen und Verifizierungslogik Angriffe mit großer Wirkung ermöglicht, einschließlich der Verwechslung zwischen asymmetrischen und symmetrischen Verifizierungsabläufen. (OWASP-Stiftung)
Selbst wenn die Unterschrift gültig ist, muss ein Token immer noch auf seine Gültigkeit überprüft werden. RFC 7519 definiert aud als Zielpublikum und stellt fest, dass das Token abgelehnt werden muss, wenn der Auftraggeber, der das Token verarbeitet, sich nicht als Zielpublikum identifiziert, wenn aud vorhanden ist. (IETF Datatracker) Das ist ein Hinweis darauf, dass kryptografische Gültigkeit nicht gleichbedeutend mit kontextueller Gültigkeit ist.
Erweiterte Ausnutzung: über "alg: none" hinaus
Die "alg: none"-Erzählung ist historisch wichtig, aber die meisten modernen Bibliotheken blockieren sie standardmäßig. Die interessanteren Fehler fallen heute eher in zwei Kategorien: Implementierungsfehler in Kryptoanbietern und komplexe Logikumgehungen, die durch flexible Verifikationspipelines verursacht werden.
Psychic Signatures (CVE-2022-21449): wenn ECDSA Überprüfung liegt
CVE-2022-21449 - auch bekannt als "Psychic Signatures" - ist eine schwerwiegende Java-Kryptografieschwachstelle, bei der die ECDSA-Signaturprüfung unter bestimmten Bedingungen in den betroffenen Java-Versionen umgangen werden kann (insbesondere eingeführt in Java 15 und behoben in der CPU vom April 2022). Analysen betonen, wie dramatisch diese Schwachstelle Systeme schwächt, die auf ECDSA-Signaturen angewiesen sind, einschließlich Szenarien mit ECDSA-signierten JWTs oder WebAuthn-Mechanismen. (Neil Madden)
Die wichtigste Lehre für die Token-Sicherheit ist nicht die Cleverness der Umgehung, sondern die betriebliche Realität, dass "Ich habe ES256 gewählt" keine Garantie ist. Ihre Laufzeitversion, die Implementierung des Sicherheitsanbieters und der Patch-Status sind Teil Ihres Bedrohungsmodells. Sicherheitsteams sollten "Regressionen bei Kryptoanbietern" als erstklassige Risiken behandeln, mit expliziten Patch-SLAs und Regressionstests, die eine Überprüfung gegen missgebildete Signaturen durchführen.
Algorithmus-Verwirrung / Schlüssel-Verwirrung: wenn der Server den Token die Regeln auswählen lässt
Algorithmus-Verwechslungsangriffe treten auf, wenn der Überprüfer zulässt, dass der Token beeinflusst, welcher Algorithmus für die Überprüfung verwendet wird, und die Schlüsselverarbeitung nicht sauber zwischen asymmetrischem und symmetrischem Modus getrennt ist. PortSwigger merkt an, dass wenn dieser Fall nicht richtig behandelt wird, Angreifer gültige JWTs fälschen können, die beliebige Werte enthalten, ohne den geheimen Signierschlüssel des Servers zu kennen. (PortSwigger)
In der Praxis ist die Verteidigung konzeptionell einfach, wird aber häufig übersehen: Lassen Sie niemals "Algorithmusflexibilität" an der Grenze zu, an der Authentifizierungsentscheidungen getroffen werden. Wenn Ihr Dienst RS256 erwartet, setzen Sie RS256 durch. Sie akzeptieren nicht "welchen Algorithmus auch immer im Header steht und schauen, ob er validiert".
Kopfzeilengesteuertes Abrufen von Schlüsseln: Kind/jku als Überprüfung der Lieferkette
Sobald Sie akzeptieren, dass die Kopfzeile eine Eingabe des Angreifers ist, akzeptieren Sie auch, dass die Schlüsselauswahl Teil Ihrer Angriffsfläche ist. A Kind sollte sich auf eine vordefinierte Liste von Schlüsseln beziehen, nicht auf beliebiges Schlüsselmaterial, das zur Laufzeit geholt, geladen oder konstruiert wird. A jku sollte niemals zulassen, dass ein Token neu definiert, woher die Vertrauensanker kommen. Wenn Sie das Abrufen von JWKS für OIDC unterstützen, sollte es an eine vertrauenswürdige Ausstellerkonfiguration gebunden und durch Zulässigkeitslisten, Zwischenspeicherung und Überwachung abgesichert sein.
Härtungsstrategien, die die Produktionsdrift überstehen
Ein Defense-in-Depth-Ansatz für die JWS-Validierung sieht auf dem Papier eher langweilig aus, ist aber genau das, was die Mehrzahl der Token-Fehler verhindert.
Sie legen ausdrücklich die akzeptierten Algorithmen fest und verlangen, dass der Überprüfer durchsetzt, dass der erwartete Algorithmus verwendet wurde. In der JWT-Anleitung für Java von OWASP wird dieser Punkt direkt als Präventivmaßnahme genannt. (OWASP-Spickzettel-Serie)
Sie validieren den Aussteller und das Publikum einheitlich. Die in RFC 7519 enthaltenen Definitionen für registrierte Ansprüche sind nicht akademischer Natur; sie existieren, weil "gültige Signatur, falscher Kontext" eine häufige Fehlerklasse ist. Insbesondere die Nichtübereinstimmung der Zielgruppe ist eine der einfachsten Möglichkeiten, versehentlich einen Token zu akzeptieren, der für einen anderen Dienst geprägt wurde. (IETF Datatracker)
Sie behandeln Schlüssel-IDs als Daten, nicht als Suchabfrage. A Kind sollte durch ein begrenztes Mapping - KMS-Alias, statische Schlüsselregistrierung oder streng kontrollierter Schlüsselspeicher - aufgelöst werden, nicht durch einen Dateisystempfad oder eine Datenbankabfrage, die aus nicht vertrauenswürdigen Eingaben erstellt wurde.
Sie patchen Krypto-Laufzeiten aggressiv und testen gegen bekannte katastrophale Klassen. CVE-2022-21449 existiert als Erinnerung daran, dass die "korrekte Wahl des Algorithmus" nicht für fehlerhafte Verifikationsimplementierungen kompensieren kann. (Neil Madden)
Sie überwachen Anomalien, die auf aktives Sondieren hindeuten. Große Mengen von base64url-Auffüllfehlern, wiederholte ungültige Token oder hohe Abwechslung in Kind Werte können auf laufende Fuzzing- oder Verwechslungsversuche hinweisen. Die Überwachung wird den Fehler nicht beheben, aber sie kann die Erkennungszeit verkürzen und Ihnen helfen, verdächtige Aktivitäten mit bestimmten Endpunkten und Prüfern zu korrelieren.
Automatisierung der Prüfung der Verifizierungslogik: wo Penligent eingesetzt werden kann
In realen Umgebungen besteht die Schwierigkeit nicht in der einmaligen Dekodierung eines Tokens. Es geht darum, herauszufinden, wo Token akzeptiert werden, zu ermitteln, welche Dienste welche Überprüfungsregeln durchsetzen, und zu prüfen, ob die nachgelagerte Autorisierung vorzeitig von dekodierten Ansprüchen abhängt. Diese Schleife "Dekodieren → Interpretieren → Mutieren → Validieren der Auswirkungen" wiederholt sich und ist genau die Art von Arbeit, bei der moderne KI-gestützte Sicherheitsplattformen helfen können, sie zu industrialisieren.
Eine Plattform wie Penligent kann glaubwürdig als Automatisierungsschicht für Token-zentrierte Tests positioniert werden: Sie kann Offline-Decodierung durchführen, um Token zu klassifizieren und Felder mit hohem Signalwert zu extrahieren (Aussteller, Zielgruppe, Bereiche, Rollen), wahrscheinliche Verifizierungsstapel aus dem Antwortverhalten und den Service-Fingerprints ableiten und dann systematisch auf Policy-Drift-Algorithmus-Allowlist-Fehler, inkonsistente Aussteller-/Zielgruppen-Durchsetzung über Microservices hinweg und unsichere Schlüsselauswahlmuster testen. Der Wert liegt nicht in "magischen, brechenden Token", sondern in der wiederholbaren Generierung von Beweisen und kontinuierlichen Regressionstests, die subtile Verifikationsregressionen abfangen, bevor sie auftreten.
Wenn Sie die JWS-Verifizierung als sicherheitskritische API-Grenze betrachten, dann ist ein KI-gesteuerter Workflow dann am leistungsfähigsten, wenn er Ihnen hilft, diese Grenze über alle Versionen, Umgebungen und Servicebesitzer hinweg konsistent zu halten.
Schlussfolgerung
Der Befehl an json web signatur dekodieren ist die Startlinie, nicht die Ziellinie. Durch Dekodierung erhält man Beobachtbarkeit, aber Sicherheit entsteht durch strenge Verifizierung und Anspruchsvalidierung, disziplinierte Schlüsselverwaltung und robuste Laufzeithygiene.
Von katastrophalen Ausfällen von Krypto-Anbietern wie "Psychic Signatures" (CVE-2022-21449) bis hin zu Algorithmus-Verwirrungen und Header-gesteuerten Risiken in der Schlüssel-Lieferkette - JWS-Sicherheit ist eine Systemeigenschaft. Teams, die eine sorgfältige manuelle Analyse mit einer Automatisierung kombinieren, die Verifikationsabweichungen erkennt, können ihre Authentifizierungsschichten robust halten - selbst wenn sich Ökosysteme weiterentwickeln und neue Fehlermöglichkeiten entstehen.
Zuverlässige Ressourcen und weiterführende Literatur
RFC 7515: JSON Web Signature (JWS). (RFC-Editor)
RFC 7519: JSON Web Token (JWT). (IETF Datatracker)
PortSwigger: Algorithmus-Verwechslungsangriffe. (PortSwigger)
OWASP WSTG: Testen von JSON-Web-Tokens (OWASP-Stiftung)
OWASP-Spickzettel: JSON Web Token für Java. (OWASP-Spickzettel-Serie)
Neil Madden: Psychische Signaturen in Java. (Neil Madden)
JFrog-Analyse von CVE-2022-21449. (JFrog)
Kryptomathische Erklärung von CVE-2022-21449. (Kryptomathisch)
