Question

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?

Answer 1

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.