Was ein entschlüsseltes JWT beweist

Ein JWT-Decoder zeigt Ihnen, was ein Token beansprucht. Es kann Ihnen nicht zeigen, ob diese Behauptungen wahr sind. In diesem Leitfaden wird erläutert, was die drei Segmente sind, was die Dekodierung bewirkt und was nicht und welche Angriffe in der Lücke zwischen den beiden stattfinden.

Drei Segmente, zwei davon nur JSON

Ein JWT in seiner üblichen Form ist ein JWS: drei durch Punkte getrennte base64url-Segmente. Der erste ist ein Header, der zweite eine Nutzlast, der dritte eine Signatur.

Der Header und die Nutzlast sind gewöhnliche JSON-Objekte, die base64-URL-codiert wurden. Verschlüsselt, nicht verschlüsselt. Jeder, der den Token besitzt, kann beides sofort und ohne Schlüssel lesen – das ist kein Fehler, sondern das Design. Ein JWT ist eine unterschriebene Erklärung, kein versiegelter Umschlag. Die Unterschrift garantiert, dass die Aussage nicht verändert wurde; es trägt nicht dazu bei, es privat zu halten.

Die Konsequenz ist es wert, klar dargelegt zu werden, da sie regelmäßig übersehen wird: Fügen Sie niemals vertrauliche Informationen in eine JWT-Nutzlast ein. Kein Passwort, keine vollständige nationale Kennung, keine internen Systemdetails. Gehen Sie davon aus, dass die Nutzdaten öffentlich sind, denn für jeden, der das Token besitzt, ist es öffentlich.

Das dritte Segment ist die Signatur, berechnet über die ersten beiden. Es ist der einzige Teil, der einen Sicherheitswert hat, und es ist der Teil, den ein Decoder nicht auswerten kann.

Was die Dekodierung beweist: nichts

Darum geht es im gesamten Leitfaden. Beim Dekodieren eines JWT werden zwei base64url-Strings in JSON analysiert. Es bestätigt, dass das Token wohlgeformt ist. Es wird nicht bestätigt, dass der Token echt ist, dass er von der im "iss"-Anspruch genannten Partei ausgestellt wurde, dass die Ansprüche nicht bearbeitet wurden oder dass er jemals gültig war.

Jeder kann einen Token erstellen. Nehmen Sie ein beliebiges JWT, ändern Sie „role“: „user“ in „role“: „admin“, codieren Sie die Nutzlast neu, heften Sie eine beliebige Signatur an das Ende und ein Decoder zeigt Ihre bearbeiteten Ansprüche genauso sicher an wie das Original. Es gibt keine Möglichkeit, den Unterschied zu erkennen, da die Überprüfung des Unterschieds ein anderer Vorgang ist, der einen Schlüssel erfordert, den der Decoder nicht hat.

Wenn Ihnen also ein Decoder – dieser oder ein anderer – „exp: 2026-01-01“ anzeigt, sagt er Ihnen in Wirklichkeit Folgendes: Dieser Token enthält den Anspruch, dass er an diesem Datum abläuft. Ob diese Behauptung etwas bedeutet, hängt ganz davon ab, ob die Unterschrift gültig ist, was nicht überprüft wurde.

Dieses Tool dekodiert nur und gibt dies jedes Mal auf der Seite neben den Ergebnissen an. Nicht in einer Fußnote. Der Grund dafür ist, dass ein Decoder, der darüber schweigt, seinen Benutzern beibringt, nicht verifizierte Daten so zu lesen, als ob sie verifiziert wären, und diese Angewohnheit ist die Wurzel einer ganzen Familie von Authentifizierungsfehlern.

Warum dieses Tool keine Verifizierung bietet

Für die Verifizierung sind drei Dinge erforderlich, die eine Webseite nicht verantwortungsbewusst haben kann: den Schlüssel des Ausstellers, den im Voraus festgelegten Algorithmus und eine Richtlinie darüber, was abgelehnt werden soll.

Der Schlüssel liegt im offensichtlichen Problem. Bei HMAC-Algorithmen (HS256 und Co.) ist der Schlüssel ein gemeinsames Geheimnis – dasselbe Geheimnis, das zum Erstellen von Token verwendet wird. Das Einfügen in eine Webseite bedeutet, dass ein Berechtigungsnachweis, der gültige Token prägen kann, in eine Webseite eingefügt wird. Für RSA und ECDSA ist der öffentliche Schlüssel nicht geheim, aber Sie müssten dennoch den richtigen Schlüssel vom richtigen JWKS-Endpunkt abrufen und ihm vertrauen.

Der Algorithmus ist das subtile Problem und die Quelle zweier bekannter Angriffe. Das erste ist alg: "none": Der Header behauptet, dass das Token nicht signiert ist, und ein Verifizierer, der den Header und nicht seine eigene Konfiguration berücksichtigt, akzeptiert alles. Das zweite Problem ist die RS256-zu-HS256-Verwechslung: Der Angreifer nimmt einen öffentlichen Schlüssel – der per Definition öffentlich ist – ändert den Header in „HS256“ und signiert das Token mit diesem öffentlichen Schlüssel als HMAC-Geheimnis. Ein Verifizierer, der den Algorithmus aus dem Token liest und nach „dem Schlüssel“ sucht, validiert ihn.

Beide Angriffe basieren auf demselben Fehler: Der Token sagt dem Verifizierer, wie er den Token überprüfen soll. Ein korrekter Prüfer ignoriert den Algorithmus des Headers und verwendet den, mit dem er konfiguriert wurde. Das ist eine Entscheidung des Systems, das dem Token vertraut – nicht einem praktischen Tool und nicht demjenigen, der etwas in ein Formular eingefügt hat.

Warum Produktionstoken nicht irgendwo einfügen?

Ein Zugriffstoken ist ein Inhabernachweis. Das bedeutet "bearer" im Authorization-Header: Wer es trägt, sind Sie. Es gibt keinen zweiten Faktor und normalerweise keine Möglichkeit, einen gestohlenen Token von einem legitimen zu unterscheiden. Bis zu seinem Ablauf ist er ein funktionierender Schlüssel für Ihr Konto.

Das Einfügen eines Live-Tokens in eine beliebige Webseite bedeutet also, dass dieser Seite ein Berechtigungsnachweis übergeben wird. Dieser dekodiert alles lokal und stellt nach dem Laden der Seite keine Netzwerkanfrage – Sie können dies im Netzwerkfenster Ihres Browsers bestätigen, und das sollten Sie auch, denn es dauert zehn Sekunden. Aber beachten Sie, was dieses Argument eigentlich ist: eine Behauptung auf einer Website, dass die Website vertrauenswürdig ist. Jede Website, die Token exfiltriert, erhebt genau die gleiche Behauptung, und ein Besucher kann den Unterschied nicht auf den ersten Blick erkennen.

Die sichere Gewohnheit hängt nicht von der korrekten Beurteilung von Websites ab. Verwenden Sie abgelaufene Token, Testumgebungs-Token oder Token, die Sie zu diesem Zweck geprägt haben. Wenn Sie irgendwo – irgendwo – bereits einen Produktionsmarker eingefügt haben, drehen Sie ihn. Ein Widerruf ist günstig; ein Vorfall ist es nicht.

Das Gleiche gilt mit größerer Kraft auch für Signierschlüssel. Es gibt keinen legitimen Grund, ein HMAC-Geheimnis oder einen privaten Schlüssel in eine Webseite einzugeben, und jede Website, die nach einem "verify" Ihres Tokens fragt, verlangt nach der Möglichkeit, Token zu fälschen. Das ist der konkrete Grund, warum dieses Tool keine Verifizierungsfunktion hat: Die Funktion erfordert die Anfrage.

Lesen Sie die Behauptungen, auf die es ankommt

RFC 7519 registriert einen kleinen Satz von Anspruchsnamen. „iss“ ist der Aussteller, „sub“ der Betreff des Tokens, „aud“ die beabsichtigte Zielgruppe, „exp“ der Ablauf, „nbf“ der früheste gültige Zeitpunkt, „iat“ der Ausgabezeitpunkt und „jti“ eine eindeutige ID zur Wiederholungserkennung. Alles andere ist anwendungsspezifisch.

Die Zeitangaben sind NumericDate-Werte: Sekunden seit der Unix-Epoche, nicht Millisekunden. Dies bringt die Leute ständig aus der Fassung, da die meisten JavaScript-Zeitwerte Millisekunden sind. Einem Token, das in 1970 abzulaufen scheint, wurde normalerweise ein Millisekundenwert zugewiesen; einer, der im Jahr 55000 abzulaufen scheint, hatte normalerweise irgendwo einen zweiten Wert, multipliziert mit 1000.

"aud" verdient beim Debuggen besondere Aufmerksamkeit. Ein vollkommen gültiger Token kann dennoch der falsche Token sein, weil er für ein anderes Publikum ausgegeben wurde. Ein Verifizierer, der die Signatur, aber nicht die Zielgruppe überprüft, akzeptiert ein Token, das vollständig für einen anderen Dienst erstellt wurde – was in Systemen, die einen Identitätsanbieter gemeinsam nutzen, ein echter Weg zur Rechteausweitung ist.

Dieses Tool stellt die Zeitansprüche in UTC dar, markiert einen abgelaufenen Token als abgelaufen und verknüpft dies mit einer Erinnerung, dass der Ablaufanspruch nur dann eine Bedeutung hat, wenn die Signatur gültig ist. Die Erinnerung ist da, weil „es heißt, es sei nicht abgelaufen“ genau der Moment ist, in dem die Gewohnheit, nicht überprüfte Daten zu verwenden, ihren Schaden anrichtet.

Eine kurze Checkliste für das System, das die Vertrauensstellung durchführt

Wenn Sie den Code schreiben, der Token akzeptiert, anstatt nur eines zu überprüfen, finden Sie im Folgenden die Kurzversion dessen, was ein korrekter Verifizierer tut.

Überprüfen Sie zunächst die Signatur mit einem Schlüssel, den Sie außerhalb des Bandes erhalten haben, bevor Sie einen Anspruch lesen.
Pinnen Sie den Algorithmus in Ihrer eigenen Konfiguration. Lesen Sie es niemals aus dem Token-Header. "none" bedingungslos ablehnen.
Vergleichen Sie „exp“ und „nbf“ mit einer vertrauenswürdigen Uhr, mit höchstens einer kleinen Abweichungstoleranz.
Vergleichen Sie „iss“ und „aud“ mit den erwarteten Werten. Eine gültige Signatur auf einem Token, der für jemand anderen bestimmt ist, ist immer noch der falsche Token.
Verwenden Sie eine geprüfte Bibliothek für Ihre Plattform, anstatt diese selbst zusammenzustellen. Jeder Punkt auf dieser Liste steht darauf, weil die Implementierungen einen Fehler gemacht haben.
Halten Sie die Token-Lebensdauer kurz und verfügen Sie über einen Widerrufspfad. Kurzlebige Token begrenzen den Schaden des Lecks, den Sie noch nicht bemerkt haben.

Was passiert mit dem, was Sie einfügen?

Jede Konvertierung, jeder Hash, jede Dekodierung und jeder Diff wird in Ihrem Browser-Tab ausgeführt. Es werden keine Eingaben hochgeladen, protokolliert oder auf einem Server gespeichert, da nach dem Laden der Seite kein Server beteiligt ist.
Hashes stammen von der browsereigenen Web Crypto-Implementierung und UUIDs von seinem kryptografisch sicheren Zufallsgenerator. Bei beiden handelt es sich nicht um einen Netzwerkanruf.
Nichts, was Sie eingeben, wird in den lokalen Speicher oder in ein Cookie geschrieben. Beim Neuladen der Seite wird diese verworfen; Wenn Sie die Registerkarte schließen, wird sie verworfen.
Siteweite Analysen laufen nur auf dem konfigurierten kanonischen Produktionshost und werden in der Datenschutzrichtlinie offengelegt; Lokale und Vorschau-Hosts lehnen dies ab. Eingefügte Werte, Token, URLs und Dateiinhalte sind von den eigenen Analyseereignissen von ToolAcre ausgeschlossen. Werbung ist in der aktuellen Konfiguration deaktiviert.
Das heißt: Ein JWT oder ein API-Schlüssel ist ein Live-Zugangsdatensatz. Es ist eine sichere Angewohnheit, niemals etwas in eine Webseite einzufügen, die Sie nicht geschrieben haben, egal wie vertrauenswürdig die Behauptungen sind – auch diese hier.

Fragen

Verifiziert dieses Tool die Signatur?

Nein, und das wird es auch nie. Es dekodiert den Header und die Nutzlast und zeigt Ihnen, was sie enthalten. Die Signatur wird nicht überprüft, sodass nichts, was angezeigt wird, beweist, dass das Token authentisch, unverändert oder von der benannten Person ausgestellt ist.

Woher weiß ich dann, dass ein Token echt ist?

Durch die Überprüfung der Signatur mit dem Schlüssel des Ausstellers unter Verwendung einer geprüften Bibliothek, wobei der Algorithmus in Ihrer eigenen Konfiguration verankert ist und nicht vom Token gelesen wird. Das ist Arbeit für den Dienst, der dem Token vertraut, und zwar in einer Umgebung, die den Schlüssel rechtmäßig besitzt.

Wird mein Token irgendwohin gesendet, wenn ich es hier entschlüssele?

Nein. Die Dekodierung erfolgt in Ihrem Browser-Tab mithilfe des eigenen JavaScript der Seite und die Seite stellt nach dem Laden keine Netzwerkanfragen. Sie können dies im Netzwerkfenster Ihres Browsers überprüfen. Sie sollten Produktions-Tokens dennoch nicht aus Gewohnheit in Web-Tools einfügen, denn diese Gewohnheit muss auf Websites funktionieren, die nicht ehrlich damit umgehen.

Warum kann jemand meine JWT-Nutzlast lesen?

Weil die Nutzlast base64-URL-codiert und nicht verschlüsselt ist. Ein JWS ist eine unterschriebene Erklärung, keine versiegelte. Wenn der Inhalt unlesbar sein soll, benötigen Sie JWE, das verschlüsselte Token-Format – und dann kann Ihnen ein Decoder ohne den Schlüssel überhaupt nichts anzeigen.

Was ist alg: "none"?

Ein Headerwert, der angibt, dass das Token nicht signiert ist. Es existiert in der Spezifikation für Kontexte, in denen die Integrität auf andere Weise garantiert wird, und es ist eine ständige Falle: Ein Verifizierer, der dem Algorithmus des Headers vertraut, akzeptiert jedes Token, das "none" beansprucht. Dieses Tool markiert es, wann immer es erscheint.

Mein Token hat fünf Segmente und lässt sich nicht entschlüsseln. Warum?

Fünf Segmente bedeuten ein JWE – ein verschlüsseltes Token – und nicht ein signiertes JWS. Der Inhalt kann ohne den Entschlüsselungsschlüssel nicht gelesen werden, sodass ein Decoder wirklich nichts anzeigen kann. Dieses Tool identifiziert diesen Fall explizit, anstatt einen vagen Analysefehler zu melden.

Der Ablauf sieht um den Faktor 1000 falsch aus.

JWT-Zeitansprüche sind NumericDate: Sekunden seit der Epoche, nicht Millisekunden. Ein von Date.now() erzeugter Wert ist tausendmal zu groß. Das Zeitstempel-Dienstprogramm in diesem Toolkit konvertiert zwischen den beiden und teilt Ihnen immer mit, welche Einheit verwendet wurde.

Ist es sicher, ein JWT in localStorage zu speichern?

Es ist ein Kompromiss, kein Ja oder Nein. localStorage kann von jedem auf Ihrem Ursprung ausgeführten JavaScript gelesen werden, sodass das Token durch eine einzelne XSS-Schwachstelle herausgefiltert wird. Ein httpOnly-Cookie ist für JavaScript nicht lesbar, benötigt jedoch CSRF-Schutz. Die ehrliche Zusammenfassung ist, dass beides nicht kostenlos ist und die Entscheidung vom Bedrohungsmodell Ihrer Anwendung abhängt.

Einschränkungen

Dieses Tool dekodiert nur. Es werden keine Signaturen überprüft, und das ist eine dauerhafte Entwurfsentscheidung und keine fehlende Funktion – warum das so ist, erfahren Sie in der Anleitung oben.
Verschlüsselte Token (JWE, fünf Segmente) können ohne den Schlüssel überhaupt nicht entschlüsselt werden. Das Tool erkennt sie und stoppt.
Verschachtelte JWTs – ein Token, dessen Nutzlast selbst ein Token ist – werden nicht automatisch entpackt. Dekodieren Sie das innere Token als separaten Schritt.
Anspruchsbedeutungen, die über den in RFC 7519 definierten registrierten Satz hinausgehen, sind anwendungsspezifisch, sodass das Tool ihre Werte anzeigt, ohne sie zu interpretieren.
Ein hier angezeigter Ablauf spiegelt nur wider, was der Token über sich selbst behauptet. Ob dieser Anspruch sinnvoll ist, hängt von einer Signatur ab, die dieses Tool nicht überprüft.
Token mit mehr als 200,000 Zeichen werden abgelehnt. Jedes echte JWT ist um Größenordnungen kleiner.