I read a guide currently, and I am bit confused over this:
To address this weakness, it helps to understand the scope of the
problem. Session fixation is merely a stepping-stone—the purpose of
the attack is to get a session identifier that can be used to hijack a
session. This is most useful when the session being hijacked has a
higher level of privilege than the attacker can obtain through
legitimate means. This level of privilege can be as simple as being
logged in. If the session identifier is regenerated every time there
is a change in the level of privilege, the risk of session fixation 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 make a session_regenerate_id() before I assign a value like logged_in = true or user_id = id and then I have made a protection against session fixation?
Is this enough? What else can I do?
Actually, the most common scenario with session fixation is that the attacker will place a link e.g. to your homepage or login page, setting the Session id on the url (as a GET variable) and wait for some users to login. Since the attacker then knows the session ID of these users and since this session ID can be set in the url, the attacker can revisit the link to the registered user's profile page/dashboard etc and impersonate this user.
Thus, to prevent such kinds of attacks, session id regeneration is adequate, as the attacker remains with an unauthenticated session. An additional step you could take is to not accept session IDs in the url. To do this, you have to set (either in php.ini if you have access to this file on the server or via ini_set) the following:
- session.use_only_cookies should be set to TRUE (use only cookies for php session id and don't pass it via url)
- session.use_trans_sid should be set to FALSE (session IDs should never be passed via url if cookies are disabled)
This way, the attacker cannot even set the session id even for the unauthenticated session.
No. Session Fixation exploits the weakness that an attacker can foist a valid session ID on a victim, whereby that session ID is then used to identify the victim’s session.
Regenerating the session ID after a successful authentication at least mitigates that the attacker can use the victim’s authenticated session. But it doesn’t prevent using the victim’s (unauthenticated) session at all.
That’s why you should only allow session IDs via cookies (see session.use_cookies_only). Because normally an attacker can’t overwrite the victim’s cookies (except from other attacks like XSS or cookie forcing).
You are right. As long as you change the session id when you upgrade the user privileges, your are protected against session fixation.
Session fixation works by setting a victim's session id to some id the attacker knows. Then the attacker waits for the user to login. If the session id doesn't change, at this point the attacker has access to the user's account (he has his session id). If the session id changes, the attack is uneffective.
