¿Impedir la divulgación de información desde el botón / historial de retroceso del navegador?

21

Tengo datos confidenciales que se alojarán en un sitio web, y me gustaría evitar que los datos se expongan en este escenario:

  • El usuario principal cierra la sesión de la aplicación, pero no cierra el navegador (suponiendo un entorno de Kiosk)

  • Luego, y un segundo usuario (malicioso) se acerca al terminal y luego presiona el botón Atrás o simplemente busca el historial.

Como resultado, el usuario malintencionado puede ver contenido para el que no está autorizado.

  
  1. ¿Cuáles son mis opciones para evitar esto?

  2.   
  3. ¿Qué puedo hacer para mantener el sitio "fácil de usar" y permitir que los usuarios autenticados vuelvan a través del historial, pero no sin autenticar / no autorizar?

  4.   

Algunas ideas con las que estaba jugando incluyen

  • Cache-Control: no-cache
  • Última modificación
  • Caduca
  • Y también Javascript para actualizar la autenticación de la página

Pero no estoy seguro de cómo estas distintas configuraciones afectarán a un navegador web cuando operen en modo SSL o no SSL. Esto se vuelve aún más complicado si se trata de un proxy, por lo que decidí que sería conveniente consultar a los expertos.

    
pregunta random65537 26.10.2011 - 17:18
fuente

6 respuestas

23
  1. Utilizar SSL
  2. Asegúrese de implementar la administración de la sesión correctamente, por ejemplo, la presencia de la identificación correcta de la sesión verificada en cada página y destruida con el cierre de sesión
  3. Agregar control de caché: no-cache, pragma: no-cache y caducará: -1 encabezados en todas partes
  4. Asegúrese de que los formularios y todas las variables confidenciales se envíen solo a través de solicitudes POST y no GET (durante las auditorías de código he visto innumerables veces que las páginas aceptan ambos métodos sin ninguna razón)
respondido por el john 26.10.2011 - 18:46
fuente
7

Si un proxy cambia las cosas, entonces no está usando SSL, y no usar SSL es muy malo si los datos intercambiados son "confidenciales". Hablando de eso, datos confidenciales en un quiosco público que pueden ser "mejorados" con un registrador de teclas, bueno, eso tampoco es sumamente tranquilizador.

Puede usar Javascript para descargar y mostrar las páginas de contenido sin "cambiar la página" en el sentido del navegador. A continuación, debe proporcionar sus propios "botones" atrás y adelante. Luego agrega un gancho al cambio de página real (desde el punto de vista del navegador) para modificar los contenidos internos.

Ninguna de las anteriores le salvará si el usuario abre una nueva ventana y se olvida de cerrar la ventana "sensible".

    
respondido por el Tom Leek 26.10.2011 - 17:59
fuente
6

Los controles de caché se aplican a las conexiones SSL, y son ampliamente compatibles con los navegadores, por lo que parece ser el mejor enfoque. Si se está conectando a través de SSL, un proxy o bien hará un hombre en el medio y entregará contenido, o simplemente lo ignorará y se enrutará normalmente. En el caso de que realice un MiTM, se interrumpirá la verificación de confianza del certificado del navegador, por lo que aparecerá un gran error rojo y (con suerte) se enseñará a los usuarios a alejarse del quiosco y usar otra cosa. Si no lo hacen, bueno, eres SOL.

Si el proxy simplemente enruta la conexión y usted pasa en el control de caché o Caducidad, o en los encabezados de Última modificación, se espera que el navegador lo admita. Sin embargo, el problema con el que se encuentra es el caché local de la página HTML. Un usuario malintencionado podría leer la página del caché. Si el navegador no lo admite, no permita que el usuario vea la página. Verifique el agente de usuario y compárelo con una lista de versiones compatibles conocidas.

Por supuesto, como dijo Tom, si el kiosco tiene un keylogger instalado, se acabó el juego.

    
respondido por el Steve 26.10.2011 - 18:12
fuente
3

Una pregunta antigua, pero agregando una respuesta para los tiempos modernos.

Para respuestas sensibles, debe establecer el siguiente encabezado:

Cache-Control: no-store, must-revalidate

En estos días, probablemente no deba preocuparse por el encabezado HTTP 1.0 Expires . Pragma es solo para solicitudes, no respuestas.

Para actualizar la página justo después del tiempo de espera de la sesión (para que aparezca el formulario de inicio de sesión), agregue este encabezado:

Refresh: n + m

Donde n es el número de segundos hasta que la sesión se agote y m es un pequeño retraso. En Java esto es:

session.getMaxInactiveInterval() - ( System.currentTimeMillis() - session.getCreationTime() ) / 1000
    
respondido por el Neil McGuigan 12.03.2015 - 19:24
fuente
1

Del caso MSFT # 111101555217932

Verá esta funcionalidad con cualquier página web que acepte datos dentro de una solicitud HTTP POST. La lógica de Azure ACS es que el proceso de envío de datos de formularios a través de una POST de HTTP en realidad se muestra como una entrada en el historial de su navegador. Si verifica el historial inmediato de su navegador, la entrada aparecerá como "Trabajando ..." en la lista. Esto le permite "navegar" de regreso a esta entrada. Una vez que intente navegar de nuevo a esta 'página', el navegador notificará que el contenido ya ha caducado, por lo que le indicará con información que el contenido ha caducado y le preguntará si desea volver a enviar la solicitud para obtener la versión 'actualizada' de Esa página desde el servidor. Una vez que hace clic en el botón Reintentar, los datos de estos formularios se devuelven a ADFS y ADFS los trata como una solicitud de inicio de sesión normal, de modo que autentica esa solicitud y envía el token SAML y lo redirige automáticamente a su página web original.

Verás este mismo comportamiento con otros navegadores también.

Entonces, queremos saber cómo evitar que los usuarios inicien sesión como otro usuario simplemente pulsando de nuevo, de nuevo, de nuevo, de actualización. Tuve algunas conversaciones con nuestro equipo de IE y nuestro equipo de ASP.NET y se nos ocurrió un par de cosas que podrías intentar para evitar este problema.

Soluciones del lado del cliente

  1. Una sugerencia de nuestro equipo de IE es modificar la página de inicio de sesión de ADFS para que no acepte las credenciales de inicio de sesión directamente. En su lugar, solo contiene un botón que dice inicio de sesión. Cuando el usuario haga clic en este botón de inicio de sesión, tendrá un javascript que ejecuta la llamada a window.open () para iniciar un segundo cuadro de diálogo pequeño que navega a una segunda página alojada en su sitio web de ADFS. La segunda página de ADFS aceptará el nombre de usuario y la contraseña y luego los enviará para la autenticación. Después de que el cuadro de diálogo inicie sesión, puede cerrar esa ventana y usar la ventana principal para navegar a la aplicación de su usuario de confianza.

  2. Otra sugerencia es probar una llamada a location.replace () como se describe aquí: enlace Esto eliminaría una entrada de la lista de historial a medida que navega a una página nueva.

Soluciones laterales del servidor

  1. Una opción es modificar la página de inicio de sesión de ADFS para que el usuario también envíe un valor basado en el tiempo como parte de los datos del formulario. Digamos que agregó un valor TimeSubmitted al formulario y cuando el usuario hizo clic en el botón de inicio de sesión, tiene un script que establece el valor a la hora actual y lo envía como parte de los datos de inicio de sesión. Luego, en el lado del servidor, verificará este valor y si fue más de 2 a 5 segundos más tarde que la hora actual del servidor, podría rechazar el intento de inicio de sesión y enviar al cliente una nueva página de inicio de sesión para ingresar manualmente combinación de nombre de usuario / contraseña de nuevo.

  2. Otra sugerencia del lado del servidor es manipular el historial del navegador para eliminar esa entrada "Trabajando ...". Para hacer esto, puede emitir un script del lado del cliente dentro del evento PreRender de las páginas. Así que en tu página de inicio de sesión podrías tener

     private void WebForm1_PreRender(object sender, System.EventArgs e)
     {
        if (IsPostBack)
     {
     Response.Write("<html><head><script>location.replace('"+Request.Path+"');\n"
     +"</script></head><body></body></html>\n");
     Response.End();
     }
    

La solicitud POST se elimina del historial de navegación de IE. El historial contendrá solo las solicitudes GET.

  1. También puede ocultar la barra de navegación del navegador en su quiosco y simplemente agregar los botones de avance y retroceso a sus páginas directamente. Tendría que manejar las funciones de navegación de la página con sus propias páginas y, obviamente, no permitir que un usuario navegue "Atrás" desde la página de inicio de sesión de ADFS.

Lamentablemente, no hay una manera fácil de solucionar este problema de deshabilitar la capacidad de alguien para volver a enviar los datos del formulario, incluso si los datos del formulario se utilizan para autenticar e iniciar sesión en un usuario. De todas las sugerencias propuestas, probablemente implementaría la primera solución del lado del servidor en la que simplemente pasa el tiempo enviado y si está a una cierta delta de la hora del servidor, simplemente ignore la solicitud porque es una nueva publicación de un intento de inicio de sesión exitoso anterior.

    
respondido por el random65537 27.10.2011 - 20:18
fuente
1

En mi experiencia con la navegación por PHP es "difícil" navegar hacia atrás una vez que hayas cerrado la sesión y redirigido a la pantalla de inicio de sesión o cierre la ventana. Concedido cualquier instancia de una ventana abierta a una página abierta es una entrada antes de que caduque. Dependiendo de la cantidad de usuarios asegurados con bocas seguras que tenga, una variación en CAPTCHA capturará los intentos de reutilizar las cookies o las pulsaciones de teclado memorizadas. El método más simple es agregar una varianza predeterminada a un generador de pines CAPTCHA. Es decir. el número de pin generado es 5463 agrego mi día de nacimiento 14. En el código para el CAPTCHA simplemente agregas la cadena de usuario a la instrucción if. Lo siento, no es brillante, pero para el escenario que describiste es efectivo y fácil.

    
respondido por el Z_TLAW 22.11.2011 - 12:19
fuente

Lea otras preguntas en las etiquetas