Question

I’m having troubles understanding this, and I think my ignorance to web exploits is to blame. My understanding of session fixation goes like this:

• Hacker uses some exploit to retrieve the session id of a currently logged in user.
• Hacker uses session id to access the site, stealing the session and effectively logging in.

It’s been recommended that you use regenerate_session_id to reduce the chances the hacker can intercept the session. Now wouldn’t that trigger regenerate_session_id, updating the hacker with the session id while simultaneously logging out the user who was originally logged in? This seems like it would cause more harm then good, so I know I must be missing something in the picture here. What am I missing?

Answer 1

session_regenerate_id is a good way to prevent session highjacking because highjacking usually occurs in a later step after the session id was stolen.

For example:

1. Visit a forum which XSS injection
2. Use clicks on a link and it steals session
3. User realizes that it’s not what he wanted, presses back
4. Site regenerates a new session id, user is saved, session fixation doesn’t occur as the session id stolen is probably not used immediately by the server.

If, for any reason, the fixation comes to be something live and very fast such as an automated process, then no, you’re right, this will not save the user. This is why you should not rely only on session_regenerate_id but also on the IP address of the user.

if(!session_id()){
    session_start();
    if(!isset($_SESSION['user_ip'])){
        $_SESSION['user_ip'] = $_SERVER['REMOTE_ADDR'];
    }
    if($_SESSION['user_ip'] !== $_SERVER['REMOTE_ADDR']){
        exit('highjacking detected, session terminated');
    }
    session_regenerate_id();
}

Obviously, if the hack comes from the same network such as a workplace, the ip detection won’t work so you can also use a UserAgent check. But this is getting a bit overkill depending on the sensitivity of your data.

Hope it helps…