Two Quick Tips for Securing PHP Sessions

Feb 11, 2016 php security

This post is more than 18 months old. Since technology changes too rapidly, this content may be out of date (but that's not always the case). Please remember to verify any technical or programming information with the current release.

Let’s talk a little bit about session fixation in PHP. Such a fun topic, right? Tons to get into here. But, let’s just touch the surface on two VERY SIMPLE things you can be doing now to make sure that your website is safe.

Use Cookies

The session ID generated by PHP can be passed from the client to the server two ways. The first is via a cookie value from the browser. The second is from a get parameter in the URL.

Now, you can see the problem right away, right? Let’s say you’re logged in - and you have this url: http://mysite.com/admin.php?SID=abc123 - and you’re doing your admin work. Then, you go to the about page of the site - and realize you want to share that link with your friend: http://mysite.com/about.php?SID=abc123 This means you’ve basically given your friend the token to your session. Once they load that, they could - depending on the security of your app - act as you.

So let’s turn it off. Pretty much all sites require cookies now (yeah, I’ve seen those annoying popups everywhere!) - so let’s force ONLY cookies to be used. It’s not 100% fool-proof, but it’s a start at reducing the vector of attack.

Edit your php.ini file to have the following setting:

session.use_cookies = 1
session.use_only_cookies = 1

Chances are this is already set - and that’s good. So - that’s the bare minimum.

Moving on…

Use Session Strict Mode

So, now imagine you didn’t do the above setting - and instead - you allow session IDs in URLs. This is bad because PHP can allow you to set your own session ID if it doesn’t already exist. For example, let’s say that Bob wants to hack Sue, an administrator. He sends her to this specially crafted link: http://mysite.com/about.php?SID=abc123

PHP doesn’t have that session yet, so it starts a session with that ID. Well, later, Sue logs in and does some admin type stuff. Bob still knows the session ID - and now can use that in his browser to overtake her session. (aside: you should also regenerate your session IDs when you change access levels… so this wouldn’t matter there…)

Now, if we set it to use cookies only, it’s still not impossible - just harder (Bob needs to find a way to set a cookie in Sue’s browser with a known value.)

PHP has this setting available since 5.5.2 called strict mode. With this activated, if a session is requested with a ID that does not exist, PHP will generate a new ID instead of creating a session with that ID.

In the php.ini file, set this setting and you should be all set:

session.use_strict_mode = 1

End Notes

These are just two very BASIC session security things you should be doing - and in no way are “enough” for security. They’re just your building blocks. I’d suggest continuing on with using session id regeneration, browser finger printing, XSS/CSRF filtering, and more.