Does the session identifier update after a successful login to prevent the session from committing?

Question

I am currently reading a manual , and I'm a bit confused about this:

To eliminate this weakness, it helps to understand the scope of the problem. Fixing a session is just a step - the goal of the attack is to get a session identifier that can be used to capture a session. This is most useful when a hijacked session has a higher privilege level than an attacker can obtain through legitimate means. This privilege level can be as simple as being logged in. If the session identifier is regenerated every time there is a change in the privilege level, the risk of fixing the session is practically eliminated:

<?php $_SESSION['logged_in'] = FALSE; if (check_login()) { session_regenerate_id(); $_SESSION['logged_in'] = TRUE; } ?> 

If I understand this correctly, I only need to do session_regenerate_id() before assigning a value like logged_in = true or user_id = id , and then I made protection against session commit?

is that enough? What else can I do?

Answer 1

In fact, the most common session-fixing scenario is for an attacker to post a link, for example. to your homepage or login page by setting the session ID to the URL (as a GET variable) and wait for some users to log in. Since the attacker knows the session ID of these users, and since this session ID can be set in the URL, the attacker can reconsider the link to the registered user profile page / control panel, etc. And impersonating this user.

Thus, to prevent these types of attacks, regenerating the session identifier is sufficient since the attacker remains with an unauthenticated session. An additional step you can take is not to accept the session identifiers in the URL. To do this, you need to install (either in php.ini, if you have access to this file on the server or through ini_set):

• session.use_only_cookies should be set to TRUE (use only cookies for the php session id and not pass it to the url)
• session.use_trans_sid must be set to FALSE (session IDs should never be passed to the URL if cookies are disabled)

Thus, an attacker cannot even set a session identifier even for a session without verification.

Answer 2

Not. Session fixation exploits the weakness that an attacker can impose on a valid session identifier for a victim, as a result of which this session identifier is used to identify the victim's session.

Recovering a session identifier after successful authentication at least mitigates that an attacker could use a victim authentication session. But it does not prevent the use of the victim (unauthenticated) session at all.

This is why you should only allow session identifiers with cookies (see session.use_cookies_only ). Since usually an attacker cannot overwrite victims cookies (other than other attacks such as XSS or cookie formatting ).

Answer 3

You're right. As long as you change the session ID when updating user privileges, you are protected from committing the session.

Session fixing works by setting the victim's session identifier to some identifier that the attacker knows. The attacker then waits for the user to log in. If the session identifier does not change, at the moment the attacker has access to the user account (he has a session identifier). If the session ID changes, the attack is ineffective.