it-swarm-es.com

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

¿La regeneración de la ID de sesión en cada solicitud mitiga la probabilidad de un Secuestro de sesión suficiente para que valga la pena implementar?

Me imagino que combinar una verificación para REMOTE_ADDR versus REMOTE_ADDR almacenada en las variables de sesión, junto con un tiempo de espera de inactividad de 30 minutos y una identificación de sesión en constante cambio debería mitigar el riesgo a un nivel aceptable.

Además, ¿hay otras preocupaciones con la regeneración de un id de sesión? ¿Necesito destruir explícitamente la sesión anterior para cada nueva regeneración?

Finalmente, ¿la regeneración de la identificación de la sesión en cada solicitud se volvería demasiado intensiva en recursos en una implementación grande para justificar las ventajas de seguridad?

17
Purge

He visto implementaciones que probaron este enfoque y terminaron tirando de él porque sí, puede causar problemas de recursos y condiciones de carrera en granjas web. Al principio, parece una buena idea, pero también puede hacer que su aplicación sea más propensa a ataques de denegación de servicio si el proceso de regeneración es demasiado criptográfico. La respuesta es pregenerar 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 asegurar las variables de ID de sesión es

  • usar SSL
  • solo genere la ID de sesión autenticada después inicio de sesión exitoso a través de SSL, de lo contrario, será vulnerable a la fijación de la sesión
  • generar tokens criptográficamente aleatorios e indiscutibles
  • caducar ID de sesión con frecuencia
  • caduca correctamente y luego del lado del servidor al cerrar sesión
  • marque la cookie de ID de sesión como HttpOnly y 'segura'
12
Weber

Supongo que depende de cómo implemente todo esto, pero lo más probable es que se encuentre con una gran cantidad de problemas de tiempo de ejecución que rastrean los ID de sesión cambiantes.

¿Ayudaría? Realmente no. Puede suplantar REMOTE_ADDR, y capturar la identificación de la sesión antes de que cambie es bastante sencillo: capturarlo y usarlo antes de que el usuario realice otra solicitud.

La mejor idea sería encriptar los valores de la cookie, solo conectarse a través de HTTPS, establecer la vida útil de la cookie en algo muy corto/establecer la vida útil de la sesión en algo muy corto, configurar las cookies en HttpOnly (no accesible a través de JavaScript, solo parte sin embargo, de los navegadores más nuevos), y finalmente, use la administración de la sesión del marco de trabajo; no utilice el suyo propio. :)

4
Steve

Debe asegurarse de que su sesión caduque y que los tokens sean, por supuesto, 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 utiliza http normal a partir de ese momento, regenerando sesiones de cada solicitud posterior, 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 de alguna manera. Realmente necesitas asegurarte de que el transporte de toda la sesión evite las escuchas y el secuestro, para lo cual SSL fue diseñado.

El uso de direcciones remotas también es bastante discutible cuando se trata de firewalls 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 máquina que podría iniciar sesión, podría emitir un certificado de cliente, que el usuario cargaría en su navegador, y el servidor lo solicitaría durante la negociación SSL .

1
Troy Rose

El mejor que he visto en el uso común regenera el identificador de sesión después de un inicio de sesión seguro y asocia el identificador con la máquina del cliente. El contenedor de seguridad de la aplicación busca inicios de sesión concurrentes (no permitir uno nuevo hasta que el anterior haya terminado y la ID haya expirado) expira la ID al cerrar o cerrar sesión del navegador y también tiene un tiempo de expiración bastante corto (10 minutos)

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

0
Rory Alsop