it-swarm.com.de

Kann ich einen Wiederholungsangriff meiner signierten JWTs verhindern?

Ich habe eine zustandslose Authentifizierung über HTTP in Laravel mithilfe von JWTs implementiert.

  1. Ich sende meinen Benutzernamen/mein Passwort vom Frontend.
  2. Der Server authentifiziert den Benutzer und sendet eine signierte JWT mit einer Ablaufzeit zurück.
    • Ich verwende den HS512-Algorithmus, um mit einem privaten Schlüssel zu signieren (nur für den Server verfügbar).
  3. Das Frontend speichert das Token für zukünftige Anforderungen.
  4. Das Frontend sendet die nächste Anfrage mit dem enthaltenen Token.
  5. Der Server überprüft, ob das Token gültig und nicht abgelaufen ist, und lässt die Aktion fortgesetzt, wenn beide mit Ja versehen sind.
  6. Wenn das Token abläuft, sendet der Server eine abgemeldete Nachricht.

Alle diese Kommunikationen erfolgen über HTTPS.

Ich kann also sehen, dass dies unter folgenden Punkten sicher ist:

  • Angreifer können aufgrund von HTTPS keinen Datenverkehr abhören und das JWT-Token stehlen.
  • Angreifer können keine ungeraden Token generieren und senden, da der Server die Signatur mithilfe seines privaten Schlüssels überprüft.
  • Angreifer können nicht ändern, welcher Benutzer (und damit die Rolle + Berechtigungen des Anforderers) die Anforderung stellt, da dies Teil des Anspruchs sub im Token ist.

Aber ich habe zwei Fragen:

  1. Was ist, wenn sich auf dem Computer oder dem Mobiltelefon des Benutzers ein Virus befindet und ein gültiges Token von RAM oder vom Browser) gestohlen wurde? Es kann dann weitere Anfragen senden und diese werden akzeptiert überhaupt eine Möglichkeit, sich dagegen zu schützen?
  2. Gibt es eine andere Möglichkeit, dieses System anzugreifen, die ich nicht sehe?
30
Aditya M P

Der jti -Anspruch wie beschrieben hier ist ein optionaler Mechanismus, um weitere Wiederholungsangriffe zu verhindern. Aus der Spezifikation:

4.1.7. Anspruch "jti" (JWT ID)

Der Anspruch "jti" (JWT ID) stellt eine eindeutige Kennung für das JWT bereit. Der Bezeichnerwert MUSS so zugewiesen werden, dass eine vernachlässigbare Wahrscheinlichkeit besteht, dass derselbe Wert versehentlich einem anderen Datenobjekt zugewiesen wird. Wenn die Anwendung mehrere Emittenten verwendet, MÜSSEN Kollisionen zwischen Werten verhindert werden, die auch von verschiedenen Emittenten erstellt wurden. Der Anspruch "jti" kann verwendet werden, um zu verhindern, dass die JWT wiedergegeben wird. Der Wert "jti" unterscheidet zwischen Groß- und Kleinschreibung. Die Verwendung dieses Anspruchs ist OPTIONAL.

Dies macht Ihren Server letztendlich statusbehaftet, verhindert jedoch unbegrenzte Wiederholungen, wenn Sie anomales Verhalten feststellen oder wenn ein Benutzer verdächtige Aktivitäten meldet. Stellen Sie sich das folgende Szenario vor.

  1. Ein Benutzer meldet sich an. Ihr Server generiert eine JWT und speichert die Signatur sowie einige Metadaten (die Benutzer-ID und den Typ des Clients, der die Anforderung möglicherweise stellt, sowie jti).
  2. Benutzer meldet verdächtiges Verhalten.
  3. Die Anwendung "meldet" den Benutzer aller Geräte ab, indem alle JWTs im Backend-Speicher gelöscht werden, der diesem Benutzer zugeordnet ist. Jetzt kann die Anwendung sagen: "Ich weiß, dass Sie eine gültige Signatur haben, aber ich akzeptiere sie nicht, weil ich sie nicht erstellt habe."
    • Wenn Ihre Metadaten präzise genug sind, können Sie mit jti und zusätzlichen Informationen beispielsweise nur den Benutzer von bestimmten Geräten abmelden.

Wie oben erwähnt, macht dies Ihren Server unweigerlich zustandsbehaftet. Dies verhindert auch nicht vollständig Wiederholungsangriffe, kann jedoch weitere derartige Angriffe beenden, nachdem einer erkannt wurde.

Eine alternative/zusätzliche Methode kann Wiederholungsangriffe bis zu einem gewissen Grad vollständig verhindern, wobei das Risiko potenzieller Unannehmlichkeiten für den Benutzer besteht. Machen Sie die IP-Adresse des Benutzers zu einem Teil des Anspruchs UND speichern Sie die Metadaten beim Anmelden und überprüfen Sie, ob die IP mit dem JWT die erwartete ist. Dies kann für einen Benutzer frustrierend sein, der sagt, dass er sowohl von zu Hause aus als auch in einem Café arbeitet, aber es kann eine akzeptable Voraussetzung für Hochsicherheitsanwendungen sein.

23
bretmattingly

Wenn Code im selben Kontext wie Ihre Webanwendung ausgeführt wird, unabhängig davon, ob er Teil eines XSS-Angriffs im Browser oder Malware/Virus auf dem Computer des Benutzers war, ist es schwierig (unmöglich?), Diese Anforderungen von Ihren zu unterscheiden besitzen.

Wenn der Angreifer Zugriff auf den Computer hat, kann er auch nur die Daten aus den normalen Anforderungen Ihrer Anwendungen an Ihren Server stehlen.

Möglicherweise könnten Sie eine serverseitige Analyse des Intrusion Detection-Stils durchführen: z. auf eine hohe Anzahl von Anfragen oder Artikelzahlen prüfen; Erzwingen Sie ein benutzerdefiniertes Verweisschema, bei dem Sie wissen, welche Komponenten Ihrer Webanwendung Datenanforderungen stellen. Dann vielleicht eine erneute Authentifizierung auslösen, wenn Sie anomales Verhalten feststellen? Sie benötigen außerdem eine serverseitige Methode, um Ihre JWT über dem in die JWT eingebetteten exp abzulaufen.

4
Kevin Hakanson

Warum nicht eine Datums- und Uhrzeit als Nutzlast und Ablauf haben? Sie müssen die Nutzdaten nicht ändern, und die Anwendungslogik kann das Token ablaufen lassen. Oder verwenden Sie ein neues Geheimnis, das auf einer Blattnatur basiert (ähnlich DUKPT ), damit eine neue Tokenanforderung die alte ungültig macht.

1
TheBB