JSON-Web-Tokens (JWT): Schlüssel für deren sichere Verwendung

Jul 13, 2023

Vor einigen Wochen haben uns einige Entwicklungskollegen ihre Besorgnis über die Generierung von JSON Web Tokens (JWT) mitgeteilt, die sie im Rahmen der Integration eines neuen Tools durchführen. Sie hatten von „ziemlich vielen“ Sicherheitsproblemen gehört und wollten, dass wir ihnen bei der Überprüfung helfen, ob die ausgegebenen Token korrekt waren und einige grundlegende Sicherheitsanforderungen erfüllten.

Wir arbeiten derzeit an einem Projekt, das bei der Automatisierung von Sicherheitstests hilft, APICheck, das wir kürzlich als „Open Source“ veröffentlicht haben. APICheck besteht aus einer Reihe kleiner Tools, die über Pipes miteinander verbunden werden können, um die Ausführung verschiedener Tests bei Anfragen an APIs verketten zu können. Daher haben wir uns an die Entwicklung eines Tools gemacht, das die Validierung der von ihnen ausgegebenen Token ermöglichen würde, jwt -Checker, in dem wir die Möglichkeit implementiert haben, die Validierungen zu übergeben, die wir zu den Token kommentieren. Später werde ich ein Beispiel für einen Test mit dem Tool zeigen.

JWT (JSON Web Token) ist ein offener Standard (veröffentlicht in RFC 7519), der eine kompakte, eigenständige Methode zum sicheren Kapseln und Teilen von Ansprüchen über ein Subjekt zwischen verschiedenen Parteien mithilfe von JSON-Objekten definiert. Der Inhalt des Tokens kann vertrauenswürdig und verifiziert werden, wenn es digital signiert ist (JWS, RFC 7515). Die Signatur kann mit symmetrischen Schlüsseln (HMAC) oder asymmetrischen Schlüsseln (RSA oder ECDSA) generiert werden. Darüber hinaus können JWTs auch verschlüsselte Daten (JWE, RFC 7516) zum Schutz sensibler Daten enthalten, obwohl diese Art von Token nicht Gegenstand dieser Studie ist.

Es ist wichtig zu beachten, dass Token standardmäßig nicht verschlüsselt sind und dass es sich bei der angezeigten Zeichenfolge lediglich um eine Serialisierung mit Base64URL-Kodierung handelt, die leicht dekodiert werden kann, um den JSON-Inhalt des Tokens klar zu sehen.

Die Antwort auf die Ausgangsfrage lautet also: „Es kommt darauf an ...“. Wie bei vielen anderen Technologien hängt JWT stark von der bei der Generierung verwendeten Konfiguration und der ordnungsgemäßen Verwendung und Validierung von Token beim Verbrauch ab.

JWT (JSON Web Token) ist ein offener Standard, der eine kompakte, eigenständige Methode zum sicheren Kapseln und Teilen von Aussagen über eine Entität zwischen verschiedenen Parteien mithilfe von JSON-Objekten definiert.

Wir beginnen mit der Betrachtung der wichtigsten Token-Typen und der wichtigsten Anwendungsfälle:

JWT ermöglicht aufgrund seiner geringeren Größe einen sicheren Datenaustausch zwischen Parteien effizienter als andere Standards (SAML) und eignet sich daher ideal für die folgenden Anwendungsfälle:

Jeder Anwendungsfall hat einen anderen Empfänger (Clientanwendung und API-Dienst), aber für den Fall, dass gleichzeitig die Kontrolle über beide ausgeübt wird, kann ein einziger Token für beide Fälle verwendet werden.

Im Folgenden listen wir die Best Practices für die Arbeit mit JWT auf und konzentrieren uns ausschließlich auf deren Generierung und Validierung.

Mit sehr wenigen Ausnahmen (zur Verwendung auf der Clientseite zum Übertragen von Sitzungsinformationen und Daten zum Neuaufbau der Benutzeroberfläche) sollte ein Token nicht ohne Signatur ausgestellt werden. Die Signatur ist ein grundlegender Schutz, der es Verbrauchern des Tokens ermöglicht, ihm zu vertrauen und sicherzustellen, dass er nicht manipuliert wurde.

Bedenken Sie bei der Wahl des Signaturalgorithmus, dass symmetrische Schlüsselalgorithmen anfällig für Brute-Force-Angriffe sind, wenn der verwendete Schlüssel nicht stark genug ist (Kosenamen und Geburtsdaten sind hierfür ebenfalls nicht gültig;- ), sodass für ausreichende Komplexität gesorgt werden muss wenn symmetrische Schlüsselalgorithmen gewählt werden. Andererseits vereinfachen asymmetrische Schlüsselalgorithmen die Aufbewahrung des Schlüssels, da dieser nur im Serverteil erforderlich ist, der den Token generiert.

Ein einmal signierter Token ist für immer gültig, wenn es kein Ablaufdatum gibt (Anspruchsablauf). Im Fall von „Zugriffstoken“ hat jemand, der einen erbeutet, für immer Zugriff auf den erlaubten Vorgang. Die Zuweisung von Identifikatoren (Claim JTI) zu den Token ermöglicht deren Widerruf; im Falle einer Token-Kompromittierung ist es äußerst wünschenswert, die Möglichkeit zu haben, sie zu widerrufen.

Um den Verbrauchern die Verwaltung der Token zu erleichtern, ist es notwendig, den Aussteller (claim iss) und alle möglichen Empfänger (claim aud) zu identifizieren. Auf diese Weise können sie den Validierungsschlüssel identifizieren und überprüfen, ob er adressiert ist zu ihnen. Wie wir später sehen werden, ist es für Token-Konsumenten eine gute Praxis, diese Daten zu validieren.

Wie eingangs erwähnt, sind die Token standardmäßig nicht verschlüsselt, Sie müssen also mit den darin eingegebenen Informationen vorsichtig sein. Wenn es notwendig ist, sensible Informationen oder Geheimnisse einzubeziehen, müssen verschlüsselte Token verwendet werden.

Als Beispiel zeige ich Ihnen hier die Ausführung eines Tests zur Überprüfung einiger der Validierungen, die wir mit jwt-checker gesehen haben:

In diesem Beispiel sehen wir eine der Fähigkeiten des APICheck-Tools, nämlich die Verkettung von Aktionen. In diesem Fall fordert das erste Tool den Erhalt eines Tokens an und generiert ein Austauschobjekt, das an das nächste Tool, in diesem Fall unseren Validator, übergeben wird, der mehrere der oben genannten Aspekte überprüft.

Die Signatur ist das einzige Mittel zur Überprüfung der Vertrauenswürdigkeit der darin enthaltenen Daten. Die erste Validierung, die wir nach der Überprüfung des Formats durchführen müssen, besteht darin, dass das Token signiert ist. Diese Option muss immer aktiviert sein, sonst könnte ein Angreifer einen Token erbeuten, die Signatur entfernen, ihn nach Belieben modifizieren und erneut versenden. Akzeptieren Sie niemals ein Token mit „alg: „none““ im Header. Der beste Schutz besteht darin, immer zu überprüfen, ob das Alg-Feld einen Wert aus einem bestimmten, von uns definierten Satz enthält. Je kleiner, desto besser.

Wir sollten niemals auf die Unbedenklichkeit der im Header oder in den Ansprüchen erhaltenen Informationen vertrauen, insbesondere wenn wir sie für Suchen in Backends verwenden. Wir müssen sie immer bereinigen, bevor wir sie verwenden, um Injektionsangriffe zu vermeiden. Beispielsweise kann der Wert des Felds „kid“ (Schlüsselkennung) für die Suche in einer Datenbank verwendet werden (SQL-Injection) und der Wert der Felder „jku“ (URL zum Definition eines Schlüssels) und x5u (URL zur Zertifikatskette des Schlüssels) sind beliebige URLs, die SSRF-Angriffe verursachen können und die wir anhand einer Whitelist von URLs validieren sollten.

Bevor wir ein Token akzeptieren, müssen wir überprüfen, ob es an uns adressiert ist (claim aud) und ob es von der erwarteten Entität ausgestellt wurde (claim iss). Auf diese Weise verringern wir das Risiko, dass ein Angreifer ein ausgegebenes Token für einen anderen Zweck verwendet aber deren Unterschrift wir überprüfen können.

Bei der Auswahl des Schlüssels zur Validierung der Signatur müssen wir nicht nur den Aussteller, sondern auch den Algorithmus berücksichtigen. Ein Angreifer könnte einen Token, der „RS512“ verwendet, erbeuten und ihn in „HS256“ ändern, indem er zum Signieren den öffentlichen Schlüssel des Ausstellers (der zugänglich ist) verwendet. Wenn wir diese Validierung nicht durchführen würden, könnten wir das Token als gültig akzeptieren, obwohl dies in Wirklichkeit nicht der Fall ist.

Lesen Sie weiter über