Spring Security / JSF / Versehentliches Hijacking von Sitzungen im Ruhezustand auf Tomcat?

Neulich ist mir etwas sehr Merkwürdiges und Peinliches passiert, und ich habe keine Worte, um zu beschreiben, was passiert ist.

Meine App läuft mit Spring 3, integriert in JSF 2.1, Hibernate 4 und Spring Security, alle auf Tomcat 7. Ich telefonierte mit einer wichtigen Person von C-Level und wir waren beide gleichzeitig in der Testumgebung zur selben Zeit auf denselben Seiten. Er navigierte zu einer Seite, zu der ich gerade navigierte, als seine Seite meine persönlichen Kontodaten enthielt. Ich habe ihm nicht geglaubt, also bin ich rüber in sein Büro gegangen und sicher war er irgendwie als mein Account angemeldet, für den er kein Passwort hat.

Die Anwendung verfügt über geschützte Informationen zum Gesundheitszustand des Patienten. Daher wurde mir befohlen, C-Level einen vollständigen Bericht über die Vorgänge zu übermitteln, aber ich kann nicht feststellen, wie dies möglich war. Ich durchsuchte die Codebasis und fand nichts. Ich habe mehrmals versucht, das genaue Szenario zu reproduzieren und konnte es nie reproduzieren. Ich habe nicht einmal eine begründete Vermutung, mit der ich glücklich bin.

Ich glaube, es gab möglicherweise eine unsichere Thread-Operation für Sitzungen, die in der Implementierung des Tomcat-Anwendungskontexts gespeichert wurden, aber ich kann dies nicht beweisen, wenn es nicht reproduzierbar ist. Ich dachte auch, dass da Spring Security als Filter vor anderen Anfragen arbeitet und weiterleitet, dass vielleicht einer der anderen Servlet-Filter stört. Die anderen beiden waren der Primefaces File Upload-Filter und der Omnifaces SEO-Filter, die ich kürzlich hinzugefügt hatte.

Der Omnifaces-Filter hat in der Tat den Primefaces-Datei-Upload-Filter gestört, den ich an seiner Konfiguration basteln musste, damit die beiden gut miteinander spielen konnten, sodass ich immer noch der Meinung bin, dass dies auch eine Möglichkeit sein könnte.

Gibt es bekannte Fehler bei Spring Security, die ähnliche Probleme verursacht haben? Gibt es bekannte Probleme mit Tomcat, wenn versehentlich der falsche Sitzungsstatus aus dem ApplicationContext bereitgestellt wird? Hat jemand anderes ein ähnliches Problem erlebt oder einen einzigartigen Einblick in dieses Problem?

BEARBEITEN: Kurz nachdem ich das gepostet hatte, fand ich das, das erst vor ein paar Tagen gepostet wurde:

Session-Mixup - Apache httpd mit mod_jk, Tomcat, Spring Security - Serving-Daten anderer Benutzer

Es ist fast genau das gleiche Setup wie ich Apache httpd + mod_jk plugin vor Tomcat habe, also bin ich sicher nicht verrückt :)

AKTUALISIEREN:

Ich konnte das Problem in meiner Entwicklungsumgebung reproduzieren, ohne dass mod_jk oder Apache im Vordergrund standen, sodass ich dies als Schuldigen zuverlässig ausschließen kann.

Antworten auf die Frage(1)

Ihre Antwort auf die Frage