JWT mit offenen Augen verwenden – Risiken des blinden Vertrauens in Drittanbieter-Pakete
Von Idego Group

JSON Web Token ist ein in RFC 7519 definierter Standard für den sicheren Datentransfer zwischen Diensten. Er bietet Datenintegrität und ermöglicht einem Dienst zu überprüfen, ob ein Token während der Übertragung nicht manipuliert wurde. Web-Entwickler lagern die JWT-Implementierung oft an Drittanbieter-Pakete aus und gehen davon aus, dass diese korrekt und sicher sind. Das blinde Vertrauen in diese Pakete kann jedoch schwerwiegende Sicherheitsfolgen haben.
Ein JWT besteht aus drei base64-kodierten Elementen, die durch Punkte getrennt sind: Header, Payload und Signatur. Der Header gibt den Token-Typ und den Algorithmus an, der zur Erstellung der Signatur verwendet wird. Der Payload enthält die funktionalen Daten, wie z.B. die Benutzeridentifikation. Die Signatur garantiert die Datenintegrität durch das Signieren des kodierten Headers und Payloads mit einem privaten Schlüssel.
RFC 7519 erlaubt none als Wert für den alg-Header-Parameter, gedacht für Fälle, in denen die Datensicherheit auf andere Weise gewährleistet wird. Schlecht implementierte JWT-Pakete können jedoch entweder einen 500-Fehler zurückgeben oder die Signaturverifizierung beim Auftreten dieses Werts vollständig umgehen. Dies könnte es Angreifern ermöglichen, unsignierte Tokens zu senden und sensible Daten ohne jegliche Verifizierung zu erhalten.
Eine kritische Schwachstelle kann entstehen, wenn Clients HS256 als Algorithmus angeben können, während sie mit dem öffentlichen Schlüssel des Servers signieren. Falsch konfigurierte Systeme könnten mit HMAC und demselben öffentlichen Schlüssel verifizieren und dabei die beabsichtigte Sicherheit vollständig umgehen. Ein Angreifer kann Tokens fälschen, indem er mit einem öffentlich verfügbaren Schlüssel signiert und gleichzeitig behauptet, einen symmetrischen Algorithmus zu verwenden.
Base64-Dekodierung allein verifiziert nicht die Authentizität eines Tokens. Das bloße Dekodieren der Header- und Payload-Daten bestätigt nicht, dass das Token von der behaupteten Quelle stammt oder nicht modifiziert wurde. Ein häufiger Fehler besteht darin, nur Dekodierungsfunktionen zu verwenden, anstatt Verifizierungsfunktionen, die die kryptografische Signatur prüfen.
Sicherheitspakete sind nur so vertrauenswürdig wie ihre Implementierungen. Während Drittanbieter-Lösungen generell angemessen sind, sollten Entwickler gründlich verstehen, wie sie funktionieren. Halten Sie Pakete aktuell, überwachen Sie auf Schwachstellen und aktualisieren Sie umgehend, wenn Probleme gefunden werden.