Entwicklertools · JWT Decoder
So dekodieren Sie eine JWT-Nutzlast manuell mit base64 und jq
· Wie es funktioniert
jwt Befehlszeile Entwickler-Workflow
Auf einer Headless-Box kann man immer noch einen Token mit cut, tr, base64 und jq lesen. In diesem Beitrag werden die Befehle erläutert, die jeweils durchgeführte Base64URL-Konvertierung erläutert und die Fallstricke aufgeführt.
Lesen eines Tokens über SSH – wenn ein Browser keine Option ist
Ein Headless-Server hinterlässt möglicherweise eine tokenförmige Zeichenfolge und keine Browser-Benutzeroberfläche. Der erforderliche Inspektionsaufwand ist noch gering: Isolieren eines Segments, Übersetzen der Base64-URL-Schreibweise, Wiederherstellen der Auffüllung, Dekodieren von Bytes und Analysieren von JSON. Die Gefahr ist eher betrieblicher als rechnerischer Natur, da der Shell-Verlauf einen aktiven Berechtigungsnachweis bewahren kann.
Verwenden Sie nach Möglichkeit ein abgelaufenes oder synthetisches Token. Wenn die Reaktion auf einen Vorfall die Untersuchung eines echten Werts erfordert, befolgen Sie die Kontrollen Ihrer Organisation zum Umgang mit Anmeldeinformationen, verhindern Sie, dass diese in den gemeinsamen Verlauf oder in Protokolle gelangen, und rotieren Sie sie nach der Offenlegung. Die Dekodierung über die Befehlszeile bleibt nur der Inspektion vorbehalten; Es stellt keinen Verifizierungsschlüssel oder eine Vertrauensrichtlinie bereit.
Aufteilung nach Punkten – schneiden oder awk, um das Nutzlastsegment zu isolieren
Ein kompakter JWS-förmiger JWT hat drei durch Punkte getrennte Felder. Die Nutzlast ist die zweite. Eine Shell kann es mit einem Trennzeichen-fähigen Tool teilen, aber Variablen in Anführungszeichen setzen, damit die Shell Zeichen nicht erweitert oder Leerzeichen teilt. Entfernen Sie die führende Bezeichnung `Bearer `, bevor Sie Felder auswählen, da dieses Präfix zur HTTP-Syntax gehört.
Zählen Sie die Felder, anstatt blind Feld zwei zu nehmen. ToolAcre lehnt alles andere als drei Teile ab und identifiziert fünfteilige verschlüsselte Eingaben separat. Bei einer Shell-Pipeline sollten die gleichen strukturellen Vorsichtsmaßnahmen getroffen werden. Der Empfang eines Segments aus einer fehlerhaften Eingabe kann plausibles JSON erzeugen und gleichzeitig verbergen, dass das ursprüngliche Token abgeschnitten wurde.
Konvertieren des Alphabets – tr, um Bindestrich und Unterstrich wieder in Plus und Schrägstrich umzuwandeln
Standardmäßige Base64-Befehlszeilenimplementierungen erwarten üblicherweise Pluszeichen und Schrägstriche, wobei ein JWT-Segment Bindestriche und Unterstriche enthalten kann. Die Übersetzung von `-` in `+` und `_` in `/` ordnet die URL-sicheren Symbole wieder ihren Standardpositionen zu, ohne die dargestellten Sechs-Bit-Werte zu ändern.
Verwenden Sie einen Übersetzungsbefehl, dessen Optionsanalyse einen führenden Bindestrich nicht mit einem Flag verwechseln kann, und behalten Sie die Daten in einer in Anführungszeichen gesetzten Variablen oder einer Standardeingabe bei. Die Alphabetkonvertierung ist eine reversible Codierungsarbeit. Die Ansprüche werden nicht entschlüsselt, und ein Erfolg beweist nicht, dass der Token vom genannten Emittenten stammt.
Wiederherstellen der Auffüllung – die Arithmetik, die die richtige Anzahl von Gleichheitszeichen hinzufügt
Berechnen Sie nach der Übersetzung die Länge modulo vier. Für den Rest Null sind keine Gleichheitszeichen erforderlich, für den Rest zwei sind zwei erforderlich und für den Rest drei ist eins erforderlich. Der Rest eins weist auf eine Kürzung hin und sollte die Pipeline stoppen. Das Anhängen willkürlicher Auffüllungen, bis ein Dienstprogramm aufhört, sich zu beschweren, kann Schäden eher verbergen als diagnostizieren.
ToolAcre verwendet genau diese Längenregel in `base64ToBytes` und lehnt den unmöglichen Rest ab. Shell-Dienstprogramme unterscheiden sich darin, ob sie weggelassene Auffüllungen akzeptieren. Wenn Sie also zunächst die Eingabe normalisieren, wird die Pipeline im Konzept explizit und portierbar, obwohl sich die Befehlsflags zwischen den Betriebssystemen dennoch unterscheiden können.
Dekodierung und Pretty-Printing – base64 -d in jq weitergeleitet
Leiten Sie den aufgefüllten Wert an den Base64-Decoder der Plattform und dann an `jq` weiter. Der erste Befehl stellt Bytes wieder her; Die zweite erfordert, dass diese Bytes JSON bilden. Ein erfolgreicher Base64-Befehl, gefolgt von einem jq-Parse-Fehler, bedeutet, dass die Codierung strukturell decodierbar war, ihr Inhalt jedoch keine JSON-Nutzlast war.
Diese Unterscheidung spiegelt die Fehlerpfade von ToolAcre wider. Es meldet zunächst eine ungültige Base64-URL oder UTF-8, dann separat eine ungültige JSON und lehnt dann Null, Arrays und Grundelemente ab, da ein JWT-Header oder eine Nutzlast ein Objekt für dieses Tool sein muss. Durch die Trennung der Phasen wird ein Fehler strafbar.
Arbeitsbeispiel – die vollständige Pipeline auf einem Beispieltoken, mit der Ausgabe in jeder Phase
Für ein synthetisches Beispiel benötigt das Nutzlastsegment `eyJzdWIiOiJkZW1vIiwicm9sZSI6InJlYWRlciJ9` keine alphabetische Übersetzung oder Auffüllung. Die Dekodierung ergibt `{"sub":"demo","role":"reader"}` und jq-Formate, die zeilenübergreifend widersprechen. Die sichtbare Rolle ist lediglich eine vom Token bereitgestellte Zeichenfolge.
Ändern Sie nun den JSON, kodieren Sie ihn erneut und hängen Sie ein beliebiges drittes Segment an. Die Pipeline druckt weiterhin das geänderte Objekt. Dies beweist, warum ein Dekodierbefehl nicht als Gültigkeitsprüfung dienen kann: Sowohl legitime als auch erfundene Ansprüche durchlaufen dieselben öffentlichen Transformationen, es sei denn, ein separater Verifizierer überprüft die Signatur.
Fallstricke – Shell-Verlauf, der das Token erfasst, Base64-Implementierungen, die fehlende Auffüllungen ablehnen, und Token mit einem führenden „Bearer“
Zu den häufigsten Fehlern gehören die Beibehaltung des HTTP-Präfixes, die Auswahl des falschen durch Punkte getrennten Felds, der Verlust von nachgestellten Zeichen beim Kopieren und die Verwendung einer Base64-Implementierung, die Auffüllen erfordert. Eine weitere Gefahr besteht darin, das gesamte Token direkt in der Befehlszeile zu platzieren, wo es in Prozesslisten oder im Verlauf gespeichert werden kann.
Bevorzugen Sie Standardeingaben und kurzlebige Variablen unter entsprechenden Kontrollen und fügen Sie der Einfachheit halber niemals einen Produktionstoken in Chat, Tickets oder gemeinsam genutzte Terminals ein. Denken Sie auch daran, dass es sich beim dritten Segment um binäres Signaturmaterial und nicht um JSON handelt. Daher sollte das Senden über jq fehlschlagen und Ihnen nichts über die Gültigkeit der Signatur sagen.
Takeaway: Die gleiche Dekodierung, jede Umgebung – wenn Sie einen Browser haben, führt der ToolAcre JWT-Decoder dies lokal durch, ohne dass etwas hochgeladen wird
Die Shell-Pipeline und ToolAcre führen dieselbe Nur-Dekodierungs-Sequenz in unterschiedlichen Umgebungen aus: Teilen, Normalisieren, Auffüllen, Dekodieren von UTF-8 und Analysieren von JSON. Verwenden Sie jede Umgebung, die Sie überprüfen und steuern können, mit nicht vertraulichen Daten als Standard.
Keiner der Pfade überprüft die Authentizität oder autorisiert einen Anrufer. Wechseln Sie nach dem Lesen der Nutzlastform zum vertrauenswürdigen Verifizierer und zu den Protokollen des Dienstes, um kryptografische und Richtlinienentscheidungen zu treffen. Ein Befehl, der hübsches JSON erzeugt, hat eine Formatierungsaufgabe abgeschlossen, keine Sicherheitsbeurteilung.