JWT-Schwachstellen
Was ist JWT-Schwachstellen?
JWT-SchwachstellenKlassen von Implementierungsfehlern bei der Validierung von JSON Web Tokens, die es Angreifern erlauben, Tokens zu fälschen, Rechte auszuweiten oder die Authentifizierung zu umgehen.
JSON Web Tokens transportieren Ansprüche zur Authentifizierung und Autorisierung, doch die Flexibilität ihres im Header deklarierten Signaturalgorithmus hat mehrere wiederkehrende Schwachstellenklassen hervorgebracht. Der alg=none-Fehler, 2015 von Tim McLean offengelegt, tritt auf, wenn ein Verifier dem alg-Header des Tokens selbst vertraut und an einen „none"-Verifier weiterleitet, der bei einer leeren Signatur true zurückgibt – wodurch ein Angreifer die Payload umschreiben und die Signatur weglassen kann. Er wurde in Nodes jsonwebtoken vor Version 4.2.2 behoben (CVE-2015-9235).
Key Confusion (CVE-2016-10555) ist subtiler: Akzeptiert ein Server sowohl RS256 als auch HS256, signiert ein Angreifer ein Token per HMAC und nutzt dabei den öffentlichen RSA-Schlüssel des Servers als gemeinsames Secret; ein naiver Verifier reicht diesen öffentlichen Schlüssel an HS256.verify() weiter, und die Fälschung geht durch. Verwandte Probleme sind schwache HS256-Secrets, die sich offline mit hashcat knacken lassen, fehlende exp/nbf-Prüfungen sowie Header-Injection-Sinks – kid-Path-Traversal oder SQL-Injection und vom Angreifer kontrollierte jwk/jku/x5u-Felder, die die Verifikation auf einen Schlüssel lenken, den der Angreifer besitzt. 2022 warf CVE-2022-23529 in jsonwebtoken RCE-Bedenken über ein manipuliertes Key-Objekt auf (später zurückgezogen, nachdem die Voraussetzungen für den Exploit angezweifelt wurden).
Gegenmaßnahmen: Legen Sie die akzeptierten Algorithmen serverseitig fest und lesen Sie alg niemals aus nicht vertrauenswürdiger Eingabe, verwenden Sie starke asymmetrische Schlüssel, validieren Sie kid gegen eine Allowlist, ignorieren Sie eingebettete Schlüssel-URLs, erzwingen Sie den Ablauf und behandeln Sie jedes JWT-Feld als feindliche Eingabe.
flowchart TD
A[Angreifer erhält gültiges JWT] --> B{Header manipulieren}
B -->|alg none, Signatur weglassen| C[Verifier überspringt Prüfung?]
B -->|RS256 zu HS256| D[HMAC mit öffentlichem Schlüssel]
B -->|jku / kid zeigt auf Angreifer-Schlüssel| E[Prüfung gegen fremden Schlüssel]
C -->|Ja| F[Gefälschtes Token akzeptiert]
D -->|Ja| F
E -->|Ja| F
F --> G[Rechteausweitung / Auth-Umgehung]
C -->|Fixierter alg| H[Abgelehnt]
D -->|Fixierter alg| H
E -->|Allowlist kid| H● Beispiele
- 01
Header {"alg":"none"}, der von einer fehlerhaft konfigurierten Bibliothek akzeptiert wird.
- 02
Server validiert ein RS256-Token mit seinem öffentlichen Schlüssel als HS256-HMAC-Secret.
● Häufige Fragen
Was ist JWT-Schwachstellen?
Klassen von Implementierungsfehlern bei der Validierung von JSON Web Tokens, die es Angreifern erlauben, Tokens zu fälschen, Rechte auszuweiten oder die Authentifizierung zu umgehen. Es gehört zur Kategorie Anwendungssicherheit der Cybersicherheit.
Was bedeutet JWT-Schwachstellen?
Klassen von Implementierungsfehlern bei der Validierung von JSON Web Tokens, die es Angreifern erlauben, Tokens zu fälschen, Rechte auszuweiten oder die Authentifizierung zu umgehen.
Wie schützt man sich gegen JWT-Schwachstellen?
Schutzmaßnahmen gegen JWT-Schwachstellen kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.