Session hijacking is the act of taking control of a user session after successfully obtaining or generating an authentication session ID. Session hijacking involves an attacker using captured, brute forced or reverse-engineered session IDs to seize control of a legitimate user's Web application session while that session is still in progress.
HTTP is stateless, so application designers had to develop a way to track the state between multiple connections from the same user, instead of requesting the user to authenticate upon each click in a Web application. A session is a series of interactions between two communication end points that occurs during the span of a single connection. When a user logs into an application a session is created on the server in order to maintain the state for other requests originating from the same user.
Applications use sessions to store parameters which are relevant to the user. The session is kept "alive" on the server as long as the user is logged on to the system. The session is destroyed when the user logs-out from the system or after a predefined period of inactivity. When the session is destroyed, the user's data should also be deleted from the allocated memory space.
A session ID is an identification string (usually a long, random, alpha-numeric string) that is transmitted between the client and the server. Session IDs are commonly stored in cookies, URLs and hidden fields of Web pages. A URL containing the session ID might look something like:
In an HTML page, a session ID may be stored as a hidden field:
Sometimes, cookies are set to expire (be deleted) upon closing the browser. These are termed "session cookies" or "non-persistent" cookies. Cookies that last beyond a user's session (i.e., "Remember Me" option) are termed "persistent" cookies. Persistent cookies are usually stored on the user's hard drive. Their location is determined according to the particular operating system and browser (e.g.,
C:\Documents and Settings\username\Cookies for Internet Explorer on Windows 2000).
There are several problems with session IDs. Many of the popular websites use algorithms based on easily predictable variables, such as time or IP address, in order to generate the Session IDs, causing their session IDs to be predictable. If encryption is not used (typically SSL), Session IDs are transmitted in the clear and are susceptible to eavesdropping.
Session hijacking involves an attacker using captured, brute forced or reverse-engineered session IDs to seize control of a legitimate user's session while that session is still in progress. In most applications, after successfully hijacking a session, the attacker gains complete access to all of the user's data, and is permitted to perform operations instead of the user whose session was hijacked.
There are three primary techniques for hijacking sessions:
- Brute force - the attacker tries multiple IDs until successful.
- Calculate - in many cases, IDs are generated in a non-random manner and can be calculated.
- Steal - using different types of techniques, the attacker can acquire the Session ID.
In brute force attacks, the attacker can try many IDs. For example, take a look at the following list of URLs, in which an attacker is trying to guess the session ID:
Session IDs can be stolen using a variety of techniques: sniffing network traffic, using trojans on client PCs, using the HTTP referrer header where the ID is stored in the query string parameters, and using cross-site scripting attacks.
In a "referrer" attack, the attacker entices a user to click on a link to another site (a hostile link, say www.hostile.com):
GET /index.html HTTP/1.0
The browser sends the referrer URL containing the session ID to the attacker's site - www.hostile.com, and the attacker now has the session ID of the user.Session IDs can also be stolen using script injections, such as cross-site scripting. The user executes a malicious script that redirects the private user's information to the attacker.