Security-wise, what is safer... ?

[sholodak]

I have a site that only allows access over SSL. When a user logs into the site, the site checks to see whether he/she is a superuser. The way its currently implemented, it is stored as $_SESSION['is_superuser']

The alternative that I can see is to query the users table in the database whenever I need to test this using $_SESSION['username'] as the identifier.

I guess what I'm wondering is whether it is safe to leave the superuser flag in the session rather than on the db. Is it possible--even remotely possible--for an enduser to tamper with their cookie on their machine and change this? (For the purposes of this question, assume that I'm not concerned about someone hacking into the web or db server and making the change).

Here is what I am figuring as of right now. Looking at the cookies stored after login, I only see:

PHPSESSID => 27aafc7df0f7a3c0241b3d9d4f467bd4f

I am assuming that that Session ID tells PHP where the session state is located on the web server (php/sessiondata?). If I understand correctly, tampering with PHPSESSID would only be a threat if the user coincidentally stumbled on another active session's ID with higher privileges. Given that the sessions expire after 15 minutes, I would say the probability of it happening makes it a non-issue.

Am I missing anything here? Is there anything in PHP.INI that might change this behavior if I release the application to the public and/or relocate it between servers w/different configurations? Does anyone know of a better/safer way to accomplish this? Does the HTTPS/SSL play any role in this (i.e., encrypting the PHPSESSID cookie?)?

Thanks,
Scott

[Shrike]

In short, no. The session ID is too long to 'brute force' in the timescale, and there is no setting in php.ini to cause session data to be stored on the client. Also switching between HTTP and HTTPS doesn't cause an issue, unless the secure server is a different machine to the non-secure one.

[PHPMagician]

Why not add some some security to make session hijacking even more difficult. For instance, one of the most basic checks is that you store the original IP address in the session. If a client refers to the session and has a different IP address, require a re-login. This might cause issues with some users, but not most.

It may be unfeasable to brute force a session id, but there are other ways to obtain session ids. For instance, if some where in you application XSS is possible. Or social engineering. For instance, if the PHP session id was ever passed via GET (which if you using PHP sessions functions, with default settings, they very well could be) I might ask someone: "What page are you looking at?" and many without thinking would simply copy and paste the URL.

So, to be extra safe, add more security to session managment.