Spring-Sicherheit Ungültiger Token (Serie / Token), der sich nicht merkt. Impliziert vorherigen Cookie-Diebstahl-Angriff

7

Ich habe eine GWT-Anwendung, die Spring Security3.1.2 in einem Tomcat 7 ausführt. Ich benutze UsernamePasswordAuthenticationFilter und PersistentTokenBasedRememberMeServices, um Logins auf der DB persistent zu halten. Außerdem verwende ich Tomcat PersistentManager, um Sitzung auch in DB zu speichern. Jetzt ist mein Problem, dass jedes Mal, wenn ich versuche, mich anzumelden, ungültige Erinnerung-mich-Token (Serie / Token) Mismatch CookieTheftException (ich fügte den Stapel unten). Ich habe versucht, die Sitzung aus tomcat_sessions Tabelle wie folgt zu löschen

  1. tomcat herunterfahren
  2. Löschen von Datensätzen aus tomcat_sessions-Tabelle
  3. start tomcat
  4. versuchen Sie, sich bei der Anwendung anzumelden, wo ich die CookieTheftException erneut bekomme ...

Ich habe auch bemerkt, dass tomcat_sessions auch nach dem Löschen aller Datensätze in der tomcat_sessions-Tabelle und beim Neustart von tomcat mit der gesamten zuvor gelöschten Sitzung gefüllt wird ...

ich löschte auch alle Datensätze in Spring persistent_logins Tabelle und deaktiviert Tomcat PersistentManager, aber immer noch das gleiche Problem ...

irgendeine Idee, was könnte das Problem sein? Danke

%Vor%     
Sameeh Harfoush 18.11.2013, 16:46
quelle

3 Antworten

21

Nur damit wir auf der gleichen Seite sind, werde ich mir erst eine Minute Zeit nehmen, um zu erklären, wie ich diesen persistenten Token-Mechanismus verstehe.

Von Grund auf neu starten (keine Einträge in der Tabelle persistent_logins ):

Bei erfolgreicher Anmeldung: Ein persistentes Token wird für den Benutzer mit einem zufälligen Hash erstellt. Ein Cookie wird für den Benutzer mit den Token-Details erstellt. Für den Benutzer wird eine Sitzung erstellt.

Solange der Benutzer noch eine aktive Sitzung hat, wird bei der Authentifizierung die Funktion "remember me" nicht aufgerufen.

Nach Ablauf der Benutzersitzung: Die Erinnerungsfunktion tritt ein und verwendet den Cookie, um das beständige Token von der Datenbank abzurufen. Wenn das persistente Token mit dem des Cookies übereinstimmt, sind alle glücklich, wenn der Benutzer authentifiziert wird, ein neuer zufälliger Hash generiert und das persistente Token mit diesem aktualisiert wird und der Cookie des Benutzers für nachfolgende Anfragen aktualisiert wird.

Aber wenn das Token aus dem Cookie nicht mit dem des persistenten Tokens übereinstimmt, erhalten Sie eine CookieTheftException. Der häufigste Grund dafür, dass die Token nicht übereinstimmen, ist, dass zwei oder mehr Anfragen in schneller Folge abgefeuert wurden, wobei die erste Anfrage durchkommt und den neuen Hash für die folgenden Anfragen generiert, aber die zweite Anfrage weiterhin das alte Token hat es und damit ergibt sich die Ausnahme.

Um die CookieTheftException weitgehend zu vermeiden, stellen Sie sicher, dass Anforderungen an den Inhalt Ihrer Webanwendung (z. B. Bilder, Schriftarten, Skripts usw.) keine Springs-Authentifizierungsfilter durchlaufen. Fügen Sie dazu einfach ein weiteres <http> config oberhalb Ihrer normalen Sicherheitskonfiguration hinzu und geben Sie an, dass keine Sicherheit für Anfragen an Ihre Ressourcen gewünscht wird (verwenden Sie Ihren relevanten Pfad anstelle von /resources/** ):

%Vor%

(Für Java Config siehe hier: Wie definiere ich? http "security = 'none' in JavaConfig? )

Wenn Sie das Token eines Benutzers aus der Datenbank löschen (und deren Sitzung abgelaufen ist), wird der Benutzer bei der nächsten Anfrage abgemeldet. Was Sie über Ihre persistenten Tokens (in der Tabelle persistent_logins ) sagen, die automatisch neu erstellt werden, macht wenig Sinn und ich bezweifle sehr, dass dies der Fall ist. Die Methode PersistentTokenRepository createNewToken(PersistentRememberMeToken token) wird nur beim Login-Erfolg aufgerufen.

Schließlich, wenn Sie immer noch die Ausnahme erhalten, hilft es, die Quellen für PersistentTokenBasedRememberMeServices anzuhängen und einen Unterbrechungspunkt in die Methode processAutoLoginCookie zu setzen, um zu sehen, welche Anfrage die CookieTheftException verursacht.

Ich hoffe, das hilft.

    
Markus Coetzee 18.11.2013 19:16
quelle
2

Ich hatte denselben Fehler und bemerkte, dass er versuchte, sich automatisch bei jeder Anfrage anzumelden, bei der die Sicherheitskette ignoriert wurde. Sie können sehen, welche durch

%Vor%

Danach bemerke ich, dass js-Dateien und CSS-Dateien die Sicherheitskette übersprungen haben, habe diese Mappings entfernt und erinnere mich, dass ich anfing zu arbeiten, wie es sollte.

%Vor%     
Johann 11.04.2014 19:54
quelle
1

Der fehlende Teil für meine Konfigurationen war RememberMeAuthenticationProvider. ( Ссылка )

Bitte beachten Sie, dass sich das Paket für RememberMeAuthenticationProvider geändert hat und nicht mit den Dokumenten identisch ist.

Vergessen Sie nicht, denselben Schlüssel für PersistentTokenBasedRememberMeServices und RememberMeAuthenticationProvider

zu definieren

Dies ist meine Konfiguration:

%Vor%

Die Antwort von Markus Coetzee hat mir wirklich alles klargemacht. Danke!

    
bentzy 12.03.2014 08:00
quelle

Tags und Links