1

Is there a way to "disable" the browser's back button after loggin out?

I've read several posts and now I know, that I can disable caching. ( e.g. ASP.NET authentication login and logout with browser back button )

This is working, but I want to disable the back button for security reasons only after logging out (= when there's no Session available anymore).

If I disable caching, the user cannot use the browser's back button while logged in.

I'm using a custom authentication, not the standard of asp.net

Is there a secure (= no javascript) possibility to do this?

Community
  • 1
  • 1
Keith L.
  • 2,084
  • 11
  • 41
  • 64

4 Answers4

2

As I'm sure you already know, you can't directly disable the "back" button on a browser.

The only methods for preventing a user from going back rely on either setting the page to cache, or involve the use of javascript. Based on the fact that neither of these work for you, there isn't a solution to manage this. I've looked at many articles over the years, and re-searched this several times, and all of the suggestions either use client-side script or the cache.

My best suggestion in your case is to use the cache disable method, and look at how your UI responds to the "back" button and see if there are changes you can make to the design to make it smoother. This may involve checking the session variables, or checking to see if the user is still authenticated, but given your requirements, I believe you're out of luck.

In short, you're going to need to choose the lesser of two evils.

  • Using the page cache will ensure that people can't use the "back" button at all without using javascript - presumably better security
  • Using the javascript to delete page history on logout will allow you to prevent users from going back after logged out, but someon ewith noscript turned on, or someone malicious can disable your control.

You didn't specify exactly who you are trying to protect, and from what, but if I'm guessing right, and you're concerned about the user who leaves their PC after logging out, but without closing the browser window, then is the Javascript really a concern?

Thinking it through,the type of person who would do this isn't thinking about how the info can be used maliciously. Someone who is malicious, presumably, is already "thinking like a bad guy" and knows enough to close the browser window.

Either option could be bypassed via malware that intercepts/alters the http headers, javascript, etc, so neither is really 100% effective. The only difference I see is that the javascript option can be broken both by altering the html as it travels across the wire (using something like Fiddler or malware) AND by simply having Javascript disabled. so the page cache option is marginally better for security purposes.

Using https instead of plain http offers a lot more protection in combination with the header method, making it much more effective, because it greatly increases the difficulty of manipulating the data across the wire, and it's not disabled simply by disabling JavaScript.

Either way, I think you need to weigh your options and choose one or the other. As sad as it seems, we can only do so much to protect the users from themselves.

David
  • 72,686
  • 18
  • 132
  • 173
2

Anything running on the browser can be intercepted and/or disabled. Any page sent to the client-side can be saved: any link URLs, content, javascript, etc.

If you let me load a webpage in a browser on my machine, I can view and save the source of every page I see, and capture every piece of communication to and from the server. If you want HTML to render or javascript to run on my machine, I get to see it and keep it forever if i want.

You could control this by only permitting access to your application through a remote connection to a controlled machine where the application runs, but for a consumer app, this is probably prohibitive.

you could however, discourage most users with something like this

function logout(){
    window.open(loggedOutPageURL)
    self.close ()
}

a malicious user will have no problem disabling this javascript, or just saving content as he receives it, but this might be the best you can do.

Chris Bye
  • 1,028
  • 7
  • 17
  • 1
    +1 for a nice point about users being able to save/print pages. I don't know for sure, but I'm betting he's more worried about the user that uses a public PC and fails to close the browser window than someone printing info. A malicious user printing/saving/tampering with the info would have to be logged in in the first place. he sounds like he's trying to prevent anyone from getting back into protected pages after logging out. Example of the type of person I think he's trying to protect: Someone at a Library walking away from the PC without logging out/closing the browser, etc. – David Mar 22 '12 at 13:29
  • you are right @DavidStratton But it sounds like there's no solution for this security problem? I've seen a creditcard banking-page with exactly my problem. The user has been logged out, but the next user (on a public pc) could navigate back and read the information :\. If there's no solution for this, then Slothsberrys work around sounds nice. – Keith L. Mar 22 '12 at 13:37
  • 1
    Fair point. There's something to be said for assuming the worst when it comes to matters of security, but your reading of the question seems reasonable. The restriction of not relying on client-side code seems odd in that case. – Chris Bye Mar 22 '12 at 13:40
  • 1
    @Keith L. I agree, which is why my answer basically says to choose the lesser of two evils and either disable the page cache or use javascript. – David Mar 22 '12 at 13:41
  • 2
    Absolutely. Security is hard (read impossible) to get absolutely perfect without destroying anything resembling usability. You might be able to get a few 9s if you use something like my solution as well as disabling caching. Addressing the vulnerabilities you can is better then not addressing any. – Chris Bye Mar 22 '12 at 13:47
  • I need to accept two answers, because I will use the javascript code of Slothsberry. But I'm using it, because of the nice explained text of David Stratton. I think for users in the future who will read the question and accepted answer, the long explanation of David will inform them and make them thinking of choosing the solution of Slothsberry or not. Thanks both of you. – Keith L. Mar 22 '12 at 13:54
0

abandon method for dispose the session on logout & check Session!=null on your Data or dashboard page then I think there is not need to disable Back button.

Balwinder Pal
  • 97
  • 2
  • 10
  • That won't work. The page is still cached in the browser history, client-side, so you can still get back to it if the page cache isn't set. – David Mar 22 '12 at 13:32
0

write the script below logout button:

<script language="text/javascript">

window.history.forward(1);

</script>
ankit rajput
  • 182
  • 2
  • 5