To session_regenerate_id() or to session_regenerate_id(true)

[ajoo]

Hi all,

 

I have been coding in php now for almost an year but yet i feel like a newbie when it comes to sessions !! That's an honest confession. 

 

Like many newcomers I too came across the sec_session_start() which is  a common function that is easily found on the net for people looking for a secure login script. Here is the function:

function sec_session_start()
{
        $session_name = 'secure_session_main'; // Set a custom session name
        $secure = false; // Set to true if using https.
        $httponly = true; // This stops javascript being able to access the session id.
        ini_set('session.use_only_cookies', 1); // Forces sessions to only use cookies.
        $cookieParams = session_get_cookie_params(); // Gets current cookies params.
        session_set_cookie_params($cookieParams["lifetime"], $cookieParams["path"], $cookieParams["domain"], $secure, $httponly);  
        session_name($session_name); // Sets the session name to the one set above.
        session_start(); // Start the php session
        session_regenerate_id(TRUE); // regenerated the session, delete the old one.
}

I used it in my login page and on the other pages of my application. It seemed to work fine and then it started to create problems. I wrote about it on this forum. Every time I would click on a button or a link on my page, i would get logged out. I discussed that issue on this forum but no solution was found. Then I found that if I removed the (TRUE) from the session_regenerate_id(), things became fine. So I removed the TRUE and proceeded wanting to come back here at a later time like now. I was actually quite pleased that I had found a solution to my problem.

 

But now while reading more on session_regenerate_id, I came across a number of articles that said that not using session_regenerate_ID with the argument TRUE is not effective in preventing session hijacking or was it session fixation.

 

The articles pointed as also some of the answers to the questions in the forums that session_regenerate_id should be used only when 1. logging in, 2. logging out & 3. when privileges change.

 

However I am using this sec_session_start on each and every page of my application instead of using session_start() and I want to use this function to use the session_regenerate_id(TRUE) since that it seems is more effective against the session attacks. 

 

The latest issue that I have encountered is the generation of an error message that says " session_regenerate_id(true) failed. 

 

I would like to ask if I my using the sec_session_start() on each and every page is incorrect & too oft used usage of the function. In that case what should I use on the beginning of each of those pages to start a session? I would like to know if there is any flaw in my thought process above? And anything else related that would shed some more light on using the session_regenrate_id(TRUE) in the above function. Basically the right way to initiate a new session securely . 

 

PS - my program seems to work correctly otherwise. Even when the error is generated "session_regenerate_id(true) failed", the variables in the application remain intact and save properly. If I remove the (TRUE) all problems seem to cease but then, like I mentioned above, the discussions I have read say that that usage is ineffective against session attacks.

 

Thanks loads.  

Edited February 15, 2015 by ajoo

[scootstah]

You do not need to regenerate the session ID on every page load. You'd normally only do that in cases where privileges change, or you enter a heightened area, etc. An example would be after a user logs in, you would want to regenerate the session ID after successful login.

[ajoo]

Hi thanks for the reply. 

 

I would like to ask that in that case what should I use on the rest of the pages ? Would a simple session_start() suffice ? How safe would that be for session security? 

 

Kindly clear my doubts. 

 

Thanks !

[scootstah]

Yes, just a session_start().

 

It doesn't really have any bearing on session security. What I mentioned above only really helps when a session is actually compromised. It's an additional measure to try to make sure that a compromised session can't actually do anything special. For example, if you're an authenticated user going from a normal page to a restricted page, and want to do some restricted action, then the user should be re-authenticated (just have to enter their password) first. Then, regenerate the session. This elevated session should expire after a little bit of inactivity (10-15 minutes). In this way, if a user's session was compromised, the attacker may not actually be able to do anything without knowing the user's password.

 

The best way to deal with session hijacking is to take every step to prevent it from happening in the first place. Here's some common things:

 

- If on shared hosting, do not use the default session storage. Save it to your local web root, or to a database or something. Make sure if you do file-based sessions that the permissions are such that other system users can't access it.

- Make sure you do not have any XSS vulnerabilities.

- Make sure that the session cookie is using the "httponly" flag. This prevents it from being accessed client-side.

- Optionally, you could choose to track the user IP and browser that created a session. By comparing these past and present values you might be able to detect a hijacked session. This isn't definitive because the user might be able to manipulate the values. Still though, it can be effective at times.

- There are some additional entropy options that you can use to generate stronger session ID's. Have a look at these:

http://php.net/manual/en/session.configuration.php#ini.session.entropy-file

http://php.net/manual/en/session.configuration.php#ini.session.entropy-length

http://us2.php.net/manual/en/session.configuration.php#ini.session.hash-bits-per-character

http://us2.php.net/manual/en/session.configuration.php#ini.session.hash-function

 

Also, check out this phpsec article. It helps you to understand how session hijacking and fixation occurs and ways to prevent it.[/url]

Edited February 17, 2015 by scootstah

[ajoo]

Thanks ! That was really clear, concise & informative. Will go through the related articles. 

 

Much obliged.

 

Thanks again !

[ajoo]

Hi  scootstah ! 

 

Thanks for that reply once again. I have read through all that information. phpsec.article was really nice though not conclusive. But then I guess any solution related to sessions security cannot be 100% conclusive. Still Thank you. 

 

Just one or two points that I would still like to clear. 

 

1. Supposing my script uses php_regenerate_id() at the beginning of each page, then it would leave a trail of phpsessid's in the tmp folder which are not deleted.

 

Now would these pose a security threat 

 

1. While the user is still browising the website?

2. Even after the user has logged out ?

3. The user has not logged out but simply closed the browser?

 

How would that threat be posed or how can these phpsessid's be used to gain unauthorized access?

 

Thanks loads.

Edited February 17, 2015 by ajoo

[scootstah]

If you have a bunch of abandoned sessions laying around then it increases the chances that someone could guess a session ID.

 

Again, you don't need to or want to be regenerating a session ID on every page load. What happens if a user opens your site in another tab? Now the session in the first tab will be expired. Also think about async requests from AJAX or such.

[ajoo]

HI scootstah ! 

 

Thanks for the reply. Definitely I am removing the sec_session_start() from all my page starts. No the reason I am asking this is that I want to be as sure as possible on Sessions. I am asking this to remove all my doubts about sessions regenerate id.

 

So thanks again for the reply.

 

PS. I also wish to add to anyone looking for similar information that last year I had asked a near similar question on this very forum and Advanced Member Jacques1 had also provided a most complete & comprehensive answer to it. Searching in My Content in my account today  came across it and could really appreciate the answer provided by Jacques1. This would be incomplete without a link to that answer. Please find attached the heading under which I had asked the question and Jacques1 had replied: The answer I marked as the best answer.

 

secure login, strong(est) session ID's and secure site navigation

Thanks scootstah and Jacques1