¿Cuál es la mejor manera de asegurar las respuestas en una aplicación web de una sola página después de cerrar la sesión?

Cifre el contenido usando una clave de sesión mientras está en tránsito. Descifrar el contenido en memoria utilizando una variable. Al cerrar la sesión, elimine explícitamente las variables que contienen claves e información descifrada. También elimine explícitamente cualquier variable que contenga información de autenticación y cualquier información que se haya utilizado para generar la clave de sesión. La clave de la sesión puede generarse a partir de información de autenticación como el hash del nombre de usuario / contraseña y otra información accesible tanto para el cliente como para el servidor, pero NO alguien que esté observando el tráfico de red descifrado dentro de una sesión SSL (lo que hacen las herramientas del desarrollador). También tenga cuidado con los ataques "pass-the-hash" en el esquema de autenticación, por ejemplo, si tiene un nombre de usuario / contraseña en el lado del cliente, tenga en cuenta que alguien podría encontrar el hash de la contraseña en las Herramientas del desarrollador y luego enviar el hash para iniciar sesión, sin saber el contraseña.

Una sugerencia es la siguiente:

1: el usuario inicia sesión con nombre de usuario y contraseña.

2: la aplicación envía el nombre de usuario, H (nombre de usuario, H (contraseña, T), T) donde H () es una función hash y T es una marca de tiempo. Lee más en 3 cómo se construye la marca de tiempo.

3: el servidor comprueba que el registro es válido. Esto se logra al tener que T sea una marca de tiempo que tiene una granularidad de 1/2 del tiempo de validez esperado. Esto se genera al cortar bits de una marca de tiempo de época estándar de Unix. Por ejemplo, si desea una validez de 5-10 minutos, elimine los últimos 8 bits de la marca de tiempo. En la validación, verifique si el hash coincide con T = current_timestamp, T = current_timestamp-1 o T = current_timestamp + 1 para compensar el reloj del cliente que está ligeramente apagado. Esto da una validez de 256-768 segundos, que es aproximadamente de 4 a 12 minutos.

4: la aplicación ahora genera una clave de sesión, usando H (nombre de usuario, contraseña, T, sal estática). Guardar clave de sesión en variable. (Esto asegura que la sesión puede ser utilizada por más de 4-12 minutos). NOTA: NO PUEDE usar una marca de tiempo para caducar una sesión, TIENE QUE borrar las variables si desea caducar la sesión debido a la inactividad. Recuerde que las variables son accesibles a un individuo malintencionado si no se borran: la marca de tiempo solo se usa para caducar un hash de contraseña utilizado, por lo que no se puede reutilizar.

5: El script del servidor genera una clave de sesión de la misma manera, asegurándose de usar solo la T que se encontró correcta durante la validación en 3.

6: use la clave de sesión para cifrar la información en las estructuras JSON.

7: al cerrar sesión, eliminar clave de sesión, nombre de usuario, contraseña, H (Contraseña, T) y H (Nombre de usuario, H (Contraseña, T), T) y también cualquier información que se transfirió durante la sesión. Esto se logra simplemente configurando la variable a nada, por ejemplo, key = "";

El esquema de inicio de sesión anterior hace que Everything sea seguro tanto contra los ataques de paso como el hash y también protege la información en tránsito con una clave de sesión única. Además, las claves de sesión de otra sesión no se pueden usar para descifrar sesiones anteriores.

Esto garantiza que la información esté encriptada cuando esté visible en las Herramientas del desarrollador. No es posible obtener los valores de las variables en las Herramientas del desarrollador una vez que se hayan borrado, lo que garantiza que no haya acceso a los datos.

Si las computadoras están en un segmento controlado, que deberían estar si usted desarrolla una aplicación de registro de salud a la que los doctores acceden, debe deshabilitar todas las funciones de depuración / desarrollo a través de una política de grupo. Pero eso es difícil de hacer si los pacientes acceden a la aplicación.

Creo firmemente en una página de inicio / cierre de sesión completamente separada. Es mejor para transmitir al usuario que ha cerrado la sesión. Si solo cambia una parte de la página, sería fácil pasar por alto si un usuario no cierra sesión correctamente.

Lo has clavado.

  

Parece que el camino a seguir es NO usar el método AngularJS y, en cambio, romper el modelo y usar el redireccionamiento de javascript puro para actualizar el sitio a la página de inicio de sesión. Esto parece borrar las solicitudes de red. ¿Es este el método recomendado?

Tu mejor garantía es abandonar la página. Una vez que haya eliminado la cookie de inicio de sesión, puede enviar al usuario a cualquier lugar. Redirigirlos a su página de inicio, desbordamiento de pila, incluso esta pregunta, o para google. Puede crear una página de inicio de sesión que utilice simplemente para redirigir al usuario a algún lugar útil después de que cierre la sesión.