There are many different types of security vulnerabilities found in websites, one interesting one is called “Session Fixation”. Session fixation is an issue where an attacker can influence the session identifier aka the session id of a user and then use it to gain access to their account. There are two ways this type of vulnerability can work, it can allow the attacker to either find or set the session id of another user.
How a session fixation attack is performed
The session id of a user is often a key part of authentication to the website and is in many cases the only data that identifies the specific user logged in. The problem with this is that if an attacker can set or learn the session id of another user, they can use the session token and then be able to act as the user.
Typically, this is done by tricking a user into clicking a type of phishing link. The link itself is completely legitimate but includes a variable that sets a specified session id. If the user then logs in with the session ID and the server does not assign them a new session ID on login, the attacker can simply set their session id to be the same and have access to the victim’s account.
Another way the attacker can discover the victim’s session id is if it appears in a URL. For instance, if the attacker can trick the victim into sending them a link and it includes the victim’s session ID, the attacker can use the session id to access the victim’s account. In some cases, this can happen completely by accident. For example, if the user copies the URL with the session id and pastes it to a friend or in a forum, any user that follows the link will be signed in with the user’s account.
Session fixation remediations
There are a few solutions to this issue, and as always, the best solution is to implement as many fixes as possible as part of a defence-in-depth strategy. The first solution is to change the user’s session id when they sign in. This prevents an attacker from ever being able to influence the session id of a logged-in user. You can also configure the server to only ever accept session ids that it has generated and to explicitly reject any user-provided session ids.
The website should be configured to never place any sensitive user details such as session id in the URL and should place it in a GET or POST request parameter. This prevents the user from accidentally compromising their own session id. By using both a session id and a separate authentication token you double the amount of information the attacker needs to gain and prevent attackers from accessing sessions with known session ids.
It is vital that all valid session ids for a user are invalidated when the logout button is clicked. It’s possible to regenerate the session id on every request, if previous session ids are invalidated this also prevents attackers from using known session id. This approach also significantly reduces the threat window if a user discloses their own session id.
By enabling multiple of these approaches, a defence-in-depth strategy can eliminate this issue as a security risk.
Did this help? Let us know!