This article is continuation of my previous post explaining general principles of sessions between a server and users.

I will try to cover some basic security rules and methods of taking over someone else’s session.

What does it actually mean to hijack a session?

As the SessionID (stored on the user’s side) is the main indicator in a server side authentication process, to possess someone’s session means basically to possess its SessionID value. An obvious way to gain someone’s SessionID is to steal it. This can be stolen directly from a victim’s computer files system, from the link address or by eavesdropping on user’s request to the server. Essentially, the attacker tries to steal the value of the session identifier and then utilizes it to gain access to server’s session data. Sketch below presents that method:

session-hijacking1

A more sophisticated way of possessing victim’s session is called “session fixation”. In this case, the attacker doesn’t need to steal anything. Furthermore, the attacker’s strategy is reversed (well, sort of). He tries to inject the given SessionID into victim’s browser. Once the SessionID is fixed on user’s computer, the attacker tries to force user to authenticate on the server (for example by encouraging him to click on a link containing the SessionID). Later, if the victim has authenticated using an injected session identifier, the attacker can use the same SessionID to access private data on the server. A sketch describing that manner is attached below:

session-hijacking2

How to prevent session hijacking?

Unfortunately there is no golden remedy that would prevent a users SessionID from being stolen; or prevent the server from accepting an attacker’s malicious requests. But there are some good practices which used may mitigate the risk.

On server’s side:

  • keep the user’s IP and browser agent in a session, then check if it’s not changing during the same session
  • store SessionID in HttpOnly cookie (it’s much harder to steal the value of such a cookie)
  • require user re-login to access sensitive areas
  • regenerate the SessionID after successful login over SSL
  • use SSL over the whole site

On the user’s side:

  • don’t authenticate to sites with sensitive data using public WiFi networks
  • don’t click on suspicious link’s
  • make sure no one has remote access to your computer and cannot access your cookies directly in your files system (installing anti-virus software may be beneficial)
  • logout from services like facebok/gmail/e-banking once you’ve finished using them (it destroys your session on the server)

I hope you have found this post constructive, comments are always welcome and appreciated. 🙂