PHP sessions unchecked when rapid navigation occurs

Question

I have a session formed the following way:

function sec_session_start() {
$session_name = 'primary_session';
$secure = false;
$httponly = true;
if (ini_set('session.use_only_cookies', 1) === FALSE) {
    header("Location: /error?e=1");
    exit();
}
$cookieParams = session_get_cookie_params();
session_set_cookie_params(3600,$cookieParams["path"],$cookieParams["domain"],$secure,$httponly);
session_name($session_name);
session_start();
session_regenerate_id(true);
}

I use this on all my page by adding sec_session_start(); on my index page, which requires correct files depending on what page I am accessing.

It works perfectly fine with slow navigation.

However, when rapid navigational clicks occur, for some reason it unchecked, and the user is logged out. How come?

This is the button I press rapidly. NOTE: It also changes the page from www.example.com to www.example.com/users, and then just repeats www.example.com/users until session is broken.

And this is the result after about, 2-3 rapid clicks. Works fine when pressed 1-2 times a second, max.

I have tried not using it as a function, and putting it on the absolutt TOP of the page without success.

Answer 1

The error seems to be session_regenerate(true).

This command generates a new session id. The parameter will delete the old session file if it is set to true. In this code it is set to true, so the session is created an started and then directly closed and deleted.

I think it appears only a few times because the command is called after session_start() was called and the output already started.

Try changing the parameter to false. For the right use of session_regenerate() look into this question.

Answer 2

You appear to be discarding the old session ID on every page load. This is unnecessary, inefficient, and causes breakage.

If you navigate twice in quick succession what can happen here is:

• the first request hits the server and starts executing your PHP, causing session_regenerate_id(true) to destroy the old session
• this will cause the response from the PHP script to include a Set-Cookie: sessionid=something header, asking the browser to update its cookie to point to the new session
• but the browser hasn't received the response from the script quite yet
• you click a second time
• the browser discards the existing request. Any Set-Cookie header isn't going to get listened to now
• the browser makes a new request to your server. The browser doesn't know anything about a new session, so it includes the old session cookie
• your script sees the old session cookie, which points to nothing, so user has to start a new session which isn't logged in

If you have an anti-Cross-Site-Request-Forgery system based on storing a synchroniser token in the session, then regenerating the session ID on every page load will also make any forms you use inoperable when the browser has multiple tabs open on the site at once, or when the user navigates with the Back button.

You should only session_regenerate_id when the authentication associated with a session is changed (primarily, when the user logs in).

Changing session IDs does not prevent session fixation; it is only a mitigation for when session fixation has already occurred through some other means (eg a vulnerable app on a neighbour subdomain injects a cookie into the shared parent domain).

If you didn't change the session ID, then an attacker who had already gained session fixation could get a full session hijack, by giving you a session ID she already generated and knows, and letting you log in using that session, upgrading it to an authenticated session. When you change the session ID on auth boundaries that isn't possible; the worst she can do now is push you into a session in which you are unexpectedly logged in as her. Which isn't ideal, but generally this constitutes a much less damaging attack.