Los formularios web de Asp.net no generan un nuevo identificador de sesión si un usuario cierra la sesión y vuelve a iniciarla. ¿Se trata de un riesgo de seguridad importante? Estamos utilizando SSL.
Los formularios web de Asp.net no generan un nuevo identificador de sesión si un usuario cierra la sesión y vuelve a iniciarla. ¿Se trata de un riesgo de seguridad importante? Estamos utilizando SSL.
En ASP.NET es normal que reutilice un ID de sesión . En cuanto a los datos almacenados en la sesión, si desea asegurarse de que no se pueda acceder a los datos una vez que el usuario cierre la sesión, puede llamar a Session.Abandon () en su funcionalidad de cierre de sesión. Pero incluso si no llama a Abandon, la sesión no es más vulnerable de lo que es mientras el usuario está conectado. Abandonar simplemente lo obliga a limpiarlo antes del tiempo que demore una sesión no utilizada en caducar (creo que el valor predeterminado es 20 minutos). Todavía es una buena idea llamar a Abandon para evitar el secuestro de la sesión después de que alguien cierre la sesión y se aleje de una computadora compartida.
Deberíamos aclarar una cosa antes de mover una:
Esto no significa que sea seguro, pero tampoco significa que sea inseguro.
Ahora analicemos la máquina de estados de las sesiones de usuario a lo largo de toda la transacción y veamos qué sucede con los datos en la sesión:
La computadora navega al servicio web, obtiene la sesión id=X y los datos de la sesión se almacenan en la base de datos como id = X, session_data = {"User": null, "IP_address":..., "Mac":..., "Other_device_specific_info":...}
El usuario inicia sesión y los datos de sesión en la base de datos se actualizan como UPDATE sessions SET session_data->user = Y WHERE id = X; . La sesión se ha actualizado para reflejar los cambios y los cambios de permisos, pero no es necesario actualizar la ID de la sesión porque es la misma máquina, en la misma visita .
El usuario hace algunas cosas y el session_data se actualiza de nuevo, estableciendo otros valores en él que quieren rastrear.
Ahora el usuario cierra la sesión y la sesión destruye los datos, pero mantiene la ID y realiza una nueva sesión con la misma ID porque es la misma máquina en la misma visita y ahora se ve como id = X, session_data = {"User": null, "IP_address":...} , que es idéntico a la sesión original, sin usuario.
Ahora un usuario diferente inicia sesión y hacemos lo mismo otra vez.
Dado que la ID de la sesión fue efímera / se agotó el tiempo, finalmente se destruirá, y cuando la máquina vuelva a visitarla, tendrá una nueva ID de sesión.
Como puede ver, siempre que el back-end se haya diseñado correctamente, usar la misma ID de sesión no es un problema en absoluto. TI (tanto él como TI) sería un problema si los mismos datos de sesión fueron reutilizados.
Todo esto supone que los datos de la sesión y la identificación se rastrean correctamente y que el servicio web no es vulnerable debido a que la identificación de la sesión está asociada a la máquina y no al usuario.
El hecho de que una ID de sesión esté vinculada a una máquina y no a un usuario, no significa que se haya configurado mal. Simplemente significa que probablemente también estén rastreando lo que los usuarios han usado en qué máquinas, por cuánto tiempo con fines métricos.
Probablemente deberías buscar en Google estos términos solo para asegurarte de que tu configuración sea segura
Sí, esto podría dar lugar a una vulnerabilidad de fijación de sesión .
Diga que su sitio está en example.com y permite que los usuarios suban sus propias páginas a usercontent.example.com para protegerse contra las secuencias de comandos entre sitios.
Puede pensar que las cookies en example.com están a salvo de cualquier secuencia de comandos que se ejecute en usercontent.example.com porque la flag de solo host se establece de forma predeterminada en las cookies de su sesión. Sin embargo, un atacante podría llevar a cabo un ataque de la siguiente manera:
El atacante visita example.com y obtiene un ID de sesión, ella lo toma nota.
El atacante carga algo de contenido en usercontent.example.com , incluido algo de JavaScript para establecer una cookie en el nivel example.com para establecer el ID de sesión en ella.
El atacante incita a un usuario administrador en example.com a que visite la página del atacante en http://usercontent.example.com/evil_page .
Ahora el atacante y la víctima tienen el mismo ID de sesión. El atacante recibió la identificación de la sesión en el servidor, la víctima recibió la identificación de la sesión en la página perversa del atacante.
El atacante espera a que la víctima inicie sesión en example.com . Como el sitio no rota los ID de sesión, el atacante también iniciará sesión como administrador.
Voila: un ataque de fijación de sesión.
Si esto es posible o no con su aplicación de formularios web, depende de si utiliza la autenticación de formularios o la identificación de sesión para rastrear las sesiones de los usuarios. Consulte esta respuesta . La autenticación de formularios genera un token nuevo para cada inicio de sesión, por lo que no debe ser vulnerable. Sin embargo, si la sesión también se usa y se confía al iniciar sesión, un atacante también puede aprovecharla para controlar maliciosamente a un administrador mediante la fijación de la sesión, dependiendo de la funcionalidad del sitio.
Lea otras preguntas en las etiquetas session-management