Jetty/Tomcat encriptado almacenamiento de sesión basado en cookies?

Question

Ruby on Rails ha admitido sesiones basadas en cookies firmadas for quite some time, con algunos encrypted implementations surgiendo desde entonces. Python y PHP también tienen implementaciones.

¿Existe tal bestia para los contenedores de servlet Java Jetty o Tomcat?

Hemos recibido importantes mejoras de rendimiento en las sesiones basadas en RDBMS con la implementación de PHP en nuestro entorno agrupado, y me gustaría probar algo similar con una de nuestras aplicaciones Java (que actualmente utiliza Jetty 7).

Soy consciente de otras formas de lograr este objetivo (memcached, synchronized in-memory cachés) pero creo que para nuestra necesidades particulares de las limitaciones de este método de almacenamiento (sesiones de finalización antes de la salida, el almacenamiento en eficientes después de la cookie de tamaño 4K límite, confianza en una clave ultrasecreta del lado del servidor) son superados por el entorno de implementación más simple para esta aplicación en particular.

Si no existe una implementación, ¿alguien tiene alguna idea de por qué no lo haría? (Por ejemplo, las sesiones Java suelen ser más grandes que 4K y, por lo tanto, no son tan adecuadas para este método de almacenamiento)

Answer 1

Implementamos Session-In-Cookie y lo utilizamos con éxito en un clúster de Tomcat para permitir el intercambio de sesiones entre 20 nodos y así habilitar despliegues sin interrupción. Acabo de escribir la primera parte de una serie de dos partes sobre la implementación aquí: http://blog.shinetech.com/2012/12/18/simple-session-sharing-in-tomcat-cluster-using-the-session-in-cookie-pattern/. Esta parte trata de la implementación básica, los aspectos de seguridad se tratarán en la segunda parte.

Answer 2

No tengo conocimiento de ningún contenedor que pueda serializar una HttpSession en una cookie. Usted podría lograr este tipo de cosas implementando un Filter que podría serializar el estado de la sesión a una cookie en una respuesta a un cliente web y deserializarlo en la solicitud. Aún está sujeto a las limitaciones de cookies del lado del cliente y debe considerar cuidadosamente las implicaciones de seguridad del estado que está almacenando en el lado del cliente y cuánto confía en que el cliente presente la cookie.

Answer 3

Parece que hay dos preguntas aquí:

1. implementaciones de Java/J2EE de gestión de sesiones-efectiva sin estado.
2. Implementaciones de sesiones seguras.

En cuanto a la primera pregunta: Sí, dependiendo del tamaño de la sesión-gráfico (profundidad de anidamiento de todas las variables de sesión/objetos) la limitación de tamaño de galletas (que es efectivamente una limitación de encabezado HTTP) es un factor significativo. Si el gráfico de sesión encaja perfectamente dentro de la limitación del encabezado HTTP (que en cierta medida es configurable en el lado del servidor web) y/o puede ser aumentado con parámetros de consulta URL basados ​​en REST (para aliviar parte de la información de estado en el servidor) ... entonces una implementación de cookie es posible. Sin embargo, esto sería programático versus manejo de contenedores.

En cuanto a la segunda pregunta: Asegurar sesiones es otra cosa. La notoria cookie común de JSESSIONID en sistemas Java/J2EE es una clave token simple para la sesión en memoria o en caché de disco en el servidor de aplicaciones. Es solo una clave de mapa. Con esa clave, cualquiera puede robar o hacerse pasar por la sesión del usuario. Este es probablemente uno de los enlaces más débiles en todo el aparato de sesión administrado por contenedor. Hay productos comerciales de sesión segura disponibles que evitan el secuestro de la sesión mediante el robo de cookies, evitan los ataques de repetición (que pueden vencer a SSL capturando la repetición de la conversación de inicio de sesión encriptada para obtener una sesión) y otros vectores de ataque. Un producto del que soy consciente puede hacer esto sin cambios en el código (a través de un filtro de seguridad). Sin embargo, no conozco ningún marco general o iniciativa de código abierto para cerrar este agujero, probablemente porque requiere un nivel de experiencia que va más allá del desarrollo general de aplicaciones.