JSON Web Tokens, kurz JWTs, sind heutzutage unverzichtbare Bestandteile vieler moderner Webanwendungen. Sie kommen vor allem bei der Authentifizierung, Autorisierung und beim sicheren Datenaustausch zum Einsatz. Die Beliebtheit von JWTs rührt von ihrer Flexibilität und der Möglichkeit, zustandslose Sessions zu verwalten, was insbesondere in Microservice-Architekturen und bei Single Sign-On-Lösungen enorme Vorteile bringt. Dennoch bergen JWTs eine Vielzahl von Sicherheitsrisiken, die bei unsachgemäßer Implementierung erhebliche Folgen mit sich bringen können. Ein umfassendes Verständnis dieser Schwachstellen ist essenziell für Entwickler, Sicherheitsexperten und Betreiber, um APIs und Anwendungen effektiv zu schützen. Grundsätzlich setzt sich ein JWT aus drei kompakten Teilen zusammen: dem Header, dem Payload und der Signatur, die jeweils Base64URL-kodiert sind und durch Punkte getrennt werden. Der Header definiert dabei die Art des Tokens sowie das verwendete Signaturalgorithmus.
Im Payload befinden sich die Claims, also Informationen wie Nutzerkennung, Rollen oder Sitzungsdetails. Die Signatur soll sicherstellen, dass das Token auf dem Transportweg nicht manipuliert wurde und stammt typischerweise von einem privaten Schlüssel oder einem geheimen Schlüssel abhängig vom verwendeten Algorithmus. Die Wahl des Algorithmus ist ein kritischer Faktor für die Sicherheit eines JWT. Symmetrische Algorithmen wie HS256 beruhen auf einem gemeinsamen geheimen Schlüssel, während asymmetrische Algorithmen wie RS256 auf einem Schlüsselpaar aus privatem und öffentlichem Schlüssel basieren. Die korrekte Umsetzung der Signaturprüfung ist für die Integrität und Authentizität des Tokens entscheidend. Ein häufiger Fehler ist beispielsweise die fehlende Verifikation der Signatur, was Angreifern ermöglicht, beliebige Claims einzufügen oder Rollen zu eskalieren. Ohne Signaturprüfung wird der gesamte Zweck von JWTs als Sicherheitsmechanismus hinfällig.
Eine besonders gefährliche Schwachstelle ist der sogenannte "None Algorithm Attack". Ursprünglich hielt die JWT-Spezifikation den Algorithmus "none" für Debugging oder besondere Anwendungsfälle vorgesehen. Doch wenn Bibliotheken oder Server diesen Algorithmus nicht explizit verbieten, können Angreifer ein Token ohne gültige Signatur ausstellen und damit Sicherheitsmechanismen vollständig umgehen. Auch hier ergibt sich ein gravierendes Risiko, dass Benutzerzugriffe komplett gefälscht werden können. Die Sicherheit von HMAC-basierten JWTs hängt maßgeblich von der Stärke des geheimen Schlüssels ab. Hinterlegte oder triviale Schlüssel wie "secret" oder kurze Zeichenfolgen erleichtern es Angreifern mittels Brute-Force-Angriffen oder Wörterbuchangriffen, das Geheimnis zu erraten. Sobald der Schlüssel kompromittiert ist, können beliebige Tokens erzeugt und das gesamte Zugriffsmanagement unterwandert werden.
Daher ist die Verwendung langer, kryptographisch sicherer Schlüssel sowie deren regelmäßige Rotation ein unverzichtbarer Sicherheitsstandard. Ein komplexer Angriff, der oft erst spät erkannt wird, ist der Angriff durch Algorithmus-Verwirrung (Algorithm Confusion). Dabei manipulieren Angreifer das JWT-Header-Feld "alg" und wechseln etwa einen RS256-Algorithmus (RSA-basiert, asymmetrisch) zu HS256 (HMAC-basiert, symmetrisch). Funktioniert die Verifikation fehlerhaft, kann der öffentliche RSA-Schlüssel als HMAC-Geheimnis missbraucht werden, was zu einer vollständigen Umgehung der Authentifizierung führt. Ein ähnliches Problem besteht auch bei der Kombination von ECDSA-Algorithmen und HMAC. Die Grundlage solcher Attacken ist oft das blinde Vertrauen in das vom Client gelieferte Algorithmus-Feld, was streng vermieden werden muss. Das JWT-Header-Feld "kid" (Key ID) ist eigentlich dafür gedacht, die Identifikation des zu verwendenden Verifizierungsschlüssels zu erleichtern.
Wird das "kid"-Feld aber unzureichend geprüft oder unsicher verarbeitet – zum Beispiel durch Pfadmanipulationen oder ungesicherte Datenbankabfragen – können Angreifer Schlüsselfälschungen einführen oder sogar Remote Code Execution provozieren. Die Kontrolle und Validierung dieses Eingabewerts sind deshalb entscheidend, um solche Angriffe abzuwehren. Ein weiteres erhebliches Risiko stammt von der Möglichkeit, JSON Web Keys (JWK) direkt im JWT-Header einzubetten. Zwar kann dies in einigen Szenarien praktisch sein, führt aber bei mangelnder Prüfung dazu, dass fremde öffentliche Schlüssel akzeptiert werden. So können Angreifer eigene Schlüssel einbauen, Tokens selbst generieren und sich authentifizieren, ohne über die richtigen privaten Schlüssel des Servers zu verfügen. CVE-2018-0114 ist ein bekannter Sicherheitsvorfall, der diese Schwachstelle illustriert. Zusätzlich unterstützen JWTs Header-Felder wie "jku" (JWK Set URL) und "x5u" (X. 509 Zertifikat URL).
Diese erlauben es, öffentliche Schlüssel dynamisch über URLs zu laden. Wenn Server jedoch unbedacht diese URLs akzeptieren und keine strikten Whitelists oder Validierungen durchführen, entsteht ein Einfallstor für Server-Side Request Forgery-Angriffe und potentielle Schlüsselmanipulationen. Angreifer können eigene Schlüssel hosten und so Systeme kompromittieren. Neben Implementierungsfehlern in Servern ist auch manchmal die verwendete Kryptographie selbst Gegenstand von Schwachstellen. Ein Beispiel ist die 2022 entdeckte "Psychic Signature"-Vulnerability in der Java JDK ECDSA-Verifikation (CVE-2022-21449). Hier führte ein Fehler dazu, dass Signaturen mit ungültigen Parametern (r=0, s=0) akzeptiert wurden, was Angreifern wiederum die Möglichkeit gab, die Signaturprüfung komplett zu umgehen und sich so mit manipulierten Tokens als legitime Nutzer auszugeben. Angesichts der Vielzahl der potenziellen Risiken ist es enorm wichtig, JWT-Implementierungen lückenlos zu überprüfen.
Gerade in modernen Microservice-Architekturen, wo verschiedene Komponenten unterschiedliche Bibliotheken oder Schlüssel verwenden, muss jede einzelne Schnittstelle auf korrekte Signaturprüfung und sichere Algorithmusauswahl getestet werden. Die Vertraulichkeit der verwendeten Schlüssel, die Prüfung und Validierung aller Tokenfelder sowie eine restriktive Konfiguration von JWT-Bibliotheken sind entscheidende Grundlagen. In der Praxis empfiehlt es sich, niemals Parameter wie "alg", "kid", "jku", "x5u" oder "jwk" blind zu vertrauen. Stattdessen sollten feste Algorithmen im Servercode vorgegeben werden, etwa nur RS256. Die Eingaben von JWTs sollten strengen Validierungen unterliegen, und dynamische Schlüsselabrufe nur mit expliziten Vertrauensregeln erfolgen. Einsatz von bewährten und aktuellen JWT-Bibliotheken, regelmäßige Sicherheitsupdates und automatisierte Integrations-Tests dienen dazu, Fehler früh zu entdecken.
Darüber hinaus können gezielte Penetrationstests und Übungen mit realen Angriffsszenarien helfen, die eigene Umgebung dauerhaft abzusichern. Die umfassende Analyse der wichtigsten JWT-Sicherheitslücken und deren Exploits verdeutlicht, dass selbst kleine Nachlässigkeiten zu schwerwiegenden Sicherheitsproblemen führen können. Entsprechend fordert der Schutz von Webapplikationen und APIs eine ganzheitliche Sicherheitsstrategie. Von der Schlüsselverwaltung über die Implementierung bis hin zur Aufklärung und Schulung der Entwickler müssen alle Beteiligten sensibilisiert sein. Nur mit einem tiefen Verständnis für die Feinheiten von JWTs und deren potenzielle Schwachstellen lassen sich sichere Systeme gestalten. In einer Welt, in der digitale Identitäten und Zugriffe immer häufiger auf tokenbasierte Systeme angewiesen sind, entscheidet die sichere Handhabung von JWTs maßgeblich über die Widerstandsfähigkeit gegen Angriffe und Datenmissbrauch.
Wer die bekannten Angriffsvektoren kennt und effektiv dagegen vorgeht, schützt nicht nur seine Infrastruktur, sondern bewahrt auch das Vertrauen seiner Nutzer.
