En la API de Java Servlet, ¿qué se hace para garantizar que no se robe el ID de sesión de alguien?¿Qué impide que la identificación de HttpSession sea robada?
Por ejemplo, si tuviera una sesión activa y alguien consiguiera de alguna forma una identificación de sesión, ¿podrían usarla?
Nada lo impide. Obtiene la ID de la sesión, puede participar en la sesión.
En el caso habitual de las cookies esto no es un riesgo en sí mismo. El atacante no debería ser capaz de leer cookie de sesión de un usuario a menos que:
que tienen man-in-the-middle capacidad, en cuyo caso usted tiene problemas mucho peores que sólo los identificadores de sesión;
has dejado un agujero de scripts entre sitios, en cuyo caso tienes problemas mucho peores que solo los ID de sesión;
usted es vulnerable a los ataques de recombinación de DNS/cocción de dominios cruzados, en cuyo caso debe solucionarlo permitiendo únicamente solicitudes conocidas Host:.
(Si bien se puede tratar sesiones atar a direcciones IP, se corre el riesgo rompiendo sesiones válidos debido a, por ejemplo proxies round-robin. IPs se pueden utilizar como parte de una estrategia más amplia para la detección de actividades sospechosas, pero en el público Internet no es una buena idea pedir siempre que cada solicitud en una sesión proceda de la misma IP.)
Lamentablemente en Servlet hay otro caso, aparte de las cookies: jsessionid= parámetros. Dado que aparecen en la propia URL, eso hace que mucho tenga más fugas (por ejemplo, a través de referencias y enlaces pegados). Y eso dista mucho de ser el único problema práctico con ID de sesión de parámetros. Desordenan la navegación y destruyen el SEO.
En mi opinión jsessionid= Las URL son uno de los peores errores tempranos de Servlet, una desacreditada estrategia de reserva de cookies de antaño que no debería usarse para nada. Pero ciertamente no se les debe permitir el acceso a datos privilegiados; considere usar Autenticación HTTP básica en su lugar si necesita un mecanismo alternativo para los navegadores que no son compatibles con las cookies.
En Servlet 3.0 puede desactivar jsessionid= URLs fácilmente usando <session-config> en el web.xml; desafortunadamente en las versiones anteriores, se deja de lado con filtros si desea deshabilitar la función correctamente.
Sí, podrían usarlo. No se hace nada para protegerlo a menos que ponga todo su tráfico sobre SSL.
Así es como funciona Firesheep, que recientemente llamó mucho la atención para facilitar el robo de sesión.
¿Realmente la única solución es transferir todos los datos a través de HTTPS? ¿No hay marcos o soluciones conocidas? E incluso si todos los datos se transfieren a través de HTTPS, ¿no podría alguien escribir un programa para intentar adivinar una ID de sesión? –
Sí, lo es, cualquier información que envíe al usuario para que pueda enviarla podría ser interceptada, por lo que encriptar realmente es la única forma de detenerla. En cuanto a adivinar, usualmente las identificaciones de sesión están diseñadas para ser lo suficientemente difíciles como para adivinar que esto no es práctico. –
Sí, la identificación de sesión le da a alguien acceso a la sesión correspondiente.
Puede almacenar la IP utilizada durante el inicio de sesión en la sesión y cuando los cambios de IP requieren que el usuario vuelva a iniciar sesión. Además (aunque no estoy seguro si eso se hace automáticamente) podría hacer lo mismo con el Agente de usuario, sin aumentar la seguridad contra ataques maliciosos, solo contra usuarios tontos que regalan su sessionid accidentalmente si se pasa a través de GET y no de una cookie.
+1 para la configuración de sesión en servlet 3.0 – Bozho