Löcher in der JWT-Sessionverwaltung

Handlungsbedarf für Administratoren, die JSON Web Token einsetzen, um die Sessions angemeldeter Benutzer zu verwalten: Schwachstellen in mehreren Bibliotheken erlauben es Angreifern, sich beliebige Nutzerrechte zu verschaffen.

In Pocket speichern vorlesen Druckansicht 4 Kommentare lesen
Löcher in der JWT-Sessionverwaltung
Lesezeit: 2 Min.
Von
  • Fabian A. Scherschel

Die Entwickler des Authentifizierungs-Protokolls JSON Web Token (JWT) warnen vor kritischen Schwachstellen in einigen Software-Bibliotheken, die ihr Protokoll umsetzen. Durch zwei Sicherheitslücken können Angreifer Session-Token fälschen und sich so erweiterte Nutzerrechte verschaffen. Betroffene Administratoren sollten Updates für die von ihnen verwendeten JWT-Bibliotheken installieren oder, falls keine Updates zur Verfügung stehen, auf andere Bibliotheken umsteigen, so die JWT-Entwickler.

Auf der JWT-Webseite sind die momentan verwundbaren Bibliotheken zusammengefasst. Updates für die Node.js- und Python-Bibliotheken stehen bereit, für die in JavaScript und PHP geschriebenen Versionen sind momentan noch keine Aktualisierungen verfügbar. Implementierungen in anderen Sprachen wie Ruby, Java, Lua, Scala und .NET sind nach aktuellen Erkenntnissen nicht betroffen.

Ein JSON Web Token wird vom Server an einen Client ausgegeben, der sich dann damit ausweisen kann. Zu diesem Zweck signiert der Server die Informationen, damit der Client sie nicht manipulieren und sich etwa die zusätzlichen Nutzerrechte eines anderen Nutzer-Kontos unter den Nagel reißen kann. Token, die von verwundbaren Bibliotheken verarbeitet werden, können auf zwei verschiedene Arten manipuliert werden. Dabei umgeht ein Angreifer die Überprüfung der digitalen Signatur.

Im Header des Tokens, außerhalb des signierten Bereichs, steht der Algorithmus, mit dem signiert wird. Eine Angabe, die alle Bibliotheken laut Protokoll annehmen müssen ist none. Hier wird also ein Token übermittelt, das nicht signiert wurde – so etwas soll eigentlich nur in Situationen passieren, in denen der Server die Authentizität des Tokens schon gewährleisten kann, etwa wenn der Nutzer schon angemeldet ist und über eine verschlüsselte Verbindung kommuniziert. Die verwundbaren Bibliotheken akzeptieren allerdings auch manipulierte Token mit dem none-Header. Hierzu nimmt ein Angreifer ein signiertes Token, ändert den Inhalt nach Belieben und nimmt dann den Signierungs-Algorithmus aus dem Header. Der Server übergeht dann einfach die Signatur-Prüfung, ein äußerst fatales Vorgehen bei einem Authentifizierungs-Mechanismus.

Ein zweiter Angriff setzt ebenfalls bei den verwendeten Signierungs-Algorithmen an. Hier kann ein Angreifer ein gefälschtes Token mit einem öffentlichen Schlüssel des Servers signieren und diesen dazu bringen, diesem Schlüssel genauso zu vertrauen wie einem geheimen Schlüssel. Nicht verwundbare Bibliotheken prüfen vorher, mit welchem Schlüssel die Nachrichten laut Konfiguration signiert und geprüft werden und lassen dies nicht den (möglicherweise böswilligen) Client entscheiden. (fab)