session_regenerate_id() and race issue

[tork]

I notice that when I've regenerated a session_id(), that the original session remains on the server while the new one is added. I'd like to know how I can remove the old session. I may be mistaken, however I believe the issue is called racing, and is that the old session could (rarely, but possibly) be re-used if the session_id algorithm created it again, thus allowing the second user to have access to the first user's old session.

1. Do I understand the issue correctly?

2. How do I remove the old session?

[objnoob]

 http://php.net/manual/en/function.session-regenerate-id.php

 

bool session_regenerate_id ([ bool $delete_old_session = false ] )

session_start();
session_regenerate_id(true);

[tork]

Thank you. However, I need to be more specific. Is there any way of deleting a session file by naming it? EG (and I know the parameter must be void): session_destroy(session_id). Clearly this won't work. What I need is a non-regenerate method of destroying particular sessions by their session_id. If it's not removed, then user data may be picked up via the race issue. Any ideas anybody?

[requinix]

There isn't a need to name which session to delete: you want to delete the old one. The one you're changing away from. session_regenerate_id(true) will delete it.

[objnoob]

You should avoid regenerating session IDs. If security concerns you, you should be using HTTPS and ensure the session cookie is transmitted over a secure connection. 

 

http://php.net/manual/en/function.session-set-cookie-params.php  - see secure parameter

 

However, if you insist on regenerating the ID... configure your session.gc_* settings to increase garbage collection, and let the garbage collector dispose of those elderly sessions kept alive to mitigate race conditioning. 

If you're eager to reinvent the wheel and handle garbage collection yourself, you can call session_id to manually set the id the session_start function will use. 

 

Don't reinvent the wheel!

[requinix]

You should avoid regenerating session IDs.

Woah now. What's the reasoning behind that opinion?

[objnoob]

Woah now. What's the reasoning behind that opinion?

 

Race conditioning, of course!

[requinix]

...and? You're going to ignore a mechanism to prevent session hijacking because of the remote chance that a user might submit two simultaneous requests in such a way that one attempts to access the session information in the microsecond between the other closing the old session and deleting the file? Because that's literally what happens: one statement to close and unlock the file and the very next statement deletes the file.

 

Which isn't to say that you have no recourse in case the old session isn't deleted: session_regenerate_id() will raise a very nice "Session object destruction failed" warning (and return false) if that happens.

Edited November 5, 2013 by requinix

[tork]

Race conditioning and security are indeed my issues. Thanks.

[tork]

Correct me if I'm wrong, but if I session_regenerate_id(false) and set my php.ini gc parameters to a high probability to kick in after a short maxlifetime, would this not minimize the risk of a race condition?

 

I tested this, yet my session file has not been removed after 240 - I set the probability at 100% (100/100) and maxlifetime at 240 secs. Now I'm getting confused

Edited November 5, 2013 by tork

[objnoob]

Sorry, I should have answered sooner.

 

I notice that when I've regenerated a session_id(), that the original session remains on the server while the new one is added. I'd like to know how I can remove the old session. I may be mistaken, however I believe the issue is called racing, and is that the old session could (rarely, but possibly) be re-used if the session_id algorithm created it again, thus allowing the second user to have access to the first user's old session.

1. Do I understand the issue correctly?

2. How do I remove the old session?

 

You have a misunderstanding of the issue.

A race condition is created when 2, almost simultaneous, requests are sent to the server with the current session id, and you're actively regenerating session ids and immediately deleting the old session.

These two requests are literally racing!  The winner, if you will, will trigger the id regeneration and delete the old session. This leaves the second request using the old session id that points to an invalid / nonexistent session.

A new *empty* session is created, for the second request, using the old session id.

 

IMPORTANT: If the second request happens to call session_id that is setting the id in any way, shape, or form, a new cookie is sent with the response that will overwrite the recently regenerated session id. Now the session data is up shit's crick and your user is without a paddle. 

[tork]

Thanks for that clear explanation.

 

As a matter of understanding session parameters, I set the probability at 100% (100/100) and maxlifetime at 240 secs. Then I ran a session and timed the session record for when it got deleted. I expected it to delete in 4 minutes from the start of the session (session_start()). Yet it's been there much longer. Am I missing something here?

[objnoob]

...and? You're going to ignore a mechanism to prevent session hijacking because of the remote chance that a user might submit two simultaneous requests in such a way that one attempts to access the session information in the microsecond between the other closing the old session and deleting the file? Because that's literally what happens: one statement to close and unlock the file and the very next statement deletes the file.

 

Which isn't to say that you have no recourse in case the old session isn't deleted: session_regenerate_id() will raise a very nice "Session object destruction failed" warning (and return false) if that happens.

 

There are other ways to prevent session hijacking!

• Create a token that is strictly transmitted through the URL.
• Check if IP and/or User-Agent of the client have changed, if so, force re-authentication. ( not that I rec ommend this, but... )
• Configure php.ini properly.
• Always call session_set_cookie_params ( $secure=true, $httponly=true ) before calling session_start.

[objnoob]

Thanks for that clear explanation.

 

As a matter of understanding session parameters, I set the probability at 100% (100/100) and maxlifetime at 240 secs. Then I ran a session and timed the session record for when it got deleted. I expected it to delete in 4 minutes from the start of the session (session_start()). Yet it's been there much longer. Am I missing something here?

 

Either --

1. You're not deleting the session cookie, and when you come back with that cookie -- a new session is created, but with the same session id. this isn't the same ol' session... it's a new session with the same id.
2. You're accessing the active session using session_start and the session file lifetime is resetting.
3. The garbage collector isn't firing because you're not making a request that calls session_start().

[tork]

Great! Thanks again.