6

Etwas seltsames und peinliches passiert mir neulich und ich habe keine Worte um zu beschreiben, was passiert ist.Spring Security/JSF/Hibernate Accidental Session Hijacking auf Tomcat?

Meine App läuft Spring 3 integriert mit JSF 2.1, Hibernate 4, Spring Security alle auf Tomcat 7. Ich war am Telefon mit jemandem wichtig aus C-Level und wir waren beide gleichzeitig in der Testumgebung zur gleichen Zeit die gleichen Seiten. Er ging, um zu einer Seite zu navigieren, zu der ich gerade im selben Moment navigiert war, als seine Seite mit meinen persönlichen Kontodetails auftauchte. Ich glaubte ihm nicht, also ging ich zu seinem Büro und tatsächlich war er irgendwie als mein Account angemeldet, für den er kein Passwort hatte.

Die Anwendung wird Patientengesundheitsinformationen geschützt haben, so dass ich beauftragt wurde, C-Level einen vollständigen Bericht mit dem, was passiert war, zu liefern, aber ich kann nicht finden, wie dies möglich war. Ich habe die Codebasis durchforstet und nichts gefunden. Ich habe versucht, das genaue Szenario mehrfach zu reproduzieren und konnte es nie reproduzieren. Ich habe nicht einmal eine fundierte Vermutung, mit der ich glücklich bin.

Ich denke, vielleicht gab es einige unsichere Thread-Operation auf Sitzungen in der Tomcat Application Context-Implementierung gespeichert, aber ich habe keine Möglichkeit, dies zu beweisen, wenn es nicht reproduzierbar ist. Ich dachte auch, dass Spring Security als Filter vor anderen Anfragen und Weiterleitungen arbeitet, dass vielleicht einer der anderen Servlet-Filter interferiert. Die anderen beiden waren der Primefaces File Upload Filter und der Omnifaces SEO Filter, den ich kürzlich hinzugefügt hatte.

Der Omnifaces-Filter hat tatsächlich den Datei-Upload-Filter von Primefaces beeinflusst, den ich mit seiner Konfiguration basteln musste, damit die beiden gut miteinander spielen, also habe ich immer noch das Gefühl, dass das eine Möglichkeit ist.

Gibt es bekannte Bugs mit Spring Security, die ähnliche Probleme verursacht haben? Gibt es bekannte Probleme mit Tomcat, dass versehentlich der falsche Sitzungsstatus aus dem ApplicationContext ausgegeben wurde? Hat jemand anderes ein ähnliches Problem oder einen einzigartigen Einblick in dieses Problem?

EDIT: Kurz danach Veröffentlichung fand ich dieses, geschrieben nur wenige Tage vor:

Session mix up - apache httpd with mod_jk, tomcat, spring security - serving data of other user

Es ist fast genau die gleiche Einstellung wie ich Apache + mod_jk Plugin vor Tomcat so sicher bin ich nicht verrückt :)

UPDATE:

ich konnte das Problem in m reproduzieren y Entwicklungsumgebung ohne mod_jk oder Apache vor, so kann ich dies als Täter verlässlich ausschließen.

+1

Wenn diese Leute die Konten anderer Leute hier auf SO gesehen haben, ist es auf über aggressive Zwischenspeicherung durch einen ISP zurückzuführen. Gibt es einen Proxy/Cache zwischen Ihnen und der Anwendung? – ChrisF

+0

@ChrisF Nur Apache delegiert an den Tomcat-Connector mod_jk. Es ist ein einzelner Server, der sowohl Apache als auch Tomcat ausführt. Vielleicht spuckt Apache etwas? Ich werde versuchen, das zu entfernen und zu sehen, ob ich den Fehler reproduzieren kann. –

Antwort

4

ich es herausgefunden :)

Es Art von Entwickler Fehler war, aber es ist auch eine lächerliche Standardverhalten des Frühlings. Ich hatte eine JSF Managed Bean namens SessionBean, die ich als @SessionScope deklarierte. Wenn Sie JSF und Spring integrieren, steht die Injektion der JSF-Abhängigkeit in Konflikt mit der Spring-Abhängigkeitsinjektion, also hat Spring das JSF-Modul, das das Wrapping von Spring DI übernimmt, neu geschrieben. Wenn ich also ein JSF ManagedBean als Session Scoped deklariere, muss ich ihm auch eine @Controller Annotation geben, damit es auch als Spring Bean erkannt wird. Es stellt sich heraus, dass Spring die JSF @RequestScoped und @SessionScoped Annotationen nicht versteht.Der Frühling hat seine eigene Anmerkung, die einfach @Scope(value = "request|session|singleton?|etc...") genannt wird.

Da Spring den von mir festgelegten JSF-Bereich nicht erkannte, behandelte er die neu erstellte Bean in ihrer Standardeinstellung für Beans als SINGLETON.

Jedes Mal, wenn sich jemand anmeldete, überschrieb er die Eigenschaft, die ich zum Zwischenspeichern des angemeldeten Benutzers verwendet hatte, den ich vom Authentifizierungs-Principal abgerufen hatte. Dann wurde jeder, der etwas getan hat, als anderer Benutzer angemeldet.

Nice of Spring auf dem Weg zu warnen Sie, dass Sie Ihre verdammte Bohne falsch konfiguriert haben.

Vielen Dank für die Hilfe von jedem, ich hoffe, dies kommt zukünftigen Besuchern zugute!