Signierte JSON Web Token

Ein vermeintlich sicheres Token und seine Schwachstellen

von Valérie Kastner

Lesezeit: 8 Minuten

Keypoints

So lassen sich signierte JSON Web Token kompromittieren

JSON Web Tokens sind base64url-codiert und folgen einer strikten Struktur
Mit der Algorithmus-Definition "none" kann ein Token gegebenenfalls manipuliert werden
Hashcat hilft beim Brute-Forcing von schwachen Secrets
Access- und Refresh-Tokens sollten eine gegenseitige Zugehörigkeit aufweisen und aufgrund derer überprüft werden

Den Begriffen Autorisierung und Authentisierung wird eine bedeutende Rolle in der IT-Security beigemessen. Moderne und bekannte Frameworks wie OAuth oder OpenID, sowie diverse Business-Applikationen, nutzen den Standard der JSON Web Token. Die Sicherheitsoptionen von JSON Web Tokens lassen sich in zwei Standards unterteilen: JSON Web Signature (JWS) und JSON Web Encryption (JWE). In diesem Artikel wird der Fokus auf signierte JWTs (JWS) beschränkt, deren Nutzen und Aufbau erläutert sowie auf sicherheitsrelevante Schwachstellen hingewiesen.

Was ist ein JWT

Ein JSON Web Token (JWT) ist ein nach RFC 7519 genormtes Access-Token, das Informationen als JSON-Objekt zwischen einzelnen Parteien transferiert. Die benötigten Informationen sind im Token enthalten, weshalb dieses beispielsweise für die Authentisierung oder den Informationsaustausch zwischen Front- und Backend eingesetzt werden können. Der Inhalt das Tokens ist base64url-codiert und somit sind die im JWT enthaltenen Informationen im Klartext verfügbar. Es besteht jedoch die Möglichkeit, dass JSON Web Token zu verifizieren und zu signieren, um eine Manipulation des Tokens möglichst zu verhindern.

Struktur signierter JWT

Ein signiertes JSON Web Token besteht aus 3 Abschnitten, dem JOSE Header, der JWS Payload und der Signatur. Sie sind jeweils voneinander durch einen Punkt . getrennt.

Beispiel eines JSON Web Tokens:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6InNjaXAgQUciLCJhZG1pbiI6dHJ1ZSwiaWF0IjoxNTE2MjM5MDIyfQ.dX_ACtDZVh9ZKaDMLmZFURrh7o5R99-6MEulWUFCaT0

Das JWT-Beispiel dekodiert:

Header: {"alg": "HS256", "typ": "JWT"}
Payload: {"sub": "1234567890", "name": "scip AG", "admin": true, "iat": 1516239022}
Signatur mit HS256: dX_ACtDZVh9ZKaDMLmZFURrh7o5R99-6MEulWUFCaT0 (Verwendung des Secrets scipAG)

JOSE Header und Unsecured JWTs

Der erste Teil eines JWT ist der JOSE (Javascript Object Signing and Encryption) Header. Er enthält Informationen darüber, mit welchem Algorithmus das Token signiert wurde. Ein Token kann beispielsweise mit HMAC-Algorithmen und einem Secret signiert werden oder mittels Public-/Private-Key-Verfahren wie RSA oder ECDSA. Alle verwendbaren Algorithmen sind in der Spezifikation JSON Web Algorithms (JWA) auffindbar.

Auffällig dabei ist der definierte Algorithmus none. Es ist möglich ein JWT damit zu manipulieren, indem der Algorithmus auf {"alg":"none"} gesetzt, sowie die Signatur entfernt wird. Sofern das Backend keine Signatur-Verifizierung durchführt, wird das manipulierte Token ohne weiteres angenommen. Die Verifizierung der Signatur ist aus diesem Grund unerlässlich, da ansonsten die Informationen in der Payload des Tokens nach Belieben geändert werden kann. Beispielsweise könnte mit dem Ändern der Benutzerrolle eine Privilege Escalation angestrebt werden.

JWS Payload in Form eines JWT Claims Sets

Der zweite Abschnitt des Tokens, das JWT Claims Set, stellt ein JSON-Objekt dar, welches die zu übermittelnden Informationen (Claims) enthält. Es gibt drei Klassen von JWT Claims Names:

Registered Claim Names
Public Claim Names
Private Claim Names

Die Namen müssen stets eindeutig sein, die vordefinierten Claims können im RFC 7519 eingesehen werden.

Auch die JWS-Payload ist base64url-kodiert, weshalb besonders darauf geachtet werden sollte, dass beispielsweise keine sensitiven Personendaten über ein JWT übermittelt werden. Ansonsten ist es einem Angreifer durch die Analyse eines JWTs möglich, diese Informationen in Erfahrung zu bringen, Aufschluss über die Struktur von Email-Adressen oder Usernamen zu erhalten oder auch die genaue Bezeichnung von Benutzerrollen zu erfahren. Denn die Signatur des Tokens verhindert lediglich die Manipulation des Tokens – die darin enthaltenen Informationen können jederzeit, quasi im Klartext, ausgelesen werden. Eine JWS Payload anzupassen ist unkompliziert. Burp Suite bietet beispielsweise diverse Extensions wie unter anderem JSON Web Tokens (JOSEPH) als Hilfestellung an.

Signatur und Brute-Forcing eines Secrets

Das dritte und letzte Element des Tokens ist die Signatur, deren Aufbau nach dem RFC 7515 genormten Standard, definiert ist. Auch die Signatur ist base64url-codiert und wurde mit dem gewählten Algorithmus aus dem JOSE-Header gebildet. Mithilfe der Signatur soll sichergestellt werden, dass ein Token während der Übermittlung nicht manipuliert wurde.

Die Signatur des JWTs kann jedoch ebenfalls Schwachstellen enthalten. Wurde der Algorithmus HS256 gewählt und ein schwaches Secret gesetzt, ist es möglich, letzteres zu errechnen. Insbesondere Hashcat stellt dafür eine entsprechende Funktion zur Verfügung (Hash Mode 16500).

./hashcat64.bin --session <project> -a 16500 -m <jwt> -w 3 -r <rulepath> <dictpath>

Sobald das Secret errechnet wurde, kann wiederum das Token beliebig manipuliert oder neu generiert und mit dem entsprechenden Secret signiert werden. Dabei kann auch ein online JWT-Generator beigezogen werden.

Fremdes Access-Token mit eigenem Refresh-Token erneuern

Im Allgemeinen gibt es Access- und Refresh-Tokens. Ist die Validierung der Access- und Refresh-Tokens nicht korrekt konfiguriert, ist es unter Umständen möglich, ein Access-Token (auch abgelaufenes) eines anderen Users mit dem eigenen Refresh-Token zu erneuern, sofern der Angreifer in den Besitz eines solchen gelangen kann. Dies ist dann möglich, wenn nur die Gültigkeit eines Refresh-Tokens überprüft wird und nicht seine Zugehörigkeit zum Access-Token.

Die Bedingungen für den Request sind Kenntnisse über den Endpunkt, wo ein neues Token generiert wird, ein Authorization: Bearer Header mit dem entsprechend abgelaufenen Access-Token, sowie das Refresh-Token im Body des Requests.

Gestelltes Beispiel für die Erneuerung eines fremden Access-Tokens mit dem eigenen Refresh-Token:

POST /scipAG/JWT/refresh/newToken
[Various Headers]
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6InNjaXAgQUciLCJhZG1pbiI6dHJ1ZSwiaWF0IjoxNTE2MjM5MDIyfQ.dX_ACtDZVh9ZKaDMLmZFURrh7o5R99-6MEulWUFCaT0
[Various Headers]

{"refresh_token": "thisIsAnExampleOnly"}

Vergleich zu SAML 2.0 und SWT

Im Vergleich zu SAML (Security Assertion Markup Language) hat ein signiertes JSON Web Token den Vorteil, dass es einfach zu implementieren ist, da es aufgrund der geringen Grösse ohne Probleme in ein HTTP-Header passt. Im Gegenzug dazu ist es einem JWT nicht möglich, ein SAML vollständig zu ersetzen. SAML 2.0 bietet mehr Sicherheitsoptionen, welche jedoch mit einer höheren Komplexität und Grösse verbunden sind. Dabei tragen insbesondere die Verwendung von XML, XML Digital Signature (DSIG), sowie XML Canonicalization zur Komplexität von SAML bei.

Im Vergleich mit Simple Web Tokens (SWTs), bietet ein JWT mehr Flexibilität und Wahlmöglichkeiten. Während sowohl die Claim Names, sowie die Claim Values bei einem SWT das Format eines Strings aufweisen, können die Claim Values des JWT einen beliebigen JSON-Typ annehmen. Des Weiteren unterstützt das SWT nur HMAC SHA-256, wobei bei einem JWT zwischen verschiedenen Algorithmen gewählt werden kann.

Fazit

Signierte JSON Web Tokens sind sicher, sofern sie korrekt und sorgfältig konfiguriert und implementiert werden. Wichtig zu beachten ist jedoch, dass keine sensitiven Informationen, wie Username, Benutzerrolle oder Ähnliches, über das Token transportiert werden. Denn diese sind nur mittels base64url-codiert und werden nicht verschlüsselt übertragen.

Über die Autorin

Valérie Kastner studiert Betriebsökonomie mit Schwerpunkt Risk & Insurance an der Zürcher Hochschule für Angewandte Wissenschaften. Nach mehreren Jahren im Underwriting und Technical Center von Versicherungen, arbeitet sie seit 2018 im Bereich IT-Security mit Fokus auf Web Application Security Testing und Social Engineering. (ORCID 0000-0002-9214-572X)

Sie wollen mehr als einen simplen Security Test mit Nessus und Nmap?

Unsere Spezialisten kontaktieren Sie gern!

Ich möchte ein "Red Teaming"

Michael Schneider

Mensch und KI

Marisa Tschopp

Fahrzeugforensik

Michèle Trebo