4

Project Context

Client requires that the users of the site (when logged in and are able to view their personal information) be forced to be logged out if they try to navigate using the browser's navigation buttons.

My Research

Searching around on SO seems to indicate that most of the problems people have is to "stop" people from hitting the browser's back button when they're logged out, like this and this. The difference is that I need to "stop" the users from navigating backwards in history (and even forward as well, though I don't see how the users can go forward in history if they can't go back in the first place) even when they are logged in, making it compulsory that they use the provided navigation.

The Solution I Have In Mind

I'm thinking of capturing the browser's event when a user hits the back button and logging them out then. However, as discussed here it seems like you can only "do it" using Javascript and not using server-side code. My qualm with this approach is that users can bypass it merely by disabling Javascript on their browsers.

My Question

So my question is - Is there a way I can capture the browser event on the server-side and log them out there? If not, what are the alternatives to achieving my objective?

Community
  • 1
  • 1
jon2512chua
  • 1,062
  • 3
  • 14
  • 26
  • Maybe set the current page in your session and check the last page loaded before serving the one requested. – Gary Jan 22 '13 at 04:03
  • 7
    What's the purpose of this requirement? At first blush it seems... wrong. Can you push back on it? – John Kugelman Jan 22 '13 at 04:03
  • @Gary Sorry but I do not fully understand your proposed solution. Can you please elaborate? – jon2512chua Jan 22 '13 at 05:21
  • @JohnKugelman Apparently it's for "security reasons". I'm of the same opinion as you as well, am asking but nevertheless would like to know a solution in case I ever need to do it in the future. – jon2512chua Jan 22 '13 at 05:22
  • @Jonathan, I cant think of any graceful solution (especially without JavaScript). My idea is: You obviously have a session since the user is logged in; when the page loads store that URI in a session variable. As the page loads, check that session var to see if it is a URL you might expect the user to be after the current URL (may not be viable as we dont know your conext) – Gary Jan 22 '13 at 05:57
  • 5
    A variation of @Gary's solution, but perhaps slightly easier to implement & maintain: Turn off caching of the html pages (therefore back = reload, hopefully). On page load from the server, generate and store in the session a random "Next" nonce and decorate all of the next page links with the same. On every subsequent page load, verify the nonce, if it matches, generate, decorate, and store the next nonce. Otherwise kill the session and logout the user. But I agree that this requirement feels wrong. – Charlie Jan 22 '13 at 06:45
  • ___(therefore back = reload, hopefully)___ Hopefully! yes since browser might show page-expire Page instead of reloading. Can we specify some header property to always reload? – Prakash K Jan 25 '13 at 08:44
  • **Risk vs Cost** What is the risk to the business if a user deliberately subverts whatever solution you use ? Would a cheap Javascript solution as you suggest work for everyone and be a sufficient security measure for the amount of possible risk (could you prevent access to the site if Javascript isn't enabled for example or is there a requirement to support browsers without Javascript ?) – t0ne Jan 25 '13 at 17:38
  • The problem is sound, but the solution you're asking for is in completely the wrong direction. For the right solution, carefully read this Q&A: http://stackoverflow.com/questions/4194207/prevent-user-from-going-back-to-the-previous-secured-page-after-logout – BalusC Jan 31 '13 at 03:08
  • @BalusC Yes I've already read that Q&A, and linked to it in fact in my question, under the "My Research" heading. And like I said, it's a different problem because I need to prevent history access "even when they are logged in". The post-logged out security issue had already been covered early on. – jon2512chua Jan 31 '13 at 03:37

7 Answers7

7

I'd say that your best option is tracking the session.

You make the client send you the timestamp of when the request was processed by your server, or even simpler: a user dependent counter (which you send each time to the client), and server-side keep track of the last timestamp/counter sent.

If the user clicks the back button, he will send you an old timestamp/counter instead of the last current one, and you can then log him out server side.

This should do the trick.

In order to make sure the trick is done and making it javascript independent, I'd say you could place this value in a hidden parameter, or maybe as a hidden field form, so the user doesn't see it but it always gets sent to your server.

I hope this helps!

Daren
  • 3,337
  • 4
  • 21
  • 35
  • 1
    For added "security" you could also encrypt/decrypt the value to prevent tampering. – kahowell Jan 30 '13 at 05:10
  • I'd probably agree with this. Browser forward and back is rather hard to capture on the server side -- they all look similar like normal request. In my opinion using a robust security framework (eg: spring security / Java EE security) in the first place is probably better to avoid having to come into this position – gerrytan Jan 30 '13 at 21:43
  • @Daren Yeah I've settled with tracking the session, but with a slightly different implementation but similar concept - thanks to an in-house framework I can keep track of the "stages" the users go through once they're logged in, so I just have to write a class that stores the "stage" each time a user enters it, then if he clicks the back button he'll send a "stage" that is already in storage and voila! Logged him/her out. – jon2512chua Jan 31 '13 at 03:45
1

What I did was to create a single page, 1 html document, then use AJAX to navigate the whole site. When a user hits the back button it takes you to the index page, which is the log in page. To log in I use AJAX which I do redirect on the server side only. The only problem is when a user hits the forward button but the good thing is no JS no navigation.

zeddarn
  • 302
  • 2
  • 14
1

If the requirement is trap browser navigation buttons and log them out - the easier alternative is never show these navigation buttons in the first place. What is the use if the user cannot use or click back and forward.

Open a new browser without a toolbar, menu bar from you webapp. When the user closes the window, trap the event and logout the session. This way - the solution would remain simple.

My 2c

basav
  • 1,453
  • 10
  • 18
0

Relying on javascript is not a good practice, since it is on client side and what runs on client side can always be bypassed by client.

You should instead use session timeout.

terafor
  • 1,620
  • 21
  • 28
0

Sorry, fetch the buttons themselfe isnt possible.

Since this is a security-problem a solution (without javascript) would be:

  • to use encoded pages who warn on navigation out-of or into an unencoded-page. Even the mutual authentication might fit your needs.

authentication

leaving

Grim
  • 1,938
  • 10
  • 56
  • 123
0

If I understand correctly your question:

You can't avoid the user to send a request to your server, the user has full control of his/her browser unless you want to ship a custom altered version for an intranet crew (from open-source browser projects).

Without javascript the the only thing you can do is to send a specific parameter via GET when clicking in the required nav button. If the parameter is present you allow the view of the next/prev page, otherwise the user is logged out.

Obviously the user can bypass that by using the browser developer tools. But there is no way you can fully control user UI behavior at this level.

Fagner Brack
  • 2,365
  • 4
  • 33
  • 69
0

If i am right then you are talking about NO-Cache in broswer. you can set all these like following:

    response.setHeader("pragma", "no-cache");
    response.setHeader("Cache-Control", "no-cache");
    response.setHeader("Cache-Control", "no-store");
    response.addDateHeader("Expires", -1);
    response.setDateHeader("max-age", 0);
    response.setIntHeader ("Expires", -1);
    prevents caching at the proxy server
    response.addHeader("cache-Control", "private");

And then you can define a filter who checks session on every page. When a user logs in then set an attribute in session and on logout remove it.

Tech_Harikishan
  • 123
  • 1
  • 7
  • "like following", in other words, you have no idea what those lines of code actually do? Some of them even override the previously set one. Showing that off as an answer is somewhat ridiculous although you were close to the solution the OP *really* needs. – BalusC Jan 31 '13 at 03:12