tutorial example con hibernate tomcat spring-security omnifaces session-hijacking

example - Spring Security/JSF/Hibernate Secuestro de sesión accidental en Tomcat?



primefaces con hibernate (1)

Me lo imaginé :)

Fue una especie de error de desarrollador, pero también es un comportamiento ridículo por defecto de Spring. Tenía un Bean gestionado JSF llamado SessionBean que declaraba como @SessionScope . Cuando se integran JSF y Spring, la inyección de dependencias JSF entra en conflicto con la inyección de dependencia de Spring, por lo que Spring reescribió el módulo JSF que maneja eso para simplemente ajustar Spring DI en su lugar. Entonces, cuando declaro un JSF ManagedBean como Session Scoped, también debo darle una anotación @Controller para que también se reconozca como Spring Bean.

Resulta que Spring no comprende las anotaciones JSF @RequestScoped y @SessionScoped . Spring tiene su propia anotación llamada simplemente @Scope(value = "request|session|singleton?|etc...") .

Debido a que Spring no reconoció el alcance de JSF que establecí, trató el bean recién creado en su valor predeterminado para beans, como SINGLETON.

Así que cada vez que alguien iniciaba sesión, estaba sobrescribiendo la propiedad que usaba para almacenar en caché al usuario que había ingresado y que había obtenido del Principal de autenticación. Luego, todos los que hicieron algo iniciaron sesión como un usuario diferente.

Qué bueno de Spring, por cierto, para advertirte que has configurado mal tu maldito frijol.

Gracias por la ayuda de todos, espero que esto beneficie a los futuros visitantes!

El otro día me pasó algo muy extraño y vergonzoso y no tengo palabras para describir lo que sucedió.

Mi aplicación funciona con Spring 3 integrado con JSF 2.1, Hibernate 4, Spring Security todo en Tomcat 7. Estaba hablando por teléfono con alguien importante de C-level y ambos estábamos simultáneamente en el entorno de prueba al mismo tiempo en las mismas páginas. Fue a navegar a una página con la que estaba navegando casi en el mismo momento en que aparecieron los detalles de mi cuenta personal en su página. No le creí, así que me dirigí a su oficina y, de hecho, de alguna manera estaba conectado como mi cuenta para la cual no tiene la contraseña.

La aplicación habrá protegido la información de salud del paciente, por lo que se me ordenó proporcionar un informe completo de C-level con lo que sucedió, pero no puedo encontrar cómo fue posible. Revisé la base de códigos y no encontré nada. Traté de reproducir el escenario exacto en múltiples ocasiones y nunca pude reproducirlo. Ni siquiera tengo una suposición educada de la que estoy contento.

Creo que quizás haya habido alguna operación de subprocesos inseguros en las sesiones almacenadas en la implementación del contexto de la aplicación Tomcat, pero no tengo forma de probar esto si no es reproducible. También pensé que, dado que Spring Security funciona como un filtro antes que otras solicitudes y reenvíos, quizás uno de los otros filtros de servlets interfirió. Los otros dos fueron el filtro Carga de archivos Primefaces y el filtro SEO Omnifaces que agregué recientemente.

El filtro Omnifaces de hecho interfirió con el filtro Primefaces File Upload que tuve que retocar con su configuración para que los dos jugaran bien entre ellos, así que todavía siento que eso también podría ser una posibilidad.

¿Hay algún error conocido con Spring Security que haya causado problemas similares? ¿Existen problemas conocidos con Tomcat con respecto a la publicación accidental de un estado de sesión incorrecto desde ApplicationContext? ¿Alguien más ha experimentado un problema similar o tiene alguna idea única sobre esto?

EDITAR: Poco después de publicar esto encontré esto, publicado hace solo unos días:

Mezcla de sesiones - apache httpd con mod_jk, tomcat, seguridad de primavera - que sirve datos de otros usuarios

Es casi exactamente la misma configuración que tengo el plugin Apache httpd + mod_jk en frente de Tomcat, así que seguramente no estoy loco :)

ACTUALIZAR:

Pude reproducir el problema en mi entorno de desarrollo sin mod_jk o Apache al frente, por lo que puedo descartar esto de manera confiable como el culpable.