Security on websites is based on session management. When a user connects to a secure website, they present credentials that testify to their identity, usually in the form of a username and password. Because the HTTP protocol is "stateless," the web server has no way of knowing that a particular user has already logged in as they browse from page to page. Session management allows the web-based system to create a 'session' so that the user will not have to re-authenticate every time they wish to perform a new action, or browse to a new page.

In essence, session management ensures that the client currently connected is the same person who originally logged in. Unfortunately however, sessions are an obvious target for a malicious user, because they may be able to get access to a web server without needing to authenticate.

A typical scenario would involve a user logging on to an online service. Once the user is authenticated, the web server presents this user with a "session id." This session ID is stored by the browser and is presented wherever authentication is necessary. This avoids repeating the login/password process over and over. It all happens in the background and is transparent to the user, making the browsing experience much more pleasant in general. Imagine having to enter your username and password every time you browsed to a new page!


The session ID itself is simply a string of characters or numbers. The server remembers that the session ID (SID) was given to the user and allows access when it is presented. As a result, the Session ID is of great value and malicious users have, for years, searched for ways to compromise it and use it to circumvent authentication mechanisms. Session Management is all about protecting this session ID, and in modern day interactive web applications this becomes critical.

So how to get your hands on a Session ID? There are a number of techniques attackers use to compromise a Session ID. The most obvious is to attack the server. The server often stores the session ID somewhere, and more worryingly, the server sometimes stores the session ID in a world-readable location. For example, PHP stores its session variables in the temporary /tmp directory on Unix. This location is world-readable, meaning that any user on that system can easily view the session IDs with basic utilities that are part of the Unix API. This is serious risk, particularly on shared hosts since many users will be active on the system. This issue has since been addressed but it is just one example.