Thursday, 12 January 2012

PHP session security: Part 1 - Considerations


I thought I'd make a post about the main security considerations around PHP session security, this will be the first in a few posts about this subject; the others will go more in-depth and give you practical information.

The first thing to remember is that PHP sessions are not secure by default as many may think.  I've listed all the ones I can think of below and will expand on them in my next post, I'll probably separate some of the points into their own posts too as I'm trying to keep these at a reasonable length.  If you can think of any that I've missed here please leave a comment.
  • Session storage location by default PHP stores its sessions in the /tmp directory of your web server which can be an issue in a shared server because everyones sessions are stored in the same place and you all have access to that directory and its files.
  • Session ID storage on the client can be insecure if passed in the URL rather than in a cookie, POST data can be fairly secure as long as the connection between the client and server is secure (same is true for using cookies) but can often be more awkward to use.
  • Session fixation which is a method of a hacker setting the users session id to something they want so they'll know what the session id is and can impersonate them.
  • Session hijacking is when a hacker finds out what the users session id is and uses it to impersonate them, different to fixation because the hacker in this case is finding out what the session id is rather than setting it themselves.
  • Using a secure connection for all sensitive data sent between the client and server, such as their login credentials and the cookie data.
  • Securing cookie data so it cannot be accessed by anyone else or by any JavaScript used by a hacker on the clients browser.
  • Making the session id non-guessable (if that's even a word), this one is fairly easy as PHP has a pretty random method of generating the ids that would be next to impossible to guess anyway (as far as I'm aware) by default, but you can write your own if you liked.
  • Not storing sensitive data in the session or the cookie held on the client, even if you do everything possible to keep it all secure you're still reliant on the client browser being secure so it doesn't just give the information out to anyone.  Unfortunately this isn't always the case, notably in internet explorer, although as far as I'm aware there isn't currently any security holes in any major up-to-date browsers but I could be wrong but even if I'm right by the time you read this things could have changed.
Other parts in this series:

No comments:

Post a Comment