asp.net - ¿Hay alguna manera de evitar que una página se reproduzca una vez que una persona se desconectó pero presionar el botón "volver"?
security browser (16)
Bueno, en una importante corporación bancaria brasileña (Banco do Brasil) que es conocida por tener uno de los software de banca hogareña más seguros y eficientes del mundo, simplemente ponen history.go (1) en cada página. Así que, si golpeas el botón Atrás, serás devuelto. Sencillo.
Tengo un sitio web que requiere un inicio de sesión y muestra información confidencial.
La persona va a la página, se le solicita que inicie sesión y luego ve la información.
La persona cierra sesión en el sitio y se le redirige a la página de inicio de sesión.
La persona puede presionar "volver" y volver directamente a la página donde se encuentra la información confidencial. Como el navegador solo lo considera HTML procesado, no se lo muestra a ellos.
¿Hay alguna manera de evitar que se muestre esa información cuando la persona toca el botón "Atrás" desde la pantalla de sesión? No estoy tratando de desactivar el botón de retroceso, solo trato de evitar que la información sensible vuelva a aparecer porque la persona ya no está conectada al sitio.
En aras de la discusión, el sitio / escenario anterior está en ASP.NET con Autenticación de formularios (por lo que cuando el usuario va a la primera página, que es la que quiere, se le redirige a la página de inicio de sesión, en caso de que eso haga una diferencia).
De aspdev.org :
Agregue la siguiente línea en la parte superior del controlador de eventos Page_Load y su página ASP.NET no se almacenará en caché en los navegadores de los usuarios:
Response.Cache.SetCacheability(HttpCacheability.NoCache)
Configuración de esta propiedad asegura que si el usuario pulsa el botón de retroceso, el contenido desaparecerá, y si presiona "actualizar", se le redirigirá a la página de inicio de sesión.
Es un poco complicado, pero si tuvieras un applet de java o una aplicación flash incorporada y la autenticación se realizara a través de eso podrías hacerlo para que tuvieran que autenticarse en, erm, ''en tiempo real'' con el servidor cada vez ellos querían ver la información.
Usando esto también puedes encriptar cualquier información.
Siempre existe la posibilidad de que alguien solo pueda guardar la página con la información sensible, ya que no tener memoria caché no va a evitar esta situación (pero luego siempre se puede tomar una captura de pantalla de una aplicación Flash o Java).
Está buscando una directiva sin caché:
<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">
Si tiene un diseño de página maestra en marcha, esto puede ser un poco de malabares, pero creo que puede poner esta directiva en una sola página, sin afectar el resto de su sitio (suponiendo que eso es lo que quiere).
Si tiene esta directiva establecida, el navegador se dirigirá de vuelta al servidor buscando una nueva copia de la página, lo que hará que su servidor vea que el usuario no está autenticado y lo llevará a la página de inicio de sesión.
Haga que la operación de cierre sea POST . Luego, el navegador le preguntará "¿Está seguro de que desea volver a publicar el formulario?" en lugar de mostrar la página.
La respuesta correcta implica el uso de establecer el encabezado HTTP Cache-Control en la respuesta. Si quiere asegurarse de que nunca almacenan en caché el resultado, puede hacer Cache-Control: no-cache. Esto a menudo se usa en coordinación con la tienda también.
Otras opciones, si desea un almacenamiento en caché limitado, incluyen establecer un tiempo de caducidad y deben revalidar, pero potencialmente podrían causar que una página almacenada en caché vuelva a aparecer.
Ver http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
Los elementos de DannySmurf, <meta> son extremadamente poco confiables cuando se trata de controlar el almacenamiento en caché, y Pragma en particular aún más. Reference .
Mire en los encabezados de respuesta HTTP. La mayoría del código ASP que la gente está publicando parece estar configurándolos. Estar seguro.
El libro de la ardilla de O''Reilly es la biblia de HTTP, y el libro HTTP de Chris Shiflett también es bueno.
No sé cómo hacerlo en ASP.NET pero en PHP haría algo como:
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Cache-Control: no-cache");
header("Pragma: no-cache");
Lo que obliga al navegador a volver a verificar el elemento, por lo que debe activarse la verificación de autenticación, denegando el acceso del usuario.
Podría tener una función javascript que haga una comprobación rápida del servidor (ajax) y, si el usuario no está conectado, borrará la página actual y la reemplazará con un mensaje. Obviamente, esto sería vulnerable para un usuario cuyo javascript está desactivado, pero eso es bastante raro. Por el lado positivo, esto es tanto tecnología de navegador como de servidor (asp / php, etc.) agnóstico.
Por completitud:
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
Response.Cache.SetExpires(DateTime.Now.AddMinutes(-1));
Puede hacer que la página web con la información confidencial sea devuelta como HTTP POST, luego, en la mayoría de los casos, los navegadores le darán el mensaje que le preguntará si desea volver a enviar los datos. (Desafortunadamente no puedo encontrar una fuente canónica para este comportamiento).
Solo tenía el ejemplo bancario en mente.
La página de mi banco tiene esto en ella:
<meta http-equiv="expires" content="0" />
Esto debería ser sobre esto, supongo.
dannyp y otros, no-cache no impide que las memorias caché almacenen recursos confidenciales. Simplemente significa que un caché no puede servir un recurso que ha almacenado sin volver a validarlo primero. Si desea evitar que se almacenen los recursos confidenciales, debe usar la directiva no-store.
El caché y la historia son independientes y uno no debe afectarse entre sí.
La única excepción hecha para los bancos es la combinación de HTTPS y Cache-Control: must-revalidate fuerzas de actualización cuando se navega en el historial.
En HTTP plano, no hay forma de hacerlo, excepto mediante la explotación de errores del navegador.
Podrías hackearlo utilizando Javascript que comprueba document.cookie y redirige cuando está configurada una cookie "asesina", pero imagino que esto podría ir muy mal cuando el navegador no configure / borre las cookies exactamente como se esperaba.
La respuesta corta es que no se puede hacer de forma segura.
Sin embargo, hay muchos trucos que se pueden implementar para dificultar que los usuarios respondan y muestren datos confidenciales.
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetExpires(Now.AddSeconds(-1));
Response.Cache.SetNoStore();
Response.AppendHeader("Pragma", "no-cache");
Esto desactivará el almacenamiento en caché en el lado del cliente, sin embargo, esto no es compatible con todos los navegadores .
Si tiene la opción de utilizar AJAX, entonces los datos confidenciales pueden recuperarse utilizando un panel de actualización que se actualiza desde el código del cliente y, por lo tanto, no se mostrará cuando se vuelva a intentar a menos que el cliente todavía esté conectado.