¿Hay alguna manera de evitar que una página se reproduzca una vez que una persona se desconectó pero presionar el botón "volver"?

votos
24

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).

Publicado el 15/09/2008 a las 16:41
fuente por usuario
En otros idiomas...                            


16 respuestas

votos
3

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.

Respondida el 15/09/2008 a las 16:44
fuente por usuario

votos
0

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.

Respondida el 15/09/2008 a las 16:44
fuente por usuario

votos
0

Haga que la operación de cierre de sesión sea a POST. Luego, el navegador le preguntará "¿Está seguro de que desea volver a publicar el formulario?" en lugar de mostrar la página.

Respondida el 15/09/2008 a las 16:44
fuente por usuario

votos
0

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.

Respondida el 15/09/2008 a las 16:45
fuente por usuario

votos
0

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

Respondida el 15/09/2008 a las 16:45
fuente por usuario

votos
0

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).

Respondida el 15/09/2008 a las 16:55
fuente por usuario

votos
0

Por completitud:

Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
Response.Cache.SetExpires(DateTime.Now.AddMinutes(-1));
Respondida el 15/09/2008 a las 16:59
fuente por usuario

votos
1

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. Referencia .

Respondida el 15/09/2008 a las 17:10
fuente por usuario

votos
1

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.

Respondida el 15/09/2008 a las 17:14
fuente por usuario

votos
0

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.

Respondida el 15/09/2008 a las 19:13
fuente por usuario

votos
13

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.

Respondida el 17/09/2008 a las 23:48
fuente por usuario

votos
0

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.

Respondida el 20/09/2008 a las 07:00
fuente por usuario

votos
9

El caché y la historia son independientes y uno no debe afectarse entre sí.

La única excepción hecha para los bancos es que la combinación de HTTPS y Cache-Control: must-revalidatefuerzas se actualizan cuando se navega en la historia.

En HTTP plano, no hay forma de hacerlo, excepto mediante la explotación de errores del navegador.

Podrías hackearlo usando Javascript que verifica document.cookiey 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.

Respondida el 19/10/2008 a las 23:57
fuente por usuario

votos
0

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).

Respondida el 06/01/2009 a las 17:17
fuente por usuario

votos
0

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.

Respondida el 20/04/2009 a las 10:48
fuente por usuario

votos
1

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.

Respondida el 20/04/2009 a las 16:53
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more