SESSION FIXATION

• What is Session Fixation ?

Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID.


The attack consists of inducing a user to authenticate himself with a known 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.

• Attack Scenario :

1. Mallory has determined that http://unsafe/ accepts any session identifier, accepts session identifiers from query strings and has no security validation. http://unsafe/ is thus not secure.

2. Mallory sends Alice an e-mail: "Hey, check this out, there is a cool new account summary feature on our bank, http://unsafe/?SID=I_WILL_KNOW_THE_SID". Mallory is trying to fixate the SID to I_WILL_KNOW_THE_SID.

3. Alice is interested and visits http://unsafe/?SID=I_WILL_KNOW_THE_SID. The usual log-on screen pops up, and Alice logs on.

4. Mallory visits http://unsafe/?SID=I_WILL_KNOW_THE_SID and now has unlimited access to Alice's account.

• Attack Process :

1. Session Setup:

First, the attacker either sets up a trap session on the target server and obtains that session’s ID, or selects a arbitrary session ID to be used in the attack. In some cases, the established trap session needs to be maintained by repeatedly sending requests referencing it to avoid idle session timeout.


2. Session Fixation:

Next, the attacker needs to introduce her session ID to the user’s browser, thereby fixing his session.

3. Session Entrance:

Finally, the attacker has to wait until the user logs in to the target server using the previously fixed session ID and then enter the user’s session.

• Attack Example :

1. First, the attacker, who in this case is also a legitimate user of the system, logs in to the server and is issued a session ID 1234.

2. Then he sends a hyperlink http://online.worldbank.dom/login.jsp?sessionid=1234 to the user, trying to lure him into clicking on it.

3. The user clicks on the link, which opens the server’s login page in his browser.



4. Upon receipt of the request for login.jsp?sessionid=1234, the web application has established.

5. Finally, the user provides his credentials to the login script and the server grants him access to his bank account.

6. At this point, knowing the session ID, the attacker can also access the user’s account via account.jsp?sessionid=1234.

• Countermeasures :

1. Web applications must ignore any session ID provided by the user’s browser at login and must always generate a new session to which the user will log in if successfully authenticated.

2. If possible, a web application on a strict system should only issue session IDs of newly generated sessions to users after they have successfully authenticated.

3. Session identifiers in URL (GET or POST variables) are not recommended as they simplify this attack. The session identifier on most modern systems is stored by default in an HTTP cookie, which has a moderate level of security. Use of the SSL/TLS session identifier is very secure.




Happy Hacking...Enjoy...

For educational purpose only...Do not misuse it...