How secure are $_SESSION variables?

[Callan S.]

Currently I'm checking a timestamp in the databse, and if the current time() is past it by X amount, it adds to certain $_SESSION variables, then changes the timestamp in the database to the current time (that way they can't keep raising these values by killing the session, they can only lose the values).

Sessions are stored on the servers memory, right? I've kinda heard there are security issues with using session variables - I'm not exactly interested in military levels of security, but I would like to make sure atleast easy hacks/doesn't take much effort hacks are not possible.

[Jackolantern]

Yes, session variables are stored on the web server. Two different kinds of exploits can target session variables: session hijacking, and buffer overflows. The latter is extremely difficult to do effectively (buffer overflows are excruciatingly hard to do with targeted, specific objectives). Plus, it is very easy to guard against buffer overflows: just check each bit of data sent in from the user, and make sure they are not entering data that would over-run the underlying type. The former is the more real threat to session security: session hijacking. This is done by someone creating a link that is tied in to their session and sending it to someone else, most likely in an email. That is oftentimes why people receive spoofed WoW emails and others, to try to get their session. The user presses the link but then it doesn't take them in to their account, so they log in. They have just given their session details to the email spoofer, who can now log in to their account at will. Again, this is also pretty easy to defend against. Use this function in any script that logs in a user, after you have used session_start(), but before you set any session variables:

Code: Select all

session_regenerate_id();

This function flushes out the session that the user may have surfed to your site with and generates a new one for them. This effectively "disconnects" the user from any potential exploiter's session ID.

As far as I know, as long as you use those two methods, sessions are quite safe.

[Callan S.]

Wow, that's a thorough rundown on the state of things, Jackolantern! Thanks!

That id regenerate code seems so simple - I could just start putting it under all my session starts and that's all there is to it?

[Jackolantern]

That id regenerate code seems so simple - I could just start putting it under all my session starts and that's all there is to it?

It doesn't eliminate every threat, but that is just the way web security is. Trying to make your web application 100% secure will make it so bloated it will likely not even run. All you want to do is make your application strong enough so that it is at least almost as hard as the majority of other sites, because hackers typically go after the low-hanging fruit. If your site is not in the lowest 5% of security, you will likely avoid the majority of hacker's attention.

I still do plan on making a full PHP security tutorial, but getting a solid, all-purpose data sensitization method together has slowed me down a bit. I still plan to try to get it out within the next couple of weeks.

[Rastan]

I would be greatly interested in that tutorial. I am piecing through some different things to secure what I'm making, but it seems like most tutorials only want to mention the means rather than explain or provide any example.

[Torniquet]

a way to secure your session information as far as i am aware (by what i have read) is to store them in your database.

the following link shows you how to do it and the benefits of it

http://www.devshed.com/c/a/PHP/Storing- ... -Database/

[Jackolantern]

a way to secure your session information as far as i am aware (by what i have read) is to store them in your database.

the following link shows you how to do it and the benefits of it

http://www.devshed.com/c/a/PHP/Storing- ... -Database/

Of course, I am no web security expert, but that seems like it would be less secure, since the database is always less secure than the OS or file system since it offers some limited access to the outside world. If you leave a point of access to your database un-cleansed, your sessions could be compromised by a SQL Injection attack. Getting into the file system of the web server and retrieving the session values usually means compromising the web server itself, which is usually very difficult.

Naturally, though, if web security professionals are in agreement that this is a good option, there is obviously some angle I am missing. It seemed like that article was simply showing that technique for load balancing environments, though.

[Torniquet]

i am sure it was that one (might have been another article i read) that mentioned security when you are storing sessions on the filesystem and using a shared server.

i dont understand it all myself. just what i have read lol

[Jackolantern]

Sessions are definitely less secure on shared servers, so it could have something to do with that. A very talented cracker could basically erase all of your sessions with well-placed buffer overflow attacks if they share the server with you (they could even if they don't share the server with you, but it gets them past a ton of security if they do).

[Torniquet]

well lets face it. no matter what you do, ya never really truely safe are ya