Session Fixation
Part 1: Session fixation identification
Navigate to oredirect.htb.net
. You will come across a URL of the below format:
http://oredirect.htb.net/?redirect_uri=/complete.html&token=<RANDOM TOKEN VALUE>
Using Web Developer Tools (Shift+Ctrl+I in the case of Firefox), notice that the application uses a session cookie named PHPSESSID
and that the cookie's value is the same as the token
parameter's value on the URL.

If any value or a valid session identifier specified in the token
parameter on the URL is propagated to the PHPSESSID
cookie's value, we are probably dealing with a session fixation vulnerability.
Let us see if that is the case, as follows.
Part 2: Session fixation exploitation attempt
Open a New Private Window
and navigate to http://oredirect.htb.net/?redirect_uri=/complete.html&token=IControlThisCookie
Using Web Developer Tools (Shift+Ctrl+I in the case of Firefox), notice that the PHPSESSID
cookie's value is IControlThisCookie

We are dealing with a Session Fixation vulnerability. An attacker could send a URL similar to the above to a victim. If the victim logs into the application, the attacker could easily hijack their session since the session identifier is already known (the attacker fixated it).
Note: Another way of identifying this is via blindly putting the session identifier name and value in the URL and then refreshing.
For example, suppose we are looking into http://insecure.exampleapp.com/login
for session fixation bugs, and the session identifier being used is a cookie named PHPSESSID
. To test for session fixation, we could try the following http://insecure.exampleapp.com/login?PHPSESSID=AttackerSpecifiedCookieValue
and see if the specified cookie value is propagated to the application (as we did in this section's lab exercise).
Last updated