json web signatur dekodieren: Der Leitfaden eines Sicherheitsingenieurs, um nicht vereinnahmt zu werden

Die moderne Zugriffskontrolle lebt und stirbt von JSON-basierten Token. Wenn Sie ein OAuth-Zugriffstoken, ein OpenID Connect ID-Token oder eine signierte API-Sitzung untersuchen, sehen Sie normalerweise ein JSON-Web-Signatur (JWS) Struktur. Suchmaschinen schicken viele Leute zu "json web signature decode"-Tools, die scheinbar auf magische Weise undurchsichtige Zeichenketten in lesbares JSON verwandeln.

Für offensive und defensive Sicherheitsingenieure ist das nur der erste Schritt. Die Dekodierung eines JWS sagt Ihnen, was das Token AnsprücheEs sagt Ihnen nicht, ob diese Behauptungen vertrauenswürdig sind, ob die Signatur korrekt durchgesetzt wird oder ob die Implementierung bereits in einer CVE-Datenbank enthalten ist.

In diesem Artikel wird erläutert, was bei der Dekodierung von JSON-Web-Signaturen tatsächlich passiert, wie reale Schwachstellen aus subtilen Fehlern bei der JWS-Verifizierung entstanden sind und wie man einen wiederholbaren Arbeitsablauf erstellt, der in eine automatisierte, KI-gestützte Pentest-Pipeline passt.

Was eine JSON-Websignatur wirklich ist

Gemäß der JWS-Spezifikation stellt eine JSON-Web-Signatur beliebige Inhalte dar, die entweder durch eine digitale Signatur oder einen MAC geschützt sind, wobei JSON-basierte Strukturen verwendet werden. Sie bietet Integrität und Authentizität für eine Folge von Bytes, unabhängig davon, was diese Bytes darstellen. (IETF Datatracker)

In der Praxis ist diese Bytesequenz meist ein JSON-Objekt von Ansprüche - was wir als JSON Web Token (JWT) bezeichnen. JWS selbst ist in [RFC 7515] definiert, während JWT in einem Schwesterstandard enthalten ist, der sich darauf konzentriert, wie diese Angaben strukturiert und interpretiert werden. (Mittel)

Die bekannte Kompaktform sieht so aus:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0Iiwic2NvcGUiOlsicmVhZCIsIndyaXRlIl0sImV4cCI6MTczNDkxMjAwMH0.
ODU5Y...signature-bytes-here...

Konzeptionell handelt es sich um drei Base64URL-kodierte Teile, die durch Punkte verbunden sind:

Ein Vorgang zur Dekodierung von JSON-Web-Signaturen, der entweder von einem Online-Tool oder in Ihren eigenen Skripten durchgeführt wird, kehrt lediglich die Base64URL-Kodierung der ersten beiden Teile um und druckt das JSON aus. Es macht nicht beweisen, dass die Signatur gültig ist, es sei denn, das Tool führt explizit eine Überprüfung mit einem bekannten Schlüssel und einem eingeschränkten Algorithmensatz durch. (entwickler.pingidentity.de)

Wie json Web-Signatur-Dekodierungs-Tools tatsächlich funktionieren

Die meisten JWT/JWS-Dekoder - wie z. B. die in Browsern oder webbasierten Playgrounds verwendeten Entwickler-Tools - implementieren dieselbe minimale Pipeline:

1. Teilen Sie die Punkte in drei Segmente auf.
2. Base64URL-dekodiert die ersten beiden Segmente.
3. Parsen Sie sie als JSON für Header und Payload.
4. Wird ein Prüfschlüssel angegeben, wird die Signatur mit dem im Header angegebenen Algorithmus neu berechnet und mit dem dritten Segment verglichen. (entwickler.pingidentity.de)

Aus der Sicht eines Sicherheitsingenieurs sind die Schritte 1-3 sicher genug für eine Offline-Analyse; in Schritt 4 verbergen sich die meisten Schwachstellen.

Minimaler Python-Dekodier-Schnipsel

Hier ist ein bewusst einfach gehaltener Decodier-Schnipsel in Python, der nützlich ist, wenn Sie während eines Pests die erfassten Token durchsuchen:

base64 importieren
json importieren

def b64url_decode(data: str) -> bytes:
    # JWT Auffüllungsbehandlung
    padding = '=' * (-len(Daten) % 4)
    return base64.urlsafe_b64decode(daten + padding)

def decode_jws(token: str):
    header_b64, payload_b64, signature_b64 = token.split('.')
    header = json.loads(b64url_decode(header_b64))
    Nutzdaten = json.loads(b64url_decode(Nutzdaten_b64))
    return header, payload, signature_b64

jws = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...."
h, p, sig = decode_jws(jws)
print("Kopfzeile:", h)
print("Nutzdaten:", p)

Beachten Sie, dass diese Funktion niemals eine Verifizierungsroutine aufruft; es wird nur dekodiert. Das ist oft genau das, was man will, wenn man ein neues Ziel prüft: schnelle Prüfung ohne kryptografische Annahmen.

Node.js-Snippet mit Überprüfung

Sobald Sie über die Dekodierung hinaus zur Verifizierung übergehen, ist jedes Detail wichtig:

import jwt von "jsonwebtoken";
import fs from "fs";

const publicKey = fs.readFileSync("public.pem", "utf-8");

function verifyJws(token) {
  // Kritisch: unterstützte Algorithmen explizit festschreiben
  return jwt.verify(token, publicKey, {
    Algorithmen: ["RS256"],
  });
}

Wenn Sie die Algorithmen Wenn Sie eine Whitelist erstellen und die Bibliothek den Algorithmus aus dem nicht vertrauenswürdigen Header ableiten lassen, wiederholen Sie genau die Bedingungen, die zu mehreren JWT CVEs geführt haben.

Die Dekodierung ist harmlos, das Vertrauen in die dekodierten Daten ist nicht

In Berichten über Zwischenfälle und CVEs taucht immer wieder ein Muster auf: Entwickler behandeln entschlüsselt JWT / JWS-Daten, als ob sie bereits vorhanden wären verifiziert. In mehreren modernen Abhandlungen über JWT-Sicherheitsprobleme wird betont, dass die Dekodierung von Base64URL trivial ist und dass die Geheimhaltung eines Tokens nicht dadurch entsteht, dass es "schwer zu lesen ist". (PortSwigger)

Drei wiederkehrende Klassen von Fehlern fallen auf:

1. Das Feld "alg" wird als eine Quelle der Wahrheit behandelt. Wenn Ihr Verifizierungscode den zu verwendenden Algorithmus aus der Kopfzeile bezieht - die vom Benutzer gesteuert wird -, laden Sie zu Algorithmus-Verwechslungsangriffen ein.
2. Die keine Algorithmus versehentlich akzeptiert wird. Der JWT-Standard erforderte in der Vergangenheit Unterstützung für "keine" als einen Algorithmus, der "kein Integritätsschutz" bedeutet. Die klassische Analyse von Auth0 zeigte, wie mehrere Bibliotheken diese Wahl naiv beachteten und unsignierten Token erlaubten, Prüfungen zu bestehen. (Auth0)
3. Wichtige Hinweise (Kind, eingebettet jwk, x5u) werden nicht validiert. Sowohl im JWS-RFC als auch in den Testleitfäden wird hervorgehoben, dass Angreifer durch die Möglichkeit, dass das Token seinen eigenen Verifizierungsschlüssel ohne striktes Whitelisting wählen kann, beliebige öffentliche Schlüssel einschmuggeln oder Schlüsselabfragen an vom Angreifer kontrollierten Orten erzwingen können. (PortSwigger)

Mit anderen Worten, die Dekodierung der json-Web-Signatur bietet Ihnen Beobachtbarkeit. Es gibt Ihnen kein Vertrauen. Diese Unterscheidung ist es, die eine sichere Debugging-Einrichtung von einer Schlagzeile zur Remotecodeausführung unterscheidet.

Wenn Dekodierung auf CVEs trifft: konkrete JWS-Fehlermodi

Um zu verstehen, wie sehr die Dinge schief gehen können, wenn Decodierung und Verifizierung miteinander vermengt werden, lohnt es sich, einige CVEs zu betrachten, die sich um die JWS-Verifizierungslogik drehen.

CVE-2015-9235 - HS/RS-Schlüsselverwechslung in jsonwebtoken

In der Node.js jsonwebtoken Modul vor Version 4.2.2 war es aufgrund eines Designfehlers möglich, die Signaturprüfung zu umgehen, indem von einem asymmetrischen Algorithmus (RS256 / ES256-Familien) zu einem symmetrischen (HS256) gewechselt wurde. Der verwundbare Codepfad verwendete denselben Wert - den öffentlichen RSA-Schlüssel - als HMAC-Geheimnis, wenn der Angreifer den alg Kopfzeile nach HS256. (nvd.nist.gov)

Aus der Sicht des Angreifers ist der Arbeitsablauf einfach:

1. Dekodieren Sie das ursprüngliche Token und prüfen Sie den Header.
2. Extrahieren Sie den öffentlichen Schlüssel des Servers (z. B. aus einem JWK-Endpunkt oder Zertifikat).
3. Fälschen eines neuen Tokens mit einem HS256-Header, wobei der öffentliche Schlüssel als HMAC-Geheimnis verwendet wird.
4. Legen Sie das gefälschte Token vor; der Server behandelt es fälschlicherweise als gültig.

Hier lieferte die Dekodierung dem Angreifer das Rohmaterial (Header, Algorithmus, Schlüsselpositionen); die Verifizierungslogik erledigte den Rest.

CVE-2018-1000531 - Akzeptieren der keine Algorithmus

Diese Schwachstelle deckte Fälle auf, in denen Bibliotheken Token akzeptierten, die mit dem keine Algorithmus, so dass sie trotz fehlender Signatur als gültig behandelt werden. Das Exploit-Muster ist fast schon komisch einfach: Ändern Sie "alg": "RS256" zu "alg": "keine"entfernen Sie den Signaturteil, und prüfen Sie, ob die Ziel-API das Token akzeptiert. (0xn3va.gitbook.io)

CVE-2023-48238 - Algorithmus Verwirrung in json-web-token

Die json-web-token Bibliothek für JavaScript wurde durch einen weiteren Algorithmus-Verwechslungsangriff verwundbar. Das Kernproblem: Der für die Überprüfung verwendete Algorithmus wurde direkt aus dem Token-Header entnommen, der zu diesem Zeitpunkt nicht vertrauenswürdig war. Dadurch konnten Angreifer einen bequemeren Algorithmus wählen als den, von dem der Serverbetreiber dachte, dass er ihn erzwingen würde. (nvd.nist.gov)

CVE-2024-54150 - Verwirrung in einer C JWT-Implementierung

In jüngerer Zeit hat die cjwt C-Bibliothek litt unter einem kritischen Algorithmus-Verwechslungsfehler, der jetzt als CVE-2024-54150 verfolgt wird. Eine Codeüberprüfung ergab, dass die Implementierung HMAC-basierte Algorithmen bei der Verifizierung von Token nicht ordnungsgemäß von RSA/EC-Algorithmen unterscheidet, was wiederum die Möglichkeit einer Schlüsselverwechslung eröffnet. (nvd.nist.gov)

Diese Fälle sind keine historischen Kuriositäten, sondern zeigen, dass selbst im Jahr 2023-2024 subtile Fehler bei der Überprüfung von JWS eine aktive Quelle für ernsthafte Schwachstellen bleiben.

Um während einer Bewertung den Überblick zu behalten, erstellen viele Teams einen Spickzettel wie den folgenden:

Während einer Übung zur Dekodierung von JSON-Web-Signaturen ist die explizite Zuordnung der beobachteten Token zu dieser Tabelle ein schneller Weg, um zu erkennen, welche Playbooks Sie ausprobieren sollten.

Ein praktischer Decode-First-Workflow für Pentester

Bei der Bewertung eines API- oder SSO-Systems, das auf JWS basiert, vermeidet ein disziplinierter Decode-First-Workflow sowohl blinde Flecken als auch lautes Rätselraten.

1. Erfassen und katalogisieren Sie Token. Verwenden Sie Ihren Proxy oder Ihr Test-Harness, um alle Token zu erfassen: Autorisierungs-Header, Cookies, URL-Parameter. Gruppieren Sie sie nach Ausstellern und Zielgruppen.
2. Dekodieren Sie Header und Payload offline. Verwenden Sie Skripte wie das obige Python-Snippet oder jwt_tool nur zu entschlüsseln; verlassen Sie sich in realen Einsätzen niemals auf einen Online-Dienst für sensible Token. (GitHub)
3. Erstellen Sie eine Kopfmatrix. Erfassen Sie für jede Token-Familie alg, Kind, Vorhandensein von jku / jwk / x5uund alle benutzerdefinierten Header-Felder. An dieser Stelle wird die Anleitung von PortSwigger zu eingebetteten JWKs und von Angreifern bereitgestellten Schlüsseln direkt umsetzbar. (PortSwigger)
4. Ableitung von Schlüsselverwaltungsmustern. Auf der Grundlage von Header-Feldern und bekannten Endpunkten (/.well-known/jwks.json), skizzieren Sie, wie die Schlüssel verteilt und gedreht werden.
5. Testen Sie auf bekannte Klassen von Fehlern.
   • Versuchen Sie die Null-Signatur / keine Varianten, wenn die Bibliothek oder der Stack sie in der Vergangenheit unterstützt hat.
   • Führen Sie HS/RS-Schlüsselverwechslungsversuche durch, wenn die Algorithmen nicht gesperrt sind.
   • Sonde Kind Behandlung von Verzeichnistraversal oder Dateieinschlussverhalten.
   • Versuchen Sie eine eingebettete JWK-Injektion, wenn die Spezifikation dies zulässt, aber die Implementierung dies nicht einschränkt.
6. Dann, und nur dann, gehen Sie zu vollständigen Ausbeutungsversuchen über. In diesem Stadium sollten Sie genau wissen, was Sie beweisen wollen, und nicht nur Nutzlasten auf eine Blackbox werfen.

In diesem Prozess ist die Dekodierung der json-Web-Signatur die Beobachtungsebene für den Rest Ihrer Angriffsmethodik.

Integration der Dekodierung von json-Websignaturen in eine KI-gesteuerte Pentest-Pipeline (Penligent.ai)

Die manuelle Analyse funktioniert für ein einzelnes Engagement; in größerem Umfang benötigen die Teams etwas, das einer Pipeline näher kommt. Eine KI-gestützte Plattform wie Penligent.ai kann die Dekodierung von json-Web-Signaturen direkt in seine Erkundungs- und Ausnutzungsphasen einbinden.

In einem typischen Setup nimmt die Plattform HTTP-Datenverkehr von einer Browser-Sandbox oder einem Proxy auf, extrahiert automatisch Token-Kandidaten und führt eine Massen-JWS-Dekodierung von Headern und Payloads durch. Der KI-Agent clustert dann die Token nach Aussteller, Algorithmus und Schlüsselhinweisen und sucht nach Anomalien wie unerwarteter Algorithmenvielfalt, seltsamen Kind Kodierungen oder ungewöhnliche Anspruchskombinationen.

Sobald diese Baseline erstellt ist, kann Penligents Angriffs-Engine automatisch kuratierte JWT/JWS-Playbooks ausführen: Null-Signatur-Versuche, Algorithmus-Verwechslungsszenarien, eingebettete JWK- oder jku Missbrauch und bekannte CVE-inspirierte Sonden. Anstatt diese Überprüfungen dem Gedächtnis eines Menschen zu überlassen, behandelt das System sie als wiederholbare Testfälle, die auf jedem Ziel ausgeführt werden und deren Ergebnisse in eine evidenzbasierte Risikoliste und einen maschinenlesbaren Bericht einfließen.

Für Sicherheitsingenieure, die eine interne "KI-Red-Team"-Fähigkeit aufbauen, ist die Einbindung der Dekodierung von json-Web-Signaturen in eine solche automatisierte Pipeline oft eines der wichtigsten Elemente der Low-Level-Installation.

Checkliste für die Härtung und weiterführende Literatur

Wenn Sie in Ihrer täglichen Arbeit JWS/JWT-Tokens ausstellen oder überprüfen, können Sie dies als Mindestanforderung betrachten:

• Erzwingen Sie eine strenge, serverseitige Liste zulässiger Algorithmen; lesen Sie niemals alg von einem nicht vertrauenswürdigen Token als Richtlinie.
• Getrennte Schlüssel für asymmetrische Signaturen und HMAC-Geheimnisse; niemals einen öffentlichen RSA-Schlüssel als HMAC-Schlüssel wiederverwenden.
• Dauerhaft deaktivieren keine in Produktionsbibliotheken und lehnen jedes Token ab, das es bewirbt.
• Behandeln Sie alle Kopffelder (Kind, jku, jwk, x5u) als nicht vertrauenswürdige Eingaben und validieren sie anhand eines festgelegten Schlüsselsatzes oder einer Whitelist.
• Halten Sie Ihre JWT-Bibliotheken gepatcht; überprüfen Sie regelmäßig CVEs wie CVE-2015-9235, CVE-2018-1000531, CVE-2023-48238 und CVE-2024-54150, um zu sehen, ob Ihr Stack betroffen ist. (Swisskys Labor)
• Hinzufügen von Regressionstests, die explizit Nicht-/Algorithmus-Verwirrungs-Szenarien trainieren.

Wenn Sie tiefer eintauchen möchten, sollten Sie diese englischsprachigen Referenzen als Lesezeichen speichern und von Ihren internen Runbooks aus verlinken:

• Der Kern [JSON Web Signature (JWS) RFC 7515] von der IETF. (IETF Datatracker)
• OWASP's Abschnitt über [Testing JSON Web Tokens] im Web Security Testing Guide. (OWASP-Stiftung)
• PortSwigger's Web Security Academy Labs über [JWT-Angriffe] und [Algorithmus-Verwirrung]. (PortSwigger)
• Tim McLeans klassischer Auth0-Aufsatz über [kritische Schwachstellen in JSON-Web-Token-Bibliotheken]. (Auth0)
• Der sich entwickelnde Entwurf [JWT Best Current Practices] in der IETF OAuth Arbeitsgruppe. (IETF)

Richtig eingesetzt, ist json web signature decode nicht nur ein Debugging-Komfort; es ist die Eingangstür zu einem systematischen Weg, die Authentifizierungsstruktur Ihrer Anwendungen zu verstehen, anzugreifen und zu härten.