Secuestro de sesión - regenerar ID de sesión

He visto implementaciones que probaron este enfoque y terminaron tirando de él porque sí, esto puede causar problemas de recursos y condiciones de carrera en las granjas de servidores web. Parece una buena idea al principio, pero también puede hacer que su aplicación sea más propensa a los ataques de denegación de servicio si el proceso de regeneración es demasiado criptográfico. La respuesta es generar las ID de sesión periódicamente y mantener un caché disponible, pero luego debe administrar el caché de forma segura.

Algunas soluciones más comunes para proteger las variables de ID de sesión son

• usar SSL
• solo genere el ID de sesión autenticado después de inicio de sesión exitoso a través de SSL, de lo contrario, se volverá vulnerable a la fijación de la sesión
• generar tokens criptográficamente aleatorios e indiscutibles
• caducan los ID de sesión con frecuencia
• caduque de manera adecuada y luego del lado del servidor al cerrar sesión
• marque la cookie de ID de sesión como HttpOnly y "segura"

Supongo que depende de cómo implementarías todo esto, pero es probable que te encuentres con una gran cantidad de problemas de tiempo de ejecución que rastrean los ID de sesión cambiantes.

¿Ayudaría? Realmente no. Puede simular REMOTE_ADDR, y capturar el ID de sesión antes de que cambie es bastante sencillo: cójalo y utilícelo antes de que el usuario realice otra solicitud.

La mejor idea sería cifrar los valores de las cookies, solo conectarse a través de HTTPS, establecer la duración de la cookie en algo muy corto / establecer la duración de la sesión en algo muy breve, configurar las cookies en HttpOnly (no accesible a través de JavaScript - aunque solo una parte de los navegadores más nuevos), y finalmente, use la administración de sesiones de framework - no haga su propio rollo. :)

Debes asegurarte de que tu sesión caduque y que los tokens sean confiables y generados aleatoriamente.

Sin embargo, de todas estas respuestas, creo que el punto más fuerte es usar SSL, pero para toda la sesión.

Incluso si inicia sesión a través de SSL y usa http normal a partir de ese momento, regenera sesiones de cada solicitud subsiguiente y hace todas las cosas buenas mencionadas anteriormente, realmente no hay forma de garantizar que la sesión de un usuario no pueda ser secuestrada en algunos camino. Realmente debe asegurarse de que el transporte de toda la sesión evite las escuchas ilegales y el secuestro, para lo que se diseñó SSL.

El uso de direcciones remotas también es bastante discutible cuando se trata de cortafuegos con NAT.

Si luego necesita ir un paso más allá para asegurarse de que la máquina de un cliente en particular sea la única que pueda iniciar sesión, puede emitir un certificado de cliente, que el usuario cargaría en su navegador, y el servidor lo solicitaría durante La negociación SSL.

El mejor que he visto en el uso común regenera el identificador de sesión después del inicio de sesión seguro y asocia el identificador con la máquina cliente. La envoltura de seguridad de la aplicación comprueba si hay inicios de sesión simultáneos (no se permite uno nuevo hasta que el anterior haya finalizado y el ID haya caducado) caduque la ID al cerrar o cerrar la sesión del navegador y también tiene un tiempo de caducidad bastante corto (10 minutos)

Junto con las otras características de seguridad, fue apropiado para el propósito (una aplicación de banca de consumo en línea) sin sobrecargar el sistema.