Mantener la sesión del usuario activa - consideraciones de seguridad

9

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.

    
pregunta user15895 12.11.2012 - 12:08
fuente

2 respuestas

4

Huelo dos "malos olores" en este enfoque:

  • Primero, nunca debes confiar en el cliente. Guardar el nombre de usuario en el lado del cliente y luego confiar en el cliente para que lo devuelva honestamente no me parece tan inteligente. Ya has descubierto que esto podría permitir que alguien acceda a una sola página con un nombre de usuario diferente. Eso ya suena un poco dudoso, y ¿cómo sabes que no hay ataques peores? Recomendaría contra cualquier esquema que implique confiar, aunque solo sea por un momento, el cliente.

  • En segundo lugar, la utilidad de esto suena problemática. Los cuadros de diálogo que interrumpen tu flujo son realmente molestos. Corta la sesión o no. Personalmente, para la mayoría de los sitios web, creo que no hay un gran peligro en mantener su sesión abierta durante mucho tiempo, si han dejado una pestaña abierta, y creo que los beneficios de la usabilidad de no obligar a los usuarios a volver a iniciar sesión valen la pena Los riesgos de seguridad, pero eso es para que usted decida. Mi única sugerencia es evitar los cuadros de diálogo emergentes que interrumpen su flujo. Por supuesto, no soy un experto en usabilidad. Si desea una opinión más experta, puede preguntar en User Experience.SE .

    Actualización (11/14) : entiendo que agregó el cuadro de diálogo por una razón, pero aún creo que probablemente no sea la mejor solución desde una perspectiva de usabilidad. Si la solución es que los usuarios que estaban en medio de la entrada de datos estaban perdiendo datos, entonces hay otras soluciones que parecen tener mejor facilidad de uso. Ejemplo: puede usar Javascript para que la aplicación web guarde automáticamente el texto que ingresaron cada 30 segundos, de modo que si su sesión se agota, pueden volver a iniciar sesión y su texto vuelve a aparecer. O bien, podría ampliar la duración de la sesión. O bien, puede detectar la actividad del usuario en cualquier pestaña (escribiendo, etc.), y solo expira la sesión después de 60 minutos de inactividad del usuario. Preguntar a los usuarios de la experiencia del usuario puede llevar a otras sugerencias también. Me doy cuenta de que esto no es un tema para este sitio, por lo que lo dejaré así.

No tengo inmediatamente un ataque que rompa tu esquema y lo destruya en tiras. Pero estos "malos olores" me dejan preocupado y me hace pensar que no has seguido las buenas prácticas para el diseño defensivo en aplicaciones web.

    
respondido por el D.W. 12.11.2012 - 18:57
fuente
2
  • Mantener la sesión del usuario segura. En cuanto a la carga, eso es hasta Su hardware y cómo lo escribe, pero no tiene un efecto peor que usuarios que actualizan la página (posiblemente menos considerando la sobrecarga de una llamada AJAX sobre una carga de página estándar).
  • Puedes ajustar el tiempo de espera en la web .config si eso es lo que estás preguntando ...
  • Las cookies tienen su propósito, y las encuentro aceptables siempre y cuando Es su dominio, pero se da cuenta de que algunas personas los deshabilitan y por eso todo se reduce a tener una caída.
  • Hay devoluciones de servidor cuando se usa .NET AJAX con UpdatePanel. La única diferencia es que toda la página no está cargado. Todo el código del lado del servidor se dispara normalmente, pero el La información se envía entre el servidor y la página de forma diferente. usando la tecnología AJAX.
  • Incluso puede llamar a los métodos del lado del servidor desde el javascript del lado del cliente utilizando un mecanismo que .NET llama PageMethods. Esto es un mas Manera "manual" de usar AJAX en .NET que el tradicional UpdatePanel técnica.
  • Los bancos utilizan la misma metodología para mantener tu sesión en marcha estás revisando tus finanzas, pero por lo general ofrecen una ventana emergente justo antes para preguntar si desea continuar.
  • Mantener a un usuario conectado de forma forzada durante más tiempo que una duración normal puede ser un riesgo para la seguridad (imagine a alguien que ingresa a una biblioteca o la computadora de la escuela y dejar su escritorio - si esa sesión continúa en al día siguiente

Los siguientes recursos pueden ayudarlo

respondido por el Md Mahbubur Rahman 16.11.2012 - 07:44
fuente

Lea otras preguntas en las etiquetas