In a session fixation attack, the attacker fixes the user’s session ID before the user even logs into the target server, thereby eliminating the need to obtain the user’s session ID afterwards. This is accomplished by the attacker first going to the website and obtaining a valid session ID. Then the attacker sends a link that contains that session ID to an unsuspecting victim.

The victim clicks on the link, goes to the website and logs in. Now, the attacker sends another request to the website, say for the account information page. Since the attacker also sends the same session ID as the logged in victim, the website thinks they are the same user and sends the attacker the requested information. This results in the session being hijacked.

. Attacker connects to the server

. The server generates a session token and sends it to the attacker

. Crafts a URL containing the session token and emails it out

. Victim clicks on the link and logs in to the site with the same session token

. Server thinks it is the same user and retains session token

. Attacker sends another request to the server with the session token and hijacks   
  the victim’s session

Crafting a URL and emailing it out is just one method among many to set a victim’s cookie. If some page or sub host on the same domain is also vulnerable to XSS (cross-site scripting) attacks, that can be exploited to set the client’s cookie value with the appropriate session token. This method stands a better chance of success since email links may not be clicked on by users, but users may visit the vulnerable URL(s) on the website that they are already on.

Session Fixation is an attack technique that forces a user's session ID to an explicit value. Depending on the functionality of the target web site, a number of techniques can be utilized to "fix" the session ID value. These techniques range from Cross-site Scripting exploits to peppering the web site with previously made HTTP requests. After a user's session ID has been fixed, the attacker will wait for that user to login.Once the user does so, the attacker uses the predefined session ID value to assume the same online identity.

Generally speaking there are two types of session management systems when it comes to ID values. The first type is "permissive" systems that allow web browsers to specify any ID. The second type is "strict" systems that only accept server-side-generated values. With permissive systems, arbitrary session IDs are maintained without contact with the web site. Strict systems require the attacker to maintain the "trap-session", with periodic web site contact, preventing inactivity timeouts.

Without active protection against Session Fixation, the attack can be mounted against any web site that uses sessions to identify authenticated users. Web sites using sessions IDs are normally cookie-based, but URLs and hidden form fields are used as well. Unfortunately, cookie-based sessions are the easiest to attack. Most of the currently identified attack methods are aimed toward the fixation of cookies.

In contrast to stealing a users' session IDs after they have logged into a web site, Session Fixation provides a much wider window of opportunity. The active part of the attack takes place before a user logs in.

Example

The Session Fixation attack is normally a three step process:

  1. Session set-up

  The attacker sets up a "trap-session" for the target web site and obtains that 
  session's ID. Or, the attacker may select an arbitrary session ID used in the 
  attack. In some cases, the established trap session value must be maintained 
  (kept alive) with repeated web site contact.

  2. Session fixation

  The attacker introduces the trap session value into the user's browser and 
  fixes the user's session ID.

  3. Session entrance

  The attacker waits until the user logs into the target web site. When the user
  does so, the fixed session ID value will be used and the attacker may take 
  over.

Fixing a user's session ID value can be achieved with the following techniques:

Issuing a new session ID cookie value using a client-side script*

A Cross-site Scripting vulnerability present on any web site in the domain can be used to modify the current cookie value

Code Snippet:

  http://example/< script>document.cookie="sessionid=1234;%20domain=.example.dom
  ";< /script>.idc

Issuing a cookie using the META tag

This method is similar to the previous one, but also effective when Cross-site Scripting countermeasures prevent the injection of HTML script tags and not meta tags.

Code Snippet:

  http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20
  domain=.example.dom">.idc

Issuing a cookie using an HTTP response header

The attacker forces either the target web site, or any other site in the domain, to issue a session ID cookie. This can be achieved in many ways:

 . Breaking into a web server in the domain (e.g., a poorly maintained WAP server)
 . Poisoning a user's DNS server, effectively adding the attacker's web server to the domain
 . Setting up a malicious web server in the domain (e.g., on a workstation in Windows 
   2000 domain, all workstations are also in the DNS domain).
 . Exploiting an HTTP Response Splitting attack

Note: A long-term Session Fixation attack can be achieved by issuing a persistent cookie (e.g., expiring in 10 years), which will keep the session fixed even after the user restarts the computer.

Code Snippet:

  http://example/< script>document.cookie="sessionid=1234;%20Expires=Friday,
  %201-Jan2010%2000:00:00%20GMT";< /script>.idc