Spring Security/JSF/Hibernate Accidental Session Hijacking su Tomcat?

Question

Qualcosa di molto strano e imbarazzante mi è successo l'altro giorno e non ho parole per descrivere quello che è successo.

La mia app esegue Spring 3 integrata con JSF 2.1, Hibernate 4, Spring Security tutte su Tomcat 7. Ero al telefono con qualcuno di importante di livello C e eravamo contemporaneamente contemporaneamente nello stesso ambiente di test su le stesse pagine. Andò a navigare verso una pagina alla quale stavo navigando più o meno nello stesso momento in cui la sua pagina si avvicinò con i miei dettagli dell'account personale. Non gli credevo, quindi sono andato nel suo ufficio e abbastanza sicuro, in qualche modo è stato registrato come account per il quale non ha la password.

L'applicazione avrà protetto le informazioni sulla salute del paziente, quindi mi è stato ordinato di fornire a C-level un rapporto completo con quello che era successo, ma non riesco a trovare come fosse possibile. Ho setacciato il codice base e non ho trovato nulla. Ho provato a riprodurre lo scenario esatto in più occasioni e non sono mai riuscito a riprodurlo. Non ho nemmeno un'ipotesi plausibile di cui sono felice.

Penso che ci potrebbe essere stata qualche operazione thread non sicura sulle sessioni memorizzate nell'implementazione del contesto dell'applicazione Tomcat, ma non ho modo di provarlo se non è riproducibile. Ho anche pensato che dal momento che Spring Security funziona come un filtro in vista di altre richieste e in avanti, forse uno degli altri filtri servlet ha interferito. Gli altri due erano il filtro Caricamento file Primefaces e il filtro SEO Omnifaces che avevo aggiunto di recente.

Il filtro Omnifaces ha effettivamente interferito con il filtro File Upload di Primefaces che ho dovuto armeggiare con la sua configurazione in modo che entrambi giocassero bene l'uno con l'altro, quindi mi sento ancora che potrebbe essere anche una possibilità.

Esistono bug noti con Spring Security che hanno causato problemi simili? Esistono problemi noti con Tomcat in merito al servizio accidentale dello stato della sessione da ApplicationContext? Qualcun altro ha avuto un problema simile o ha avuto un'idea unica di questo?

EDIT: Poco dopo questo distacco ho trovato questo, pubblicato solo pochi giorni fa:

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

E 'quasi esattamente la stessa messa a punto come ho Apache httpd + mod_jk plug-in di fronte Tomcat così certamente io non sono pazzo :)

UPDATE:

sono stato in grado di riprodurre il problema in m y ambiente di sviluppo senza mod_jk o Apache in primo piano, quindi posso tranquillamente escluderlo come colpevole.

Answer 1

ho capito :)

Era una specie di un errore di sviluppatore, ma è anche un comportamento di default ridicola di primavera. Avevo un bean gestito JSF chiamato SessionBean che ho dichiarato come @SessionScope. Quando si integra JSF e Spring, l'iniezione delle dipendenze JSF è in conflitto con l'iniezione delle dipendenze di Spring, quindi Spring ha riscritto il modulo JSF che gestisce quello invece di avvolgere semplicemente Spring DI. Quindi quando dichiaro un bean gestito da JSF come Session Scoped, devo anche dargli un'annotazione @Controller in modo che venga riconosciuta anche come Spring Bean.

Si scopre che la primavera tuttavia non comprende le annotazioni JSF @RequestScoped e @SessionScoped.Spring ha una sua annotazione chiamata semplicemente @Scope(value = "request|session|singleton?|etc...").

Poiché Spring non ha riconosciuto l'ambito JSF che ho impostato, ha gestito il bean appena creato come predefinito per bean, come SINGLETON.

Quindi, ogni volta che qualcuno ha effettuato l'accesso, è stata sovrascritta la proprietà che ho utilizzato per memorizzare nella cache l'utente che ho effettuato il login che ho scaricato dal Principal di autenticazione. Quindi tutti quelli che hanno fatto qualcosa sono stati registrati come utenti diversi.

Nice of Spring a proposito di vi avverte che avete mal interpretato il vostro maledetto bean.

Grazie per l'aiuto di tutti, spero che questo avvantaggi i futuri visitatori!