Gibt es eine Möglichkeit, eine Seite vom Rendern abzuhalten, sobald sich eine Person ausgeloggt hat, aber auf die Schaltfläche "Zurück" klickt?

Question

Ich habe eine Website, die eine Anmeldung erfordert und vertrauliche Informationen anzeigt.

Die Person geht auf die Seite, wird aufgefordert, sich anzumelden, und bekommt dann die Informationen zu sehen.

Die Person meldet sich von der Site ab und wird zurück zur Anmeldeseite geleitet.

Die Person kann dann "zurück" drücken und direkt zu der Seite zurückkehren, auf der die vertraulichen Informationen enthalten sind. Da der Browser es nur als gerenderten HTML-Code ansieht, zeigt es ihnen kein Problem.

Gibt es eine Möglichkeit zu verhindern, dass diese Informationen angezeigt werden, wenn die Person die Schaltfläche "Zurück" auf dem abgemeldeten Bildschirm drückt? Ich versuche nicht, den Zurück-Button selbst zu deaktivieren, ich versuche nur, die sensiblen Informationen nicht wieder angezeigt zu bekommen, weil die Person nicht mehr auf der Site eingeloggt ist.

Aus Gründen der Argumentation ist der obige Standort/das obige Szenario in ASP.NET mit Formularauthentifizierung (wenn der Benutzer also zur ersten Seite geht, die die gewünschte Seite ist, werden sie zur Anmeldeseite weitergeleitet.) falls das einen Unterschied macht).

Answer 1

Die kurze Antwort ist, dass es nicht sicher gemacht werden kann.

Es gibt jedoch eine Menge Tricks, die implementiert werden können, um es Benutzern zu erschweren, zurückzuschlagen und sensible Daten anzuzeigen.

Response.Cache.SetCacheability(HttpCacheability.NoCache); 
Response.Cache.SetExpires(Now.AddSeconds(-1)); 
Response.Cache.SetNoStore(); 
Response.AppendHeader("Pragma", "no-cache"); 

Dies wird Caching auf Client-Seite deaktivieren, aber diese von allen Browsern nicht unterstützt wird.

Wenn Sie die Möglichkeit der Verwendung von AJAX dann sensible Daten können mit einem Update abgerufen werden, die von Client-Code aktualisiert wird, und deshalb wird es nicht angezeigt, wenn schlagen zurück, es sei denn Kunde noch angemeldet ist.

Answer 2

Von aspdev.org:

Fügen Sie die folgende Zeile auf dem Ereignishandler Page Load und ASP.NET-Seite nicht in dem Benutzer-Browser im Cache gespeichert werden:

Response.Cache.SetCacheability(HttpCacheability.NoCache) 

Einstellungen diese Eigenschaft stellt sicher, dass, wenn Der Benutzer drückt die Zurück-Taste, der Inhalt wird weg sein, und wenn er "Aktualisieren" drückt, wird er auf die Login-Seite weitergeleitet.

Answer 3

Sie sind für eine no-cache Direktive suchen:

<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE"> 

Wenn Sie ein Master-Design gehen habe, das ist ein bisschen ein jonglieren sein können, aber ich glaube, dass Sie diese Anweisung setzen können auf einer einzigen Seite, ohne den Rest Ihrer Website zu beeinträchtigen (vorausgesetzt, dass Sie das wollen).

Wenn Sie diese Anweisung gesetzt haben, geht der Browser pflichtbewusst zum Server zurück und sucht nach einer brandneuen Kopie der Seite, die Ihren Server dazu bringt zu sehen, dass der Benutzer nicht authentifiziert ist Loginseite.

Answer 4

Die Abmeldeoperation muss ein POST sein. Dann fragt der Browser nach "Sind Sie sicher, dass Sie das Formular erneut posten möchten?" anstatt die Seite zu zeigen.

Answer 5

Ich weiß nicht, wie es in ASP.NET zu tun, aber in PHP würde ich so etwas wie:

header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); 
header("Cache-Control: no-cache"); 
header("Pragma: no-cache"); 

der den Browser, dass das Element erneut zu überprüfen zwingt, so sollten Sie Ihre Authentifizierungsüberprüfung ausgelöst werden , dem Benutzer den Zugriff verweigern.

Answer 6

Die richtige Antwort bezieht die Verwendung des HTTP-Cache-Control-Headers für die Antwort ein. Wenn Sie sicherstellen möchten, dass sie nie die Ausgabe zwischenspeichern, können Sie Cache-Control: No-Cache. Dies wird oft auch in Abstimmung mit No-Store verwendet.

Andere Optionen, wenn Sie begrenztes Caching wünschen, sind das Festlegen einer Ablaufzeit und die erneute Gültigkeitsprüfung, aber diese können möglicherweise dazu führen, dass eine zwischengespeicherte Seite erneut angezeigt wird.

Siehe http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

Answer 7

Es ist ein bisschen von einem Stamm, aber wenn Sie ein Java-Applet oder eine Flash-Anwendung hatte die Authentifizierung eingebettet und wurde durch das getan Sie könnte es so machen, dass sie hatten zur Authentifizierung in, erm "Echtzeit" mit dem Server, wann immer sie die Informationen sehen wollten.

Mit diesem können Sie auch beliebige Informationen verschlüsseln.

Es gibt immer die Möglichkeit, dass jemand nur die Seite mit den sensiblen Informationen speichern kann, ohne dass ein Cache diese Situation umgehen kann (aber dann kann immer ein Screenshot einer Flash- oder Java-Anwendung erstellt werden).

Answer 8

Der Vollständigkeit halber:

Response.Cache.SetCacheability(HttpCacheability.NoCache); 
Response.Cache.SetNoStore(); 
Response.Cache.SetExpires(DateTime.Now.AddMinutes(-1)); 

Answer 9

DannySmurf, < meta> Elemente sind extrem unzuverlässig, wenn es um Steuern Caching kommt, und Pragma insbesondere noch mehr. Reference.

Answer 10

Dannyp und andere, No-Cache stoppt nicht Caches von sensiblen Ressourcen zu speichern. Es bedeutet lediglich, dass ein Cache eine gespeicherte Ressource nicht bereitstellen kann, ohne sie zuvor erneut zu validieren. Wenn Sie verhindern möchten, dass vertrauliche Ressourcen zwischengespeichert werden, müssen Sie die no-store-Anweisung verwenden.

Answer 11

Nun, in einer großen brasilianischen Bankgesellschaft (Banco do Brasil), die dafür bekannt ist, eine der sichersten und effizientesten Homebanking-Software der Welt zu haben, schreiben sie einfach history.go (1) in jede Seite , wenn Sie den Zurück-Knopf drücken, werden Sie zurückgebracht. Einfach.

Answer 12

Bitte schauen in die HTTP-Antwortheader. Der größte Teil des ASP-Codes, den Nutzer einstellen, scheint diese zu setzen. Sicher sein. Die chipmunk book from O'Reilly ist die Bibel von HTTP und Chris Shiflett's HTTP book ist auch gut.

Answer 13

Cache and history are independent und man sollte sich nicht gegenseitig beeinflussen.

Die einzige Ausnahme made for banks ist, dass die Kombination von HTTPS und Cache-Control: must-revalidate Kräfte beim Navigieren im Verlauf aktualisiert werden.

In Plain HTTP gibt es keine Möglichkeit, dies zu tun, außer durch Browserfehler.

Sie könnten es mit JavaScript, das document.cookie checkt und umleitet, wenn ein "Killer" -Cookie eingestellt ist, hacken, aber ich kann mir vorstellen, dass dies ernsthaft schief gehen kann, wenn der Browser Cookies nicht genau wie erwartet setzt/löscht.

Answer 14

Sie können die Webseite mit dem sensiblen als HTTP-POST zurückgeben. In den meisten Fällen werden Browser dann die Nachricht senden, ob Sie die Daten erneut einreichen möchten. (Leider kann ich keine kanonische Quelle für dieses Verhalten finden.)

Answer 15

Ich hatte gerade das Banking-Beispiel im Kopf.

Die Seite meiner Bank hat dies darin:

<meta http-equiv="expires" content="0" /> 

Dies darüber sein sollte, nehme ich an.

Answer 16

Sie könnten eine JavaScript-Funktion haben eine schnelle Serverprüfung (Ajax) und wenn der Benutzer nicht angemeldet ist, löscht die aktuelle Seite und ersetzt sie durch eine Nachricht. Dies wäre natürlich anfällig für einen Benutzer, dessen Javascript deaktiviert ist, aber das ist ziemlich selten. Auf der Oberseite ist dies sowohl Browser-und Server-Technologie (ASP/PHP usw.) Agnostiker.