PHP: $_SESSION - What are the pros and cons of storing temporarily used data in the $_SESSION variable

Question

Well Session variables are really one of the only ways (and probably the most efficient) of having these variables available for the entire time that visitor is on the website, there's no real way for a user to edit them (other than an exploit in your code, or in the PHP interpreter) so they are fairly secure.

It's a good way of storing settings that can be changed by the user, as you can read the settings from database once at the beginning of a session and it is available for that entire session, you only need to make further database calls if the settings are changed and of course, as you show in your code, it's trivial to find out whether the settings already exist or whether they need to be extracted from database.

I can't think of any other way of storing temporary variables securely (since cookies can easily be modified and this will be undesirable in most cases) so $_SESSION would be the way to go

$_SESSION mechanism is using cookies.

In case of Firefox (and maybe new IE, I didn't check myself) that means that session is shared between opened tabs. That is not something you expect by default. And it means that session is no longer "something specific to a single window/user".

For example, if you have opened two tabs to access your site, than logged as a root using the first tab, you will gain root privileges in the other one.

That is really inconvenient, especially if you code e-mail client or something else (like e-shop). In this case you will have to manage sessions manually or introduce constantly regenerated key in URL or do something else.

I use the session variable all the time to store information for users. I haven't seen any issues with performance. The session data is pulled based on the cookie (or PHPSESSID if you have cookies turned off). I don't see it being any more of a security risk than any other cookie based authentication, and probably more secure than storing the actual data in the users cookie.

Just to let you know though, you do have a security issue with your SQL statement:

SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=".$_GET['wave_id'];

You should NEVER, I REPEAT NEVER, take user provided data and use it to run a SQL statement without first sanitizing it. I would wrap it in quotes and add the function mysql_real_escape_string(). That will protect you from most attacks. So your line would look like:

$query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id='".mysql_real_escape_string($_GET['wave_id'])."'";

There are a few factors you'll want to consider when deciding where to store temporary data. Session storage is great for data that is specific to a single user. If you find the default file-based session storage handler is inefficient you can implement something else, possibly using a database or memcache type of backend. See session_set_save_handler for more info.

I find it is a bad practice to store common data in a user's session. There are better places to store data that will be frequently accessed by several users and by storing this data in the session you will be duplicating the data for each user who needs this data. In your example, you might set up a different type of storage engine for this wave data (based on wave_id) that is NOT tied specifically to a user's session. That way you'll pull the data down once and them store it somewhere that several users can access the data without requiring another pull.

If you're running on your own server, or in an environment where nobody can snoop on your files/memory on the server, session data are secure. They're stored on the server and just an identification cookie sent to the client. The problem is if other people can snatch the cookie and impersonate someone else, of course. Using HTTPS and making sure to not put the session ID in URLs should keep your users safe from most of those problems. (XSS might still be used to snatch cookies if you aren't careful, see Jeef Atwoods post on this too.)

As for what to store in a session variable, put your data there if you want to refer to it again on another page, like a shopping basket, but don't put it there if it's just temporary data used for producing the result of this page, like a list of tags for the currently viewed post. Sessions are for per-user persistent data.