JWT im Detail: Token-Sicherheit, Schwachstellen und Best Practices

JSON Web Tokens (JWTs) sind der De-facto-Standard für zustandslose Authentifizierung in modernen Webanwendungen. Ihre Flexibilität führt jedoch immer wieder zu fatalen Fehlkonfigurationen. Wenn wir als Penetrationstester ein JWT sehen, sehen wir nicht einfach einen Session-Identifier – wir sehen eine kryptografische Angriffsfläche.

Anatomie eines JWT: Header, Payload und Signature

Ein JWT besteht aus drei Teilen: einem Header, einem Payload und einer Signature, jeweils getrennt durch einen Punkt (.). Für Pentester sieht ein abgefangenes JWT zunächst nach einer langen Folge scheinbar zufälliger Zeichen aus. Hier ein Beispiel aus der Praxis:

eyJraWQiOiI5MTM2ZGRiMy1jYjBhLTRhMTktYTA3ZS1lYWRmNWE0NGM4YjUiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJwb3J0c3dpZ2dlciIsImV4cCI6MTY0ODAzNzE2NCwibmFtZSI6IkNhcmxvcyBNb250b3lhIiwic3ViIjoiY2FybG9zIiwicm9sZSI6ImJsb2dfYXV0aG9yIiwiZW1haWwiOiJjYXJsb3NAY2FybG9zLW1vbnRveWEubmV0IiwiaWF0IjoxNTE2MjM5MDIyfQ.SYZBPIBg2CRjXAJ8vCER0LA_ENjII1JakvNQoP-Hw6GG1zfl4JyngsZReIfqRvIAEi5L4HV0q7_9qGhQZvy9ZdxEJbwTxRs_6Lb-fZTDpW6lKYNdMyjw45_alSCZ1fypsMWz_2mTpQzil0lOtps5Ei_z7mM7M8gCwe_AGpI53JxduQOaB5HkT5gVrv9cKu9CsW5MS6ZbqYXpGyOG5ehoxqm8DL5tFYaW3lB50ELxi0KsuTKEbD0t5BCl0aCR2MBJWAbN-xeLwEenaqBiwPVvKixYleeDQiBEIylFdNNIMviKRgXiYuAvMziVPbwSgkZVHeEdF5MQP1Oe2Spac-6IfA

Header und Payload sind lediglich Base64Url-kodierte JSON-Objekte. Sie sind nur kodiert, nicht verschlüsselt. Jeder, der Zugriff auf das Token hat, kann diese Daten dekodieren und lesen.

Die JWT-Struktur visualisiert

Ein JWT (technisch gesehen ein JWS – ein JSON Web Token „im signierten Zustand“) setzt sich aus drei durch Punkte getrennten Abschnitten zusammen: Header.Payload.Signature.

{ "alg": "HS256", "typ": "JWT" }

{ "sub": "andrej", "role": "hacker" }

HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    "secret"
) = MmM0ZGMxM2Y1NWQ2YTY2YTE

Der Header

Der Header enthält Metadaten über das Token selbst, vor allem den Token-Typ und den kryptografischen Algorithmus, mit dem es abgesichert wurde. Dekodiert man den ersten Teil des obigen Tokens, erhält man:

{
    "kid": "9136ddb3-cb0a-4a19-a07e-eadf5a44c8b5",
    "alg": "RS256"
}

Der Payload

Der Payload enthält die eigentlichen „Claims“ über den Benutzer. Er ist das primäre Ziel für Manipulationen während eines Security-Assessments. Der mittlere Abschnitt unseres Beispiels dekodiert zu:

{
    "iss": "portswigger",
    "exp": 1648037164,
    "name": "Andrej Šebeň",
    "sub": "andrej",
    "role": "pentester",
    "email": "[email protected]",
    "iat": 1516239022
}

Die Signature

Da Header und Payload von jedem problemlos gelesen oder verändert werden können, hängt die Sicherheit jedes JWT-basierten Mechanismus maßgeblich an der kryptografischen Signature.

Der ausstellende Server bildet einen Hash über den Base64Url-kodierten Header und Payload und verwendet dafür einen geheimen Signaturschlüssel. Dieser Mechanismus garantiert zwei Dinge:

1. Da sich die Signature direkt aus dem restlichen Token ableitet, führt schon die Änderung eines einzigen Bytes im Header oder Payload zu einer nicht mehr passenden Signature.
2. Ohne Kenntnis des geheimen Signaturschlüssels des Servers sollte es nicht möglich sein, für einen gefälschten Header oder Payload die korrekte Signature zu erzeugen.

Wonach Angreifer in einem JWT suchen

Da JWTs von Haus aus lesbar sind, behandeln Angreifer sie nicht als verschlüsselte Daten, sondern als wertvolle Quelle für die Aufklärung. Aus offensiver Sicht liegen die logischen Schwachstellen meist im Payload. Diese kritischen Claims sehen wir uns als Erstes an:

Payload-Aufklärung: die Fundgrube für Information Disclosure

Da der Payload für jeden sichtbar ist, der das Token besitzt, sollten Entwickler ihn als öffentliche Information behandeln. In Assessments finden wir regelmäßig unnötige interne Details, die über eigene Claims nach außen gelangen:

• Abbild des internen Netzwerks: eigene Claims wie "node_ip": "10.0.4.12", "cluster": "prod-us-east-1a" oder "db_host": "internal-db.local" verraten interne Netzarchitektur und IP-Bereiche.
• Rückschlüsse auf Framework und Identity Provider: Die Namenskonventionen der Claims verraten den zugrunde liegenden Tech-Stack. Claims wie http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name deuten auf ein Microsoft-.NET-/Entra-ID-Backend hin und erlauben uns, gezielt stack-spezifische Schwachstellen anzugreifen.
• Personenbezogene Daten (PII): unnötige Offenlegung von E-Mail-Adressen, Telefonnummern, vollständigen Namen oder Anschriften – ein unmittelbarer Compliance-Verstoß (DSGVO / CCPA).
• Enumeration von Mandanten und Rollen: Claims wie "tenant_id": "uuid", "is_god_mode": false oder "permissions": ["read:profile"] legen das Autorisierungsschema offen und liefern uns die exakten Parameternamen für die Rechteausweitung.

Ein Beispiel für einen zu gesprächigen JWT-Payload aus der Praxis:

{
  "iss": "auth.internal-corp.local",
  "sub": "usr_99812",
  "email": "[email protected]",
  "role": "admin",
  "internal_ip": "10.240.12.88",
  "db_shard": "shard-04-eu",
  "is_admin": true,
  "exp": 1748037164
}

Bearer Tokens vs. Refresh Tokens: Architektur und Speicherung

Eine sichere JWT-Implementierung beruht auf einem Zwei-Token-System: kurzlebige Access Tokens (Bearer Tokens) und langlebige Refresh Tokens. Deren falsche Speicherung ist die mit Abstand häufigste Schwachstelle, die wir berichten.

Bearer Tokens (Access Tokens)

• Access Tokens autorisieren API-Anfragen und sind bewusst kurzlebig – typischerweise zwischen 5 und 15 Minuten.
• Speichern Sie sie ausschließlich im Arbeitsspeicher der Anwendung. Verzichten Sie auf localStorage und sessionStorage, denn jede erfolgreiche XSS-Schwachstelle legt sie einem Angreifer offen.

Refresh Tokens

• Refresh Tokens dienen einzig dazu, nach dem Ablauf neue Access Tokens zu beziehen.
• Sie gehören in HttpOnly-, Secure- und SameSite-Cookies. Das verhindert den Zugriff durch JavaScript, reduziert Token-Diebstahl über XSS erheblich und hilft zugleich, CSRF abzuschwächen.

Das Playbook des Pentesters: gängige JWT-Exploits

Beim Audit einer Webanwendung arbeiten Penetrationstest-Teams üblicherweise die folgenden Angriffsvektoren ab.

A. Fehler bei der Signaturprüfung

Viele JWT-Schwachstellen entstehen nicht durch gebrochene Kryptografie, sondern durch eine unsaubere Signaturprüfung. Historisch akzeptierten einige Bibliotheken den none-Algorithmus, sodass Angreifer die Signature vollständig entfernen und dabei Claims wie Benutzerrollen beliebig verändern konnten. Alle großen modernen Bibliotheken lehnen none standardmäßig ab, doch in Legacy-Anwendungen und selbst gebauten JWT-Implementierungen taucht dieser Fehler weiterhin auf – ein Test lohnt sich immer dann, wenn Sie auf einen nicht standardisierten Stack treffen.

Ein weiterer Klassiker ist Algorithm Confusion. Das ist eine der folgenschwersten JWT-Schwachstellen überhaupt, und es lohnt sich, sie genau zu verstehen.

• RS256 ist ein asymmetrisches Verfahren. Der Server signiert Tokens mit seinem privaten Schlüssel und verifiziert sie mit dem zugehörigen öffentlichen Schlüssel. Der öffentliche Schlüssel ist häufig frei verfügbar – etwa über einen /.well-known/jwks.json-Endpunkt.
• HS256 ist ein symmetrisches Verfahren. Der Server nutzt ein einziges gemeinsames Secret, um Tokens sowohl zu signieren als auch zu prüfen.

Der Angriff nutzt aus, was passiert, wenn ein Server beide Algorithmen akzeptiert, ohne den erwarteten Algorithmus explizit fest vorzugeben:

1. Der Angreifer beschafft sich den öffentlichen Schlüssel des Servers – oft trivial über den JWKS-Endpunkt.
2. Er verändert den Token-Payload, zum Beispiel von "role": "user" auf "role": "admin".
3. Er ändert den Header von "alg": "RS256" auf "alg": "HS256".
4. Er signiert das gesamte veränderte Token (Header und Payload) neu und verwendet dabei den öffentlichen Schlüssel als HS256-Secret.
5. Der Server erhält das Token, sieht alg: HS256 und verifiziert es mit dem öffentlichen Schlüssel als HMAC-Secret. Die Prüfung geht auf, und das gefälschte Token wird akzeptiert.

Die Ursache ist keine gebrochene Kryptografie, sondern ein Server, der dem vom Client gelieferten alg-Header blind vertraut, wenn es darum geht, wie das Token zu prüfen ist. Normalerweise würde eine Änderung von alg im Header die Signature ungültig machen, denn diese deckt Header und Payload ab. Der Angreifer signiert jedoch das gesamte veränderte Token neu, sodass die neue Signature unter dem umgestellten Algorithmus einwandfrei gültig ist.

Moderne Bibliotheken haben diese Fehler weitgehend beseitigt, in Legacy-Anwendungen und selbst gebauten JWT-Implementierungen treten sie jedoch nach wie vor auf.

B. Schwache Signaturschlüssel

Anwendungen, die symmetrische Verfahren wie HS256 einsetzen, sind nur so sicher wie das Secret, mit dem das Token signiert wird.

Bei einem Penetrationstest lässt sich ein abgefangenes JWT vollständig offline mit Werkzeugen wie Hashcat oder John the Ripper angreifen. Schwache Secrets wie Firmennamen, Wörterbuchbegriffe oder vorhersehbare Phrasen fallen oft innerhalb von Minuten. Danach kann ein Angreifer gültige Tokens für jeden beliebigen Benutzer erzeugen, ohne je wieder mit der Zielanwendung interagieren zu müssen.

C. Injection über Header-Parameter

JWT-Header können optionale Parameter wie kid (Key ID) und jku (JWK Set URL) enthalten, die dem Server dabei helfen, den für die Prüfung passenden Schlüssel zu bestimmen. Da diese Werte vom Client geliefert werden, kann blindes Vertrauen ohne saubere Validierung schwerwiegende Schwachstellen eröffnen.

Zu den gängigen Angriffsvektoren zählen:

• die Manipulation des jku-Parameters, um auf einen vom Angreifer kontrollierten JWKS-Endpunkt zu verweisen;
• Directory Traversal über den kid-Parameter, wenn Schlüssel direkt aus dem Dateisystem geladen werden;
• SQL-Injection, wenn der kid-Wert in Datenbankabfragen zusammengesetzt wird.

Ausgereifte JWT-Bibliotheken behandeln diese Szenarien sicher, selbst geschriebene Prüflogik liefert dagegen weiterhin Findings in Security-Assessments.

D. Fehler bei der Claim-Validierung

Eine gültige Signature bedeutet nicht automatisch, dass einem Token vertraut werden darf. Jeder sicherheitsrelevante Claim muss zusätzlich von der Anwendung validiert werden.

In Pentests begegnen uns regelmäßig APIs, die:

• abgelaufene Tokens akzeptieren, weil der exp-Claim ignoriert wird;
• die vorgesehene Audience (aud) nicht prüfen, sodass Tokens dienstübergreifend wiedereingespielt werden können;
• beliebigen Issuer-Werten (iss) vertrauen;
• sich allein auf clientseitig kontrollierte Claims wie role, tenant oder permissions verlassen, ohne die Autorisierung serverseitig durchzusetzen.

Diese Logikfehler haben in der Praxis oft größere Auswirkungen als kryptografische Schwächen, weil sie es erlauben, legitime Tokens auf nicht vorgesehene Weise einzusetzen.

Moderne Werkzeuge für JWT-Sicherheitstests

Base64 von Hand zu dekodieren und Signaturen manuell zu manipulieren, ist ineffizient. Pentester setzen auf spezialisierte Werkzeuge, um diese Angriffe zu automatisieren:

• JWTAuditor: eine ausgezeichnete, vollständig clientseitige Testplattform, die auf Pentester zugeschnitten ist. Sie ermöglicht die schnelle Analyse von Tokens, die automatisierte Erkennung von Schwachstellen (etwa Tests auf den none-Algorithmus oder Header-Injection) sowie Offline-Brute-Force, ohne sensible Kunden-Tokens der Telemetrie Dritter auszusetzen.
• Burp Suite (Erweiterung JWT Editor): kommt im dynamischen Webtest intensiv zum Einsatz, um Tokens beim Abfangen im HTTP-Proxy direkt zu manipulieren.
• JWT.io: wird von Auth0 gepflegt und ist das Standardwerkzeug, um Tokens schnell manuell zu dekodieren und in der ersten Aufklärungsphase Strukturen und Signaturen zu prüfen.
• JWTLens: eine schlanke, datenschutzfreundliche Alternative zur Token-Analyse. Sie dekodiert und verifiziert Tokens vollständig im Browser über die native Web Crypto API – Ihre Tokens und Schlüssel verlassen Ihren Rechner also nie. Da bei der Prüfung keinerlei Netzwerkanfragen stattfinden, ist das Werkzeug ideal, um Algorithmen und Signaturen sicher zu validieren.

Praktische Best Practices für die Verteidigung

Damit Ihre Anwendung nicht auf der Liste der kritischen Findings eines Pentest-Berichts landet, sollten Entwicklungsteams diese zentralen Kontrollen durchsetzen:

• Erwartete Algorithmen fest vorgeben: Lassen Sie niemals das eingehende Token bestimmen, wie es geprüft werden soll. Konfigurieren Sie Ihre Validierungsroutine explizit auf einen bestimmten Algorithmus (etwa RS256) und weisen Sie den none-Algorithmus ausnahmslos zurück.
• Claims vollständig validieren: Eine gültige Signature beweist nur, dass das Token nicht manipuliert wurde – nicht, dass es für diesen Benutzer aktuell gültig ist. Prüfen Sie bei jeder einzelnen Anfrage explizit exp (Ablauf), iss (Aussteller) und aud (Empfänger).
• Symmetrische Secrets wie Passwörter behandeln: Wenn Ihre Architektur symmetrisches Signieren (HS256) verlangt, ist Ihr geheimer Schlüssel faktisch ein Root-Passwort. Sorgen Sie für mindestens 256 Bit Entropie, erzeugen Sie ihn mit einem kryptografisch sicheren Zufallszahlengenerator und speichern Sie ihn sicher in Umgebungsvariablen oder einem Secrets Manager – niemals fest verdrahtet im Quellcode.
• Denken Sie daran: Kodierung ist keine Verschlüsselung. Legen Sie niemals sensible Daten, personenbezogene Daten oder Passwörter im JWT-Payload ab. Wer das Token abfängt, kann es umgehend per Base64 dekodieren.
• Token-Speicherung isolieren: Speichern Sie kurzlebige Access Tokens niemals in localStorage oder sessionStorage, wo eine einzige XSS-Schwachstelle für die Exfiltration genügt. Halten Sie Access Tokens strikt im Arbeitsspeicher des Clients und legen Sie langlebige Refresh Tokens in sicheren HttpOnly-, SameSite-Cookies ab.

Fortgeschrittenes Hardening: das Phantom-Token-Pattern

In Umgebungen mit hohen Sicherheitsanforderungen besteht die wirksamste Verteidigung gegen clientseitigen Diebstahl darin, das JWT dem Frontend überhaupt nie offenzulegen. Moderne Unternehmensarchitekturen setzen dafür häufig das „Phantom Token“-Pattern mit diesen Schritten um:

1. Der Autorisierungsserver stellt der Client-Anwendung eine zufällige, undurchsichtige Session-Zeichenkette aus – anstelle eines JWT.
2. Sendet der Client eine API-Anfrage, übermittelt er diese undurchsichtige Zeichenkette.
3. Das API-Gateway fängt die Anfrage ab, validiert das opake Token gegen den Auth-Server (oder den Session-Store) und tauscht es gegen ein vollständig befülltes, signiertes JWT.
4. Das API-Gateway leitet das eigentliche JWT an die internen Microservices weiter.

Häufige Fragen zur JWT-Sicherheit

Wie Haxoris helfen kann

Token-Sicherheit scheitert selten an der Kryptografie – sie scheitert an der Konfiguration. Haxoris hilft Ihnen, diese Lücken zu finden, bevor es ein Angreifer tut:

• Penetrationstests von Webanwendungen und APIs mit besonderem Fokus auf Authentifizierungs- und Autorisierungsabläufe.
• Review der Logik für die Ausstellung und Prüfung von JWTs sowie für die Schlüsselverwaltung, inklusive JWKS-Handling und Schlüsselrotation.
• Offline-Bewertung der Stärke symmetrischer Signaturschlüssel.
• Design-Review von Token-Speicherung, Session-Laufzeiten und Refresh-Token-Architektur.

Fazit

JWTs sind nicht von Natur aus unsicher. Unsicher werden sie in dem Moment, in dem eine Anwendung das Token darüber entscheiden lässt, wie es zu validieren ist – oder eine gültige Signature als Ersatz für Autorisierung behandelt. Geben Sie den Algorithmus fest vor, validieren Sie jeden Claim, behandeln Sie Secrets wie Root-Passwörter und halten Sie Tokens aus dem Browser-Speicher heraus. Dann verschwindet der Großteil der in diesem Artikel beschriebenen Findings aus Ihrem nächsten Pentest-Bericht.

Quellen und weiterführende Literatur

Die Methodik und die technischen Details dieses Beitrags sind von den folgenden maßgeblichen Sicherheitsquellen inspiriert und daraus adaptiert:

1. PortSwigger Web Security Academy. JWT Security Vulnerabilities. Eine detaillierte Aufschlüsselung von Fehlern bei der Signaturprüfung und von Header-Injection. portswigger.net/web-security/jwt
2. InfoSec Writeups. JWT Pentesting: A Journey from Token to Takeover. Praxisnahe Fallstudien zur Ausnutzung von Token-Konfigurationen. infosecwriteups.com
3. Auth0 / JWT.io. Introduction to JSON Web Tokens. Grundlegende Standarddokumentation zu Token-Strukturen und RFC 7519. jwt.io/introduction
4. JWTAuditor. Security Testing Tool. Eingesetzt für Payload-Manipulation und automatisierte Schwachstellenbewertungen. jwtauditor.com