Recientemente, hemos desarrollado algunas funciones para nuestra aplicación web para permitir que un usuario permanezca conectado de forma indefinida, y estamos interesados en conocer las ramificaciones de seguridad al hacerlo. El objetivo de esto era evitar la pérdida de datos del usuario si demoran un tiempo excesivamente largo para editar una página: antes tendrían que copiar / pegar en el portapapeles una vez que la sesión expirara, ya que las POST se bloquearían y el inicio de sesión se manejaría en una pantalla diferente .
Por lo tanto, ahora detectamos si una sesión de usuario está a punto de expirar y luego le presentamos un modo que les permite hacer clic en un botón para mantener su sesión activa. Si ignoran este aviso de advertencia por un tiempo suficiente, lo reemplazaremos por un "registro de nuevo" en cuanto la sesión expire.
El primer mecanismo modal / de advertencia funciona a través de una llamada AJAX get al servidor que devuelve el tiempo hasta el cierre de sesión. Si el tiempo es inferior a 15 minutos, abrimos el modo "Mantenerme conectado", que tiene dos opciones: cerrar sesión ahora o permanecer conectado. Desconectarme hace lo obvio, permanecer conectado implica que otro AJAX llegue al servidor nuevamente, lo cual Actualiza las cookies de autenticación del usuario.
El segundo modal es más complicado: el modal bloquea una mayor interacción con la página y solo se elimina cuando se vuelve a ingresar la contraseña correcta. Somos conscientes de que un modal no protegerá realmente los datos de lectura de la página, pero esta es la naturaleza del requisito.
Los datos necesarios para que el usuario vuelva a iniciar sesión (como el nombre de usuario y la función anterior) se almacenan en texto sin formato en los campos de entrada ocultos dentro del modal. Consideramos el hash de esto, pero realmente no parecía necesario: el nombre de usuario no es particularmente crítico y la función solicitada se reevalúa al volver a iniciar sesión; no puede actualizarse a un rol al que no tiene acceso si intentó "ajustar" el POST.
El peor de los casos que hemos considerado es que alguien edita el POST con un nombre de usuario / contraseña diferente pero válido y se registra como otra persona mientras permanece en la página. Podrían leer la página, pero pueden hacerlo de todos modos. Al navegar, volverá a las pantallas correctas para el inicio de sesión "nuevo". Probablemente necesitemos un poco de trabajo para garantizar que todos los POST estén bloqueados en este escenario, pero ¿hay algo más que considerar? ¿Se puede obtener algo al obligar al usuario a volver a identificarse al escribir manualmente su nombre de usuario nuevamente?
La aplicación web es ASP.NET MVC3.
ACTUALIZAR
Gracias por los comentarios hasta ahora.
Tomamos en cuenta que no confiamos en los datos del cliente, por lo que decidimos cifrar el nombre de usuario y la función juntos y luego descifrarlos en el intento de inicio de sesión. Desde entonces, hemos descubierto que debido a las medidas de seguridad de AntiForgeryToken que ya tenemos implementadas si un usuario diferente inicia sesión, cualquier acción de publicación fallaría en la validación.
No creemos que haya un problema de uso importante con la ventana emergente, ya que el tiempo de espera se establece en 60 minutos con una advertencia de 15 minutos. Ya hemos tenido en cuenta el vencimiento deslizante que no se actualiza hasta después de la mitad del camino (http://msdn.microsoft.com/en-us/library/system.web.configuration.formsauthenticationconfiguration.slidingexpiration.aspx). Es importante recordar que todo esto se implementó para atender las quejas de los usuarios sobre la pérdida de datos: ingresan una gran cantidad de texto en nuestro sistema, lo que puede llevar mucho tiempo y es muy probable que la sesión se agote antes de que finalice. >
Otra característica que se agregará más adelante sería manejar a un usuario cambiando los campos de entrada y enviando un latido al servidor (a menos que ya no estén autenticados). Todavía no hemos decidido cómo manejar este evento o desencadenar el latido del corazón para que no dispare cada pulsación de tecla. Una vez que esté en su lugar, el cuadro de diálogo de advertencia de tiempo de espera se mostrará con menos frecuencia.
Otra cosa que vale la pena mencionar es que todo el sitio es HTTPS y usamos ASP.Net AntiForgeryToken, que son cookies de HttpOnly marcadas como seguras.
Si alguien tiene algún comentario o sugerencia adicional, sería bueno saber de usted.