Tuesday, 27 December 2011

How PHP sessions work

This post is about how PHP sessions work, not how to use them as I'm sure most of you already know that and if not there are plenty of websites that will tell you.  I've just noticed that a fair few developers don't understand how they work, I think this is in part because a lot of places that teach you how to use them don't actually tell you how they work.  One problem with this approach is that by default PHP sessions are not all that secure but this is easily fixed, I'm hoping this post will explain how they work and highlight some of the potential security holes associated with PHP sessions.

Breif background on HTTP & Cookies
Websites use the Hypertext Transfer Protocol (HTTP) version 1.1 (RFC 2616 for those who like technical documentation) to send pages and data across the Internet, one of the problems with HTTP for developers is that it's a stateless protocol.  This means that nothing is saved between each server request (such as a page load) on the client and there is no reliable method of uniquely identifying a user between page requests.  I'm sure someone reading this has just thought that the users IP address would be unique but this isn't true as quite often many people will share the same IP address, for example a family household all using the same Internet connection will show up as all having the same IP address on your server.

People realised this problem and came up with cookies to extend HTTP (RFC 2109) and allow it to be stateful, more about how HTTP and cookies relate to each other will be covered in another post.  That was a basic overview of why cookies exists and what they try to achieve, to allow unique identification of users and remember the state of their browsing session.

I'm sure most of you are aware the are two other methods that can used called GET & POST variables but they are not directly related to this post and I'll be covering more about them and how they relate to PHP sessions in another post.  I just wanted to give a bit of information about cookies and why they exist as PHP sessions often use them.

How PHP sessions work
Firstly if used correctly sessions are the most secure method of storing data unique to a user and identifying them but it is reliant on things which are almost always outside of your control so no sensative data such as passwords should be stored in session variables.  In my opinion data stored in session variables should be hashed or encrypted where possible although a lot of the time this just wouldn't be practical or useful and just cannot be done, just worth keeping in mind.

When a PHP session is created firstly a random id is generated by the server which is used to uniquely identify the session.  A file is then created on the server (typically in the /tmp directory of your web server by default) with the generated id as its name and the session information such as the variables you have stored in that session are stored in a serialised form in that file.  A cookie is also set on the client browser and by default is named "PHPSESSID" with its value set to the same unique id used for the file name stored on the server.

Every time the client browser makes a request to the server it passes this cookie in the HTTP header to the server so it knows which session file is associated with the client and it unserialises it so you as a developer can access the session associated with the client as an array, using code such as $_SESSION['variable']'].

Most of what I've written above is just what happens by default but most of it can be changed either in the PHP script or in the php.ini file, some examples of what could be changed are:
  • The session id stored on the client is passed in the URL or as a post variable rather that as a cookie although this is less secure, more about that in the next post.
  • Making cookies the only method used to store the session id.
  • Ensuring cookies are only passed over a secured connection or only over HTTP (so JavaScript scripts cannot access it).
  • There are many more things, far more that I can list here, you can even write your own session handler rather than using the default one or store all your session data in a database rather than in a file.  For more information about what you can change have a look at the PHP manual, so you know a lot of these are settings in the php.ini file but if you don't have access to directly modify it you can use the ini_set function in your script.  I'll write another post in the future about storing sessions in a database but a very good explanation of it can be found on Chris Shiflett's website.
If you think anything I've written is incorrect, that I've missed something or just that you didn't understand something please leave a comment and I'll get right back to you.

Merry Christmas


Hope everyone had a great Christmas, I just spent it with the family eatting lots and lots, watched a bit of TV and open preseants, so it was brilliant!

Now that Christmas is just behind us I'll be adding more to this blog, the next post will be about how PHP sessions work and a bit about keeping them secure.

Thursday, 22 December 2011

Secure PHP login Introduction

Hello again all!

Firstly I'm very happy to see a few people have read my blog already!  I wasn't expecting anyone to see this yet, but I'm very grateful people have done.  I know I only just made my first blog post today but as you may have noticed in there I've already started one of my projects and I've almost reached the first milestone :).  So in this post I'm going to write about what this project is, what I'm hoping it will accomplish and some of the features it will have.

What I'm trying to build is a generic class for a secure PHP login system which will be easily integrated into most sites and used as an authentication system.  I've started building this a few weeks ago between my other work but today I've create a Google code project for it and committed what I've done so far, currently it's not at a stage where it is usable but it's very close but I'd say there's around 20% left to go including testing before it's at a stage where it could be implemented.  My main motivation for creating this is so when I'm building CMS system (I have a few sites I want to make for my self which could use this), I don't have to keep recreated all or even just part of the authentication system.

Currently the Google code project for this doesn't have much on it but I will be adding to the Wiki soon which will technical information about how the code actually works and why things have been done the way they have.  I would like to point out that although I have been coding for some time I am by no means a self-proclaimed expert so if you see any flaws, either in the code itself or even in some of my general concepts please do leave comments or send me a message about it.

I've covered what I basically want this project to achieve here is a list of features I'd eventually want to have built in:

  • Secure login page that knows what page you were originally requesting and forwards you onto it after successful authentication.
  • Authenticating the user with each server request 'behind the scenes' so they are not re-entering their password each time.
  • Protect against hacking attempts such as session hijacking, session fixation, sql injections and others (leave a comment about any you can think of).
  • Sanitise any inputs that come from outside the class, including the database it is pulling data from.
  • Have configuration options to customise aspects of the class, such as what the salt & pepper (will be explained in another post soon) is, the table storing user credentials and more.
  • Two factor authentication compatible with various methods such as YubiKey, one time codes generated on the server, Google authenticate one time code generator (like the one that can be enabled for any Google account).
  • Login using other authentication services such as Google, Facebook, OpenID and others.
This post has gotten quite long now so I'll leave it there, if there are any other features you think would be good or security concerns I should look out for please leave a comment.

Welcome to web code musing


This is my first ever blog post!  I decided to start blogging as there are quite a few development projects that I want to get going and hopefully when completed or at certain stages of completion I'll put them online so anyone who wishes to use my code can do so, also it would be good to get feedback from people to see if the way I'm developing it would actually be useful to anyone else and if they find any bugs / flaws.

So what kind of projects will I be posting about?  Well as I'm primarily a PHP developer so they'll be mainly PHP based projects, I've put a list below of some of the projects I have in mind.  I'm hoping to get these projects onto somewhere like Google code so I can keep it versioned online and people can easily get hold of the code, if anyone knows of any good places to host code please leave a comment and let me know.

Eventually I'll be moving this blog over to my own domain but I want to code my own Content Management System (CMS) for it so it'll take a little while.  Although I have built custom CMSs before and they don't really take that long it's just with a full time job and having other things to do leave me with only a limited amount of time to do my own projects.

Now that's the introduction over with if you want to know a little about me I'm a website developer leaving in Wiltshire, England but working for a pharmaceutical marketing and advertising company in Hampshire as a website developer and occasionally a designer.  I do take on some smaller freelance work as I don't have much time to do more than that.  I work and have worked with some well known clients like TalkTalk, Marks & Spencer and Durex among others.  In my spare time I tend to do quite a lot of outdoor rock climbing which is pretty much my only sport.  They'll be more on my profile soon for you to read up on if you're really interested (now updated).