Forum Discussion

Rupesh_M's avatar
Rupesh_M
Icon for Nimbostratus rankNimbostratus
May 19, 2016

How to prevent unauthenticated logins when user presses back button ?

We are working on one of the requirement..details below.

 

Work Flow

 

Users logs in to the secure website (abc.com) via PC/ Tablet/ Ipad. Once logged successfully, user browses the secure site for sometime. Then, without logging out, user opens another website (xyz.com) on the same browser (by typing xyz.com in the address-bar) and browses it. User then clicks on the back button and is now has successfully entered in to the secured site (abc.com) without re-authentication.

 

Requirement When user gets back from xyz.com to abc.com , he should not enter the website without authentication. Website should ask for authentication. How can this be achieved using F5 LTM ?

 

4 Replies

  • The Back button has been the bane of web developers since before anyone knew what Ajax was. The answer is actually pretty straight forward, but probably not what you want to hear. Let's assume that your application first authenticates a user and then issues that user a "token" in the form of an HTTP cookie. That cookie is either stored in browser memory until the browser is closed, or stored in the file system to live on between browser sessions. In any case, as long as the browser is open that cookie is still resident in memory and will be transmitted back to the site on each new request. And since this is acting as intended, the question then becomes, how do I get rid of the cookie when the user navigates away from the site. HTTP is a stateless protocol, which in this case means that if you're on a site, and then click on a link to a new site, the browser doesn't send any new information to the old site before leaving. From the server's perspective you've just stopped asking questions. So given this, you only have a few option, none of which are particularly great:

     

    1. More aggressively control session timeout - this could actually backfire on you if users pause often in your application, but it otherwise might ensure that the session token expires while the user is away looking at another site. You could employ an Ajax call under the hood of each page that asynchronously polls the web server as a keep-alive. Microsoft's OWA does this. That way the user session remains active as long as the page is resident and the JavaScript call is firing. When they leave the page the JS would stop firing and the aggressive timeout would kick in.

       

    2. Don't cache anything on your site - a terrible idea, but basically when the user hits the back button, a lot of the content (sometimes all of it) will come from their local cache and an actual request won't go to the server until they click on something. This may have to be an acceptable risk assuming you've found a good way to delete the cookie. The Back button may get them back to your site, but it'll only be a shadow of your site and any new activity will require re-authentication. Make sure of course that you include functionality that sends them back to the logon page if the cookie is missing.

       

    The thing is, unless you get rid of the cookie, users will be able to continue access without re-authenticating, and finding a way to delete the cookie is really the hard part.

     

  • Just curious, is there a way we can achieve this with an irule... Are there any events which can help this.

     

    Achieve what? Disabling caching? Sure, but again a bad idea. Instituting an Ajax keep-alive? Sure. But it really depends on where session management is happening. If session management is on the server itself, then it needs to be the one that gets the response and ultimately consumes the keep-alive.

     

  • Well i was thinking, could this be done with any event. like client accepted/http response events... i know http response or client accepted is not applicable here, just asking any other events of tcp or http which could help in achieving this...

     

    It'll be the same problem though. Let's say your application is behind your F5. Now let's say that a user is on your site, and then clicks on a link and/or goes to another site, a site that isn't behind your F5. Based on the way HTTP works, there's no signal or indication of any kind to the first site that the client has gone on to the second. There's no request, and therefore no event to trigger on. You can't really rely on TCP events (ie. CLIENT_ACCEPTED, CLIENT_CLOSED), because again HTTP is stateless. So while you're navigating a single site full of HTTP requests and responses, you'll likely pass through MANY TCP connections. In fact if you go to a page and sit there long enough (usually around 5 seconds without any sort of keep-alive), the underlying TCP connection will silently close.

     

  • Hi,

    Another solution is to check HTTP referer header. if it is not abc.com, reply to the same URI with cookie deletion.

    when HTTP_REQUEST {
        if {!([HTTP::header Referer] starts_with "https://abc.com/") && [HTTP::cookie exists "Mycookie"]} {
            HTTP::respond 302 noserver Set-Cookie "Mycookie=deleted;secure;expires=Thu, 01 Jan 1970 00:00:00 GMT" Location [HTTP::uri]
        }
    }