How it works

Unsafe session IDs handling of session IDs can expose users to attacks. Websites with normal user accounts implement an authentication mechanism to identify users and return them to users. After authentication, the session will be created. The server and browser understand each session ID , so the server can identify the user with each HTTP request. If hackers have access to another user’s session ID, they can impersonate another user. SESSION FIXATION is an attack method that hackers use to do that.

In this article, Mal will show you how this vulnerability works, if you do not know about this character, you can find out in your series . Suppose your website passes session IDs in your query string (probably few people do so: v). Mal make the URL does not contain session ID: www.hmstr.com?jsessionid=STEALING_UR_DATA .

Vic is a user of your system, he loves hamsters, and also assumes Mal knows your email, or guesses. He sent Vic an email with an interesting link about a hamster pointing to a link he crafted

Vic click on the link, assuming he is not logged in, your page will redirect to the login page. It will accept the previous session ID edited by Mal on the URL. Once Vic has logged in successfully, the session is established, and he can enjoy a gif of a hamster:

However, Mal can now access the path he sent to Vic , and he can also access the Vic ‘s session, ie he is logged in with Vic ‘s account.

Protect

In general, it is also rare, easy to exploit and very dangerous.

With this type of attack, hackers can bypass your authentication method, and worse, it’s hard to detect when it happens. There are several ways to combat this vulnerability.

Do not pass Session ID in the GET / POST variable

Passing the session ID in the query strings , or in the body of the POST request is the problem. Additionally, session IDs can be leaked in the following ways:

1. If the user follows an external link (the Referer header will describe where the browser comes from).
2. In browsing history and bookmarks.
3. in the log on the server and any proxy servers.

It is better to pass an HTTP cookie, such as with PHP, you can use session_regenerate_id (true)

Regenerate session ID when authenticating

Because the session ID was created, Mal created did not match anymore

Only accept session ID on server side

It is good practice to make sure only the server is allowed to create session IDs.

Set Timeout and replace the old session ID

Periodically resetting the session ID reduces the risk of this error.

Implementing the logout function is strong enough

The logout function should mark the session ID as expired.

Request new Session when accessing from suspicious Referrers

Consider logging in again if it is accessed from another source.

summary

This is how protection and session fixation works, hopefully useful for you. Happy coding!