JSON-Web-Tokens (JWTs) sind in vielen Unternehmen zur bevorzugten Methode für die Authentifizierung geworden. Sie sind einfach zu implementieren und daher eine beliebte Wahl für die Sicherung von APIs und Webanwendungen. Wenn sie jedoch nicht ordnungsgemäß verwaltet werden, können JWTs Sicherheitsschwachstellen verursachen und Ihre Systeme gefährden. Sie haben sie wahrscheinlich selbst schon verwendet.
Aber haben Sie sie auch sicher umgesetzt und gehandhabt?
In einem Blogbeitrag von Akamai wurden mehrere häufige Sicherheitsschwachstellen im Zusammenhang mit JWTs aufgezeigt. Er war ein Weckruf für die potenziellen Risiken einer unsachgemäßen Verwaltung Ihrer JWTs. In diesem Blogbeitrag möchte ich darauf aufbauen und mich auf eine zusätzliche Schwachstelle konzentrieren, die oft übersehen wird: nicht ablaufende JWTs. Wir werden uns ansehen, wie dieses Problem auftritt und welche Sicherheitslücken damit verbunden sind. Anschließend gebe ich Ihnen einige Hinweise, damit Sie wissen, wie Sie sich vor diesen Sicherheitslücken schützen können.
Überblick über häufige JWT-Schwachstellen
Bevor wir uns damit befassen, sollten wir kurz auf die JWT-Schwachstellen eingehen, die in dem oben erwähnten Blog-Beitrag genannt wurden. Die sechs Bedrohungen für JWTs, die der Autor erwähnte, waren:
- Erlauben, dass der Server ein Token ohne Validierung verwendet: Dies kann der Fall sein, wenn der Server die Integrität des Tokens nicht überprüft, was es Angreifern erleichtert, es zu manipulieren und auszunutzen. Angreifer können auch den Verifizierungsalgorithmus (alg) auf "none" setzen und so versuchen, den Server so zu manipulieren, dass er das Token überhaupt nicht validiert.
- Verwendung desselben privaten Schlüssels für verschiedene Anwendungen: Diese Praxis kann mehrere Anwendungen gefährden, wenn der Schlüssel offengelegt wird.
- Verwendung eines schwachen Signieralgorithmus: Schwache Signieralgorithmen können leichter geknackt werden, was zu unberechtigtem Zugriff führt.
- Wahl eines kurzen und/oder privaten Schlüssels mit geringer Entropie: Schlüssel, die zu kurz sind oder denen es an Zufälligkeit fehlt, sind anfälliger für Brute-Force-Angriffe.
- Aufbewahrung sensibler Daten in der Nutzlast eines JWTs: Sensible Informationen, die in der Nutzlast gespeichert sind, können offengelegt werden, wenn das Token abgefangen wird.
- Verwechslung der Schlüssel: Die falsche Verwaltung von Schlüsseln kann zu einer falschen Validierung führen, die unbefugten Zugriff ermöglicht.
Ausführliche Informationen zu diesen Schwachstellen finden Sie in diesem Blog-Beitrag. Schauen wir uns nun eine weitere Schwachstelle an: die nicht ablaufende JWT.
Zusätzliche Sicherheitslücke: Nicht ablaufende JWTs
Werfen wir einen Blick auf den folgenden JWT, der auf einem realen Beispiel basiert, das mir vor nicht allzu langer Zeit begegnet ist:
Dies ist ein JWT, das zur Authentifizierung und Autorisierung des Zugangs eines Benutzers zu einer API verwendet wird. Es ist mit einem sicheren Geheimnis signiert, um Fälschungen zu verhindern. Auf den ersten Blick sieht es gut aus. Aber sehen wir uns die Nutzdaten genauer an:
{ |
Bei der Angabe ttl denken Sie wahrscheinlich an time-to-live, denn dafür steht TTL normalerweise. Dies hat also wahrscheinlich damit zu tun, wie lange der JWT gültig ist. Dies muss die Ablaufzeit sein.
Wir können hier einige einfache Berechnungen anstellen. Vielleicht ist 86.400.000 die Anzahl der Sekunden, in diesem Fall beabsichtigt der Aussteller, dass dieses JWT für 1000 Tage gültig ist. Oder vielleicht sind Millisekunden gemeint, dann soll dieses JWT einen Tag lang gültig sein. Das könnte auch Sinn machen.
Aber hier ist das Problem: Die JWT-Spezifikation besagt, dass die Verfallszeit als exp und nicht als ttl angegeben wird:
| Die Angabe "exp" (expiration time) gibt die Ablaufzeit an, nach der das JWT NICHT mehr zur Verarbeitung angenommen werden MUSS. Die Verarbeitung des "exp"-Anspruchs erfordert, dass das aktuelle Datum/die aktuelle Uhrzeit vor dem im "exp"-Anspruch aufgeführten Ablaufdatum/-zeit liegen MUSS. Die Implementierer KÖNNEN einen kleinen Spielraum vorsehen, in der Regel nicht mehr als ein paar Minuten, um eine Zeitverschiebung zu berücksichtigen. Sein Wert MUSS eine Zahl sein, die einen NumericDate-Wert enthält. Die Verwendung dieses Claims ist OPTIONAL. |
Dann haben wir hier also ein paar Probleme.
Erstens verwendet der Aussteller dieses JWT ttl zur Angabe des Ablaufs, aber ttl ist kein Standard-JWT-Anspruch. Die meisten Bibliotheken, die für den Umgang mit JWTs ausgelegt sind, erkennen ttl nicht als Anweisung für den Ablauf des Tokens. Dies wird zu Kompatibilitätsproblemen führen, und das Token wird höchstwahrscheinlich als nicht ablaufend behandelt werden.
Zweitens erfordert der Anspruch exp einen tatsächlichen Zeitstempel des Ablaufs, nicht eine relative Anzahl von Millisekunden (oder Sekunden) ab dem Ausgabezeitpunkt. Diese Verwirrung rührt wahrscheinlich von der Verwendung von ttl statt exp her. Nichtsdestotrotz muss der Emittent das erwartete Format für den exp-Anspruch verstehen, um den ordnungsgemäßen Ablauf des Tokens zu gewährleisten.
Unabhängig davon, ob Sie die Ablaufzeit für ein JWT vernachlässigen oder falsch einstellen (wie in unserem Beispiel), wird Ihr JWT als nicht ablaufend behandelt. Und dies stellt eine erhebliche Sicherheitslücke dar.
| Ohne ordnungsgemäße Ablauffrist kann ein JWT von Angreifern wiederverwendet werdenoder über die vorgesehene Lebensdauer hinaus auslaufen,was das Risiko eines nicht autorisierten Zugriffs erhöht. |
Entschärfung von JWT-Sicherheitsschwachstellen
Nachdem wir uns nun mit den potenziellen Sicherheitslücken befasst haben, stellt sich die nächste Frage: Was sollten Sie dagegen tun? Glücklicherweise ist die Behebung dieser Schwachstelle einfach und unkompliziert!
Verwenden Sie immer den Verfallsanspruch. Legen Sie für jedes Token, das Sie erzeugen, eine Verfallszeit fest. Stellen Sie dabei sicher, dass Sie den standardmäßigen exp-Anspruch mit dem erwarteten Wertformat verwenden, um sicherzustellen, dass er den JWT-Spezifikationen entspricht und wie vorgesehen abläuft.
Aktualisieren Sie Anwendungen und Bibliotheken. Stellen Sie sicher, dass Ihre Anwendung und alle von Ihnen verwendeten Bibliotheken aktualisiert sind und den neuesten JWT-Standards entsprechen. Regelmäßige Updates helfen, Sicherheitslücken zu schließen und die Kompatibilität zu verbessern.
Das war's. Wenn Sie diese einfachen Richtlinien befolgen, können Sie das Risiko eines unbefugten Zugriffs über ein nicht ablaufendes JWT erheblich verringern. Dadurch wird die allgemeine Sicherheit Ihrer JWT-Implementierungen verbessert.
Fazit
Das Verständnis und die Behebung von JWT-Schwachstellen ist entscheidend für die Sicherheit Ihrer Anwendungen. In diesem Beitrag haben wir das Risiko von nicht ablaufenden Token hervorgehoben. Durch die korrekte Verwendung des Exp Claims und die Aktualisierung Ihrer Bibliotheken können Sie dieses Risiko wirksam eindämmen.
Weitere Sicherheitslösungen und Best Practices finden Sie in den Ressourcen der Linode-Dokumentation. Linode bietet umfassende Anleitungen, die Ihnen helfen, Sicherheitslücken in Ihren Anwendungen zu beseitigen.
Kommentare