0

I've got a strange one to solve today. A client needs their site to not allow people being logged in, going to a different site, then still being logged in if they hit the back button in their browser.

Simple I thought... until I couldn't find a page event that got fired when the back button was pressed from another site.

I thought of just using JavaScript and working with the referrer object, but this won't achieve my goal as I need to access the .NET Membership system and log the user out of their session.

Has anyone got around this problem? If so, how? Any help would be appreciated, potentially I'm just missing something that I could achieve in the Global.asax? If it helps, I'm using .NET 4.5 / C#.

Reasoning:

Due to, say, if one operator went and left their machine unlocked, visited Google, then another operator went on the same machine maliciously and hit the back button to gain access to that operator's logon (the client is very security cautious)

Chris Dixon
  • 9,147
  • 5
  • 36
  • 68
  • So they need to log on in the "different site" and then get access to the first site? – lboshuizen Oct 09 '12 at 12:23
  • Sorry, nope, they need to be logged out of the first site if they go to another site and return. – Chris Dixon Oct 09 '12 at 12:25
  • But when they come back they should be logged in again? – lboshuizen Oct 09 '12 at 12:26
  • Nope, when they come back they should be logged out of the .NET Membership system. – Chris Dixon Oct 09 '12 at 12:27
  • then what does "still being logged in if they hit the back button" means? – lboshuizen Oct 09 '12 at 12:31
  • The User Agent is under no obligation to tell you that the user has visited another site, or even that the user has clicked "back". Even if you can detect a "back" button click, you'll have a hard time distinguishing between an off-site and an on-site "back" click. Why does your client think this is important? – Rawling Oct 09 '12 at 12:31
  • Due to, say, if one operator went and left their machine unlocked, visited Google, then another operator went on the same machine maliciously and hit the back button to gain access to that operator's logon. Surely this has been done before? – Chris Dixon Oct 09 '12 at 12:33
  • http://stackoverflow.com/questions/981571/asp-net-logout-code-block – paparazzo Oct 09 '12 at 13:15

6 Answers6

1

So you would like to log out user whenever they leave your site? You cah have global javascript that sends a request to a server every minute saying "Hey, server, I'm here! I'm user Joe Blogs, i'm still on the site". If the server does not get this message from a user longer than a minute, log them out.

Overriding back button is just not going to work. What would you do if user opens up another tab/window and goes to google there?

Update: you can try using .unload() from jquery to catch page leave. And destroy the cookies on that event.

However, when the machine is just left unattended, nothing stop malicious user to go grab the access.

Update 2 you can just set very short session life! if user is inactive (or left the page) - log them out. To prevent possible annoyance for logging out when user looking on the screen for too long (fills in very long form) - make javascript to do regular (every 5 minutes) to a server to a dummy page - to keep the session live while the page is loaded.

Here is the source: Force users to logout when they leave my php website?

Community
  • 1
  • 1
trailmax
  • 34,305
  • 22
  • 140
  • 234
  • Updated my question with the reasoning of my goal. Potentially your solution could work, but surely there's an easier way without a request per minute, per user, overhead? – Chris Dixon Oct 09 '12 at 12:36
  • @thedixon re update: ah, that makes it even more fun! See my update to the post. – trailmax Oct 09 '12 at 12:42
  • Aha @trailmax - we're on the right lines here I think. However, .unload would work for every page, and wouldn't be aware of the page you're going to be heading to, so that couldn't work. But, maybe an AJAX call could run on the start of every page hit (synchronous), going to a handler to check the referrer there? – Chris Dixon Oct 09 '12 at 12:45
  • @thedixon here some other thread discussing similar problem: http://stackoverflow.com/questions/572938/force-logout-users-if-users-are-inactive-for-a-certain-period-of-time And I'm sure you can find some JS to detect if new page redirect is within the same domain, or user is going somewhere else. You just got cought on the "Back button", but should really looking at "logout user on inactivity" – trailmax Oct 09 '12 at 12:49
  • 1
    Update 2 is the solution here, albeit nasty, there doesn't seem to be any other way of doing this. – Chris Dixon Oct 09 '12 at 13:14
1

There is perhaps a "magical" solution for the problem but the key thing here is in the reasoning: Operator A is not allowed to use the site with the credentials of Operator B.

From a client and server perspective there is no way that the server or client (browser) can tell that persons changed seats at whatever moment in time.

That's the problem you have to solve.

But perhaps implementing face-detection is a little over the top?

lboshuizen
  • 2,746
  • 17
  • 20
1

If you were designing the site from the ground up you can do this by adding a header to specify that you do not want caching.

Cache-Control: no-cache Pragma: no-cache

But you would then have to have all your site access through a single page. The page need not be displayed the same and can contain different controls etc, but it's content would be decided by POST parameters rather than through the normal ASP.NET model.

e.g. Default.aspx and to navigate you would POST back at least two parameters. One would be the page to navigate to, and another would be an unpredictable token.

e.g. Token=3Zd2f4O61Z&Page=OrderHistory

Upon each page load you would validate the token and page title combination, and if OK you would display the page and generate new post-back data links for any navigation or actions you would like the user to take at that point. If the user were to try accessing the same page with the old token, it would expire the session and then log out the user. This is the most secure way to do this as then clicking the back button would prompt the user to resubmit their post data again. If OK was clicked, the browser would submit it but the server would recognise that the token was now invalid (as it has already been used, and discarded by the server) and then log out the user.

This method also protects against CSRF as you are validating a token in the payload of each request rather than just checking cookie values.

I know this won't help you unless you can reengineer your site, but I thought I'd add this solution in case anyone lands here with the requirement from the beginning.

SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
  • This is a very good post regarding this, I did end up using the cache control settings and the latest version of .NET uses the CSRF token checking as standard in the MasterPage templates - so that's good advice for other users reading this post also. – Chris Dixon Oct 10 '12 at 14:27
0

You can have a landing page of your site to contain nothing by a JS redirect to reals homepage this way when person hits back button he will go back first to the damy redirecting page that move him back to home page.

But it will be possible to override this if user chooses to skip number of pages at once or just opens another window.

MichaelT
  • 7,574
  • 8
  • 34
  • 47
  • Unfortunately this wouldn't work with a page that isn't the homepage. Say a user is on Client.aspx, then goes to google, then hits the back button (back to Client.aspx), the data will be shown there and the user will still be logged in. – Chris Dixon Oct 09 '12 at 12:28
  • 2
    Yes you correct, but I just don't think it possible to accomplish what you want. If user is slightly sophisticated it possible for him override any blocking mechanism very easily, like opening a new tab in a same browser window and going to your site there (all logged in cookies will be preserved). I think the best solution is to have very short authentication timeout and maybe to ask for reentering credentials before most critical operations. – MichaelT Oct 09 '12 at 12:50
0

Could you provide further information about why exactly is its needed ? I think in your case, there is a possible solution of may be having a separate Database table or field for marking or flagging such users who have been redirected to another site just treat them as signed off and then once they hit your sites URL you can probably check for the flag and sign them back in, automatically.

Manoj Dwivedi
  • 95
  • 2
  • 7
  • This would be fine, I could just check their HTTP_REFERRER and log them out instantly without any DB work. The problem is that no page events are hit when a user clicks the back button to your site (your site -> google -> back button - no events fire here). – Chris Dixon Oct 09 '12 at 12:32
  • 1
    @thedixon I'm sure you know that HTTP_REFERRER is not reliable (http://stackoverflow.com/questions/6023941/how-reliable-is-http-referer) – trailmax Oct 09 '12 at 12:36
0

JQuery unload() function will solve your problems as wel as the javascript window.onbeforeunload...

Tjassens
  • 922
  • 6
  • 9
  • And what if the user navigates to a just another page of the secure site? Login again behind the scenes? .unload() works at pagelevel and not sitelevel – lboshuizen Oct 09 '12 at 13:03