Session Hijacking - regenerate session ID

Question

Does regenerating the session ID on each request mitigate the probability of a session hijack enough to be worth implementing?

I would imagine combining a check for REMOTE_ADDR vs the REMOTE_ADDR stored in the session variables, along with a 30 minute inactivity timeout and a constantly changing session id should mitigate the risk to an acceptable level.

Additionally, are there any other concerns with regenerating a session id? Do I need to explicitly destroy the old session for each new regeneration?

Finally, would regenerating the session id on every request become too resource intensive on a large deployment to justify vs the security advantages?

Answer 1

I've seen implementations that tried this approach and ended up pulling it because yes it can cause resource issues and race conditions across Web farms. It sounds like a good idea at first, but can also make your application more prone to denial of service attacks if the regeneration process is too cryptographically intensive. Answer there is to pregenerate session IDs periodically and keep a cache available, but then you have to manage the cache securely.

Some more common solutions to securing session ID variables is to

• use SSL
• only generate the authenticated session ID after successful login over SSL, else you become vulnerable to session fixation
• generate cryptographically random and unguessable tokens
• expire session IDs frequently
• properly expire then server-side on log out
• mark the session ID cookie as HttpOnly and 'secure'

Answer 2

I suppose it depends on how you would implement this whole thing, but the liklihood is that you would run into a host of runtime issues tracking the changing session id's.

Would it help? Not really. You can spoof REMOTE_ADDR, and catching the session id before it changes is pretty straightforward: catch it and use it before the user makes another request.

The better idea would be to encrypt the cookie value(s), only connect via HTTPS, set the cookie lifetime to something very short/set session lifetime to something very short, set the cookies to HttpOnly (not accessible via JavaScript -- only part of the newer browsers though), and finally, use framework session management -- don't roll your own. :)

Answer 3

You should make sure your session expires and tokens are of course reliable and randomly generated.

However, from all these answers, I think the strongest point is to use SSL - but for the entire session.

Even if you login via SSL, and use normal http from then on, regenerating sessions from each subsequent request, and do all the good things mentioned above, there is really no way to guarantee that a user's session cannot be hijacked in some way. You really need to ensure that the transport of the entire session prevents eavesdropping and hijacking - which SSL was designed for.

The use of remote addresses is also pretty moot when it comes to NATed firewalls.

If you then need to go one step further in ensuring that a particular client's machine is the only machine that could login, you could issue a client certificate, which the user would load into their browser, and the server would request this during the SSL negotiation.

Answer 4

The best one I have seen in common usage regenerates the session identifier after secure login, and associates the identifier with the client machine. The application's security wrapper checks for concurrent logins (disallowing a new one until the old one has finished and ID expired) expires the ID on browser close or logout and also has a fairly short expiry time (10 minutes)

In conjunction with the other security features it was appropriate for the purpose (an online consumer banking application) without overloading the system.