He leído que el marco de juego resuelve el problema de la fijación de la sesión al calcular la identificación de la sesión con la clave de la aplicación, pero ¿proporciona algún mecanismo para evitar el secuestro de la sesión o se deja esto al implementador?¡Juega! marco tiene algún mecanismo integrado para evitar el secuestro de la sesión?
La documentación del juego tiene una buena sección de seguridad, así que en lugar de duplicar, aquí hay un enlace - http://www.playframework.org/documentation/1.2.4/security.
Cubre
Algunos hay que aplicar a sí mismo, otros que no lo hacen.
Tu pregunta específica sobre el secuestro de sesión es automática.
La sesión es un hash de clave/valores, firmado pero no encriptado. Que significa que, mientras su secreto esté a salvo, no es posible que un tercero forje sesiones.
Gracias por la respuesta. Realmente no veo cómo el hash de los valores clave y el firmarlo contra la clave de la aplicación evita que alguien robe tu cookie y la use. Tal vez me estoy perdiendo algo? – marchaos
porque, si alguien lo manipula, no conoce el hash, por lo que el valor de hash no es válido, y Play sabe que la sesión se ha invalidado. – Codemwnci
¿Qué pasa si no lo alteran? Si olfateo tu cookie y no cambio ningún valor dentro de ella, seguramente ya que el hash aún es válido (suponiendo que esté almacenado en la cookie), puedo autenticar usando tus valores. – marchaos
No, no existe una forma integrada para evitar el secuestro de una sesión tan pronto como uno puede capturar la cookie de sesión (a través de sniffing/man en el medio). Hay algunas maneras de hacer más difícil , por ejemplo:
Una approache para hacer más difícil es: - almacena el ip/user-agent/resolution/otras cosas o un hash de eso también en la sesión ... en tu controlador verifica si el usuario que accede a tu sitio todavía recrea el mismo hash ... el único problema real es con personas que están utilizando un proxy que, por ejemplo, cambia la ip sobre la marcha debido a la agrupación.
Un pequeño truco que podría tratar de usar: (sólo funciona en los navegadores recientes) Cuando un usuario se conecta, almacenar un poco de materia en un almacenamiento local de HTML5. Modifique sus llamadas Ajax para suministrar esta información desde el almacenamiento local. Si la información falta o no es válida, puede invalidar toda la sesión. Pero deberá asegurarse de que los controles solo se apliquen a las solicitudes de navegadores HTML5.
Espero que esto ayude un poco.
Almacenar el IP y el agente de usuario es una mala idea. Consulte http://stackoverflow.com/questions/969330/including-user-ip-addr-for-hash-cookie-value-bad-idea – marchaos
sus direcciones de enlace lo que dije con "el único problema real es con personas que están usando un proxy que, por ejemplo, cambia la ip sobre la marcha debido a la agrupación ". No hay nada en contra de almacenar un hash del agente de usuario, porque si eso cambia durante una sesión, la sesión fue secuestrada. Todo depende de la cantidad de energía que esté dispuesto a poner en esto y si realmente lo vale. Cambiar o eliminar datos confidenciales solo debería ser posible siempre a través de SSL y proporcionando una contraseña. –
Hasta ahora tengo un sí y un no, por lo que obviamente hay información contradictoria aquí. – marchaos
Todavía siento que esta pregunta no ha sido respondida, pero desafortunadamente tengo que otorgar la recompensa en cualquier caso. Si alguien pudiera responder con una respuesta definitiva, sería genial. – marchaos