In letzter Zeit wurden während unseren Tests einige Webapplikationen angetroffen, welche JSON Web Token (JWT) als klassische Session Tokens verwendeten. Dabei wurde festgestellt, dass vielen Entwicklern nicht bewusst war, dass es mit JWTs zu Problemen beim Widerruf solcher Tokens und somit auch dem Logout von Benutzern kommen kann. In diesem Artikel soll auf diese und weitere Problematiken von JWTs eingegangen und aufgezeigt werden, in welchen Situationen der Einsatz von JWTs sinnvoll ist.

Definition JWT und klassisches Session Token

RFC 7519 definiert JWTs als ein Mittel zur Repräsentation von Forderungen beziehungsweise Claims, die zwischen zwei Parteien übertragen werden. Wenn JWTs dazu genutzt werden, die Sessions von Benutzern zu verwalten, werden dementsprechend die Berechtigungen eines Benutzers im JWT festgehalten. Ein solcher Claim, der in einem JWT transportiert wird, könnte dementsprechend wie folgt aussehen:

{"user":"test", "id":"123", "gui":"full_access", "admin":"true", "exp":"1634205600"}

In diesem Claim befindet sich alles, was für die Validierung der Berechtigungen eines Benutzers serverseitig notwendig ist. Dementsprechend kann durch die Validierung der Signatur des JWTs die Validität des Claims festgestellt werden. Es besteht also keine Session per se, sondern es wird mit jedem Request die Validität des Claims überprüft. Der im Beispiel oben abgebildete Claim ist bis am 14. Oktober 2021 um 12:00:00 Uhr gültig. Danach wird das JWT aufgrund des exp-Parameters ablaufen.

Ein klassisches Session Token, das meist mittels Cookies im Browser gespeichert wird, beinhaltet lediglich eine ID, mit der serverseitig die Informationen zum Benutzer abgerufen werden können. Mit dem Session Token wird eine spezifische Session eines Benutzers verbunden. In der Regel wird eine Session nach einer gewissen Zeit aufgrund von Inaktivität oder bei einem Logout beendet und das Session Token kann nicht mehr verwendet werden.

Problematik Benutzung von JWTs als Session Token

Bereits im Artikel Signierte JSON Web Token wurde auf einige Schwachstellen wie der Algorithm:None-Angriff sowie die Problematik von gewissen verwendeten Signaturalgorithmen eingegangen. Auf diese Probleme wird hier nicht im Detail eingegangen.

Wie bereits aus der Definition der JWTs oben ersichtlich ist, gibt es für JWTs, sobald sie einmal ausgestellt sind, keinen Weg diese zu invalidieren oder zu widerrufen. Dies bedeutet auch, dass ohne Eigenentwicklungen kein funktionierendes Logout umgesetzt werden kann. Des Weiteren ist es nicht möglich, die in einem Claim enthaltenen Berechtigungen anzupassen, solange ein JWT gültig ist. Wenn der Claim

{"user":"test", "id":"123", "gui":"full_access", "admin":"true", "exp":"1634205600"}

als Beispiel genommen wird, bedeutet das also, dass der Benutzer test bis zum Ablauf des JWTs administrative Berechtigungen hat, auch wenn ihm diese serverseitig schon entzogen wurden. Da die Überprüfung der Berechtigungen nur über das JWT durchgeführt wird, kann die serverseitige Anpassung von Berechtigungen nicht erkannt werden. Diese Einschränkungen müssen Entwicklern bewusst sein, bevor der Einsatz von JWTs umgesetzt wird. Wie auch OWASP in ihrem JWT Cheat Sheet empfiehlt, sollten JWTs nur eingesetzt werden, wenn die Webapplikation komplett stateless ist. Ansonsten sollten klassische Systeme mit Sessions in Betracht gezogen werden.

Problematik Abspeichern von JWT

Neben der Problematik mit dem Invalidieren von JWTs gibt es noch die Problematik mit dem Abspeichern eines JWTs. Im Normalfall werden JWTs über einen Header versandt. Dementsprechend muss mit JavaScript auf das JWT zugegriffen werden können, um diesen Header erstellen zu können. Dies eröffnet allerdings die Problematik, dass das Token entweder im localStorage oder in einem Cookie ohne httpOnly-Schutz abgespeichert werden muss und dementsprechend bei einer XSS-Schwachstelle ausgelesen werden kann.

Um dieses Problem zu lösen, werden von OWASP zwei unterschiedliche Lösungsansätze vorgestellt. Einerseits kann das JWT in einem gehärteten Cookie gespeichert und direkt aus dem Cookie verarbeitet werden. Dabei muss das gehärtete Cookie mindestens die folgenden Attribute beinhalten:

Secure; HttpOnly;

Zusätzlich muss beachtet werden, dass mit dem Verwenden von Cookies nun Gegenmassnahmen gegen Cross Site Request Forgery Angriffe umgesetzt werden müssen. Für moderne Browser sollte das Setzten des Attributs SameSite=Strict beim Cookie reichen. Eine weitgehende Beschreibung eines CSRF-Angriffs sowie Gegenmassnahmen werden in unserem Artikel Cross Site Request Forgery – Ist CSRF tot? behandelt.

Grundsätzlich sollten die Claims aus einem JWT clientseitig nicht benötigt werden. Falls allerdings dennoch clientseitig auf Informationen aus dem JWT zugegriffen werden soll, kann der zweite Lösungsansatz von OWASP umgesetzt werden. Die Details und Implikationen einer solchen Implementation werden in den Abschnitten Tokenspeicherung auf der Client-Seite und Token Sidejacking im OWASP JWT Cheat Sheet genauer beschrieben.

Für was sind JWTs sinnvoll?

Wie bereits erwähnt, sind JWTs vor allem dann sinnvoll, wenn eine Applikation vollständig stateless ist. Ansonsten können JWTs als Token-Mechanismus in OAuth 2.0 Flows verwendet werden. Ebenfalls ein sehr guter Einsatzort für JWTs sind Anwendungsfälle, in denen sie als einmaliges Autorisierungs-Token verwendet werden können. Als Beispiel für einen solchen Anwendungsfall kann eine Applikation genommen werden, die es dem Benutzer unter anderem erlaubt Dateien herunterzuladen. Dabei handelt es sich beim Server, der die Dateien zur Verfügung stellt, um einen separaten, stateless Server oder Service. Dann kann von der Hauptapplikation ein Download-Token im JWT-Format ausgestellt werden, das vom Benutzer genutzt werden kann, um beim Download-Server seine Datei herunterzuladen. In diesem Fall haben die JWTs die folgenden Eigenschaften:

• Token sehr kurz gültig: Es muss lediglich für wenige Minuten gültig sein, damit der Benutzer den Download starten kann.
• Token nur ein Mal verwendet: Für jeden neuen Download wird ein neues Token erstellt. Dementsprechend handelt es sich beim Download-Server um eine Applikation, die tatsächlich komplett stateless ist.
• Lediglich Download-Server verwendet JWT für Autorisierung: Die Applikation selbst ist nicht stateless und verwendet Sessions. Eine Kombination von Session Tokens und JWTs kann also je nach Anwendungsfall sehr sinnvoll sein.

Fazit

JWTs sind nicht grundsätzlich etwas Schlechtes. Sie müssen einfach in den für sie angedachten Situationen eingesetzt werden, um sinnvoll zu sein. In einer Webapplikation, in der die Abmeldung von Benutzern oder das Anpassen von Berechtigungen umgehend geschehen muss, sind JWTs ohne zusätzliche eigene Logik aufzubauen nicht die richtige Lösung. JWTs sollten nur in Bereichen eingesetzt werden, die tatsächlich vollständig stateless sind. Ansonsten sollten bewährte klassische Session Tokens zum Einsatz kommen. Wenn JWTs für die Webapplikation verwendet werden, sollte darauf geachtet werden, wie diese abgespeichert werden, damit es aufgrund der gewählten Speicherungsmethode nicht zu Problemen bei XSS- oder CSRF-Angriffen kommt.

Über die Autorin

Andrea Hauser hat ihren Bachelor of Science FHO in Informatik an der Hochschule für Technik Rapperswil abgeschlossen. Sie setzt sich im offensiven Bereich in erster Linie mit Web Application Security Testing und der Umsetzung von Social Engineering Kampagnen auseinander. Zudem ist sie in der Forschung zum Thema Deepfakes tätig. (ORCID 0000-0002-5161-8658)

Links

• https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html
• https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html#token-sidejacking
• https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html#token-storage-on-client-side
• https://datatracker.ietf.org/doc/html/rfc7519