Session fixation Attack

Session Fixation is an attack that allows an attacker to takeover a valid user session. When authenticating a user, it doesn’t assign a new session ID, and use an existent session ID. The attack consists of obtaining a valid session ID (e.g. by connecting to the application), inducing a user to authenticate himself with that session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim's browser use it.

In session fixation the attacker steals the established session between the victim and the Web Server after the victim logs in. Instead, the Session Fixation attack fixes an established session on the victim's browser, so the attack starts before the user logs in.

Execution of this attack generally depends on how the Web application deals with session IDs. Below are some of the most common techniques used to deal with session IDs:

• Session ID in the URL: The Session ID is sent to the victim in a hyperlink and the victim accesses the site through the malicious URL. e.g http://site.com/login?sesseionid=12345
• Session ID in a hidden form field: In this method, the victim must be tricked to authenticate in the target Web Server, using a login form developed for the attacker. The form could be hosted in the evil web server.
• Session ID in a cookie:


1. Client-side script  Most browsers support the execution of client-side scripting. In this case, the aggressor could use attacks of code injection as the XSS (Cross-site scripting) attack to insert a malicious code in the hyperlink sent to the victim and fix a Session ID in its cookie. Using the function document.cookie, the browser which executes the command becomes capable of fixing values inside of the cookie that it will use to keep a session between the client and the Web Application.
2. <META> tag <META> tag also is considered a code injection attack, however, different from the XSS attack where undesirable scripts can be disabled, or the execution can be denied. The attack using this method becomes much more efficient because it's impossible to disable the processing of these tags in the browsers.
3. HTTP header response This method explores the server response to fix the Session ID in the victim's browser. Including the parameter Set-Cookie in the HTTP header response, the attacker is able to insert the value of Session ID in the cookie and sends it to the victim's browser.

Exploiting Session Fixation:

This is a simple example of session fixation attack

1. The attacker has to establish a legitimate connection with the web server which issues a session ID 
2. Then the attacker has to send a link with the established session ID to the victim, 
3. Victim has to click on the link sent from the attacker accessing the site, the Web Server saw that session was already established and a new one need not to be created.
4. The victim provides his credentials to the Web Server knowing the session ID
5. Now the attacker can access the victim account by replaying the same session ID for which the victim authenticated.

Testing for Session Fixation vulnerabilities:
The first step is to make a request to the site to be tested (example www.example.com). If the tester requests the following:

GET www.example.com

They will obtain the following answer:

HTTP/1.1 200 OK
Date: Wed, 14 Aug 2008 08:45:11 GMT
Server: IBM_HTTP_Server
Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Path=/; secure
Cache-Control: no-cache="set-cookie,set-cookie2"
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html;charset=Cp1254
Content-Language: en-US

The application sets a new session identifier JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 for the client.

Next, if the tester successfully authenticates to the application with the following POST HTTPS:

POST https://www.example.com/authentication.php HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com
Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1
Content-Type: application/x-www-form-urlencoded
Content-length: 57

Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in

The tester observes the following response from the server:

HTTP/1.1 200 OK
Date: Thu, 14 Aug 2008 14:52:58 GMT
Server: Apache/2.2.2 (Fedora)
X-Powered-By: PHP/5.1.6
Content-language: en
Cache-Control: private, must-revalidate, max-age=0
X-Content-Encoding: gzip
Content-length: 4090
Connection: close
Content-Type: text/html; charset=UTF-8
...
HTML data
...

As no new cookie has been issued upon a successful authentication the tester knows that it is possible to perform session hijacking.