Wie kann man JTI-Ansprüche mit JWT richtig nutzen, um Replay-Attacken zu verhindern?

Question

Ich habe einige REST-APIs mit Spring erstellt und Spring Security mit JWT zur Authentifizierung implementiert. Mein Frontend führt AngularJs aus und konsumiert diese Rest-APIs, die JSON-Antworten empfangen. Die JWT-Authentifizierung funktioniert einwandfrei, ermöglicht jedoch das einfache Kopieren und Einfügen von Anforderungsparametern und Headern aus der Browserkonsole in Postman oder einen anderen REST-Client, um erfolgreiche Antworten auch von geschützten APIs vom Back-End abzurufen.

Ich versuche, dieses Problem zu lösen, indem ich JTI-Ansprüche innerhalb der JWT verwende. Ich plane, für jede Anfrage nach der Authentifizierung einen eindeutigen JTI-Wert zu verwenden, so dass das bloße Stehlen von Kopfzeilen aus dem Browser nicht funktionieren würde.

Jetzt, nachdem ich viele online verfügbare Ressourcen durchgegangen bin, ist mir immer noch nicht klar, ob der Client oder der Server den JTI-Wert in der JWT setzen soll.

Nach meinem Verständnis, wenn ich dies auf der Serverseite tun, muss ich eine neue JWT mit jeder Antwort senden und erwarte es in der nächsten Anfrage vom Client unter Beibehaltung einer Aufzeichnung der verwendeten JTIs in einer Datenbank. Aber wenn ein Angreifer dies herausfindet, muss er nur ein Token aus einer früheren Anfrage verwenden und danach bequem mit meinen APIs interagieren.

Wenn ich dies auf der Client-Seite mache, muss ich den geheimen Signaturschlüssel des JWT und die Logik für die JTI-Generierung im JavaScript-Code behalten, damit er einen JTI-Wert und einen Hash anhängen kann das Token wieder. Meine Fragen sind dann:

1. Was ist die richtige Art, dies zu implementieren? Vermische ich etwas oder gehe in die falsche Richtung?
2. Gibt es eine andere Lösung, die ich implementieren kann, um alle Anfragen von einem Nicht-Browser-Client zu verbieten oder nicht zu authentifizieren (wie es in älteren Spring MVC-Anwendungen mit Jsps passiert)?

Jede Hilfe wird sehr geschätzt. Ich bin jetzt schon lange darauf festgefahren.

Answer 1

Ich kann nicht mit Java/Spring sprechen, aber ich kann versuchen, Ihre Bedenken bezüglich JWTs und JTI-Ansprüchen zu klären.

Die Implementierung einer JTI zur eindeutigen Identifizierung eines JWT kann dazu beitragen, dass replay attacks verhindert wird, wenn ein Angreifer dieselbe JWT sendet, um eine Anforderung zu stellen. Der Server würde den JTI-Wert generieren und ihn bei jeder Antwort mit einer neuen JWT senden. Wenn eine neue Anforderung empfangen wird, müsste der Server den JTI-Wert validieren (um sicherzustellen, dass er zuvor nicht verwendet wurde). Die Implementierung erfordert jedoch eine Art persistenten Speicher auf dem Server, der mehr oder weniger wie herkömmliche Sitzungen aussehen kann, so dass es sich ein wenig merkwürdig anfühlt, da einer der beworbenen Vorteile von JWT eine "zustandslose Anwendung" ist.

Sie sind absolut richtig in Bezug auf Ihr Anliegen eines Man-in-the-Middle-Angriffs: Wenn jemand die JWT (und seine einmalige JTI) abfängt und dann VORHER eine Anfrage stellt, wird ihre Anfrage gestellt als gültig angesehen und IHRE nachfolgenden Anfragen erscheinen dem Server als "Wiederholungen" (und der Server würde sie für ungültig halten).