A common question I get asked is:
|Should you really be storing the users' flags in a session? That's dangerous!|
Where are Sessions stored?
This is the question that will quash all those questions on are sessions safe. Anything can be unsafe in PHP if the programming is not up to par. Generally speaking, however, sessions are 1 section of the PHP language that is difficult to mess up.
Core of a Session File
Remember the times when you used to crack open the cereal boxes to retrieve the free plastic toy from inside? Well, sessions are not quite as exciting as that. In fact, sessions are pretty uneventful on the inside. Let's take the following PHP code and execute it normally:
That's all there really is to a session file. Remember that the session file is stored server-side so there is absolutely no need to transfer any information you do not publish in the HTML over the insecure medium we like to call the Internet.
Point of the Session ID
Now, this is where our delivery method comes in. Cookies are the most frequently used due to the extra security they add (not much, but just enough to be the favoured method). The other possible methods are GET (which is sometimes used) and POST (which I've never seen used but essentially it could be used with a little difficulty). Unlike GET and POST which can be used in such attacks as CSRF (see our article on CSRF for further information) and passed around to potential victims with far too much ease, cookies are just that little more difficult to install on a victim's computer.
I could quite easily send a link to you and have you either hijack a session on my behalf, or the most common reason would be to fixate your session ID (see the following post for more information about session fixation). Although, if I am unable to pass you the session ID easily then it's going to be more difficult for me to breach the target website's security and assume your identity. Consider the following link and how easily it can be passed around:
So where has this all been leading? Well, there is an important setting that is set to 1 by default (and should always be set to 1 unless you wish to also support users who do not have cookies enabled - which is not recommended) that prevents the session IDs from being transferred via a GET and to use only cookies - the safest delivery method. That setting is:
Upon loading the website where my session ID was created, the cookie is sent to the website and parsed by PHP. The session ID is correctly linked to the session file stored server-side and is then unserialized and placed into the pre-populated PHP array, $_SESSION. Once I have issued the session_start() command to begin my session I am able to access all the information - even crucial and highly sensitive information, from the $_SESSION array.
Note: Although you may store highly insensitive information in sessions, be aware that displaying it on your website will mean that crucial information is being sent over the pipes of the Internet. Without using SSL this would be a very insecure method of delivery which would be crying out to be intercepted by Harry the hacker.
Basic Session Security Example
Assume that our banking system has absolutely no extra security implemented. This is exceedingly unlikely so don't be frightened!. You have logged in and been issued a cookie containing your session ID, our banking system also erroneously accepts the GET method of delivery though to ensure everybody can use their system. Remember, all Harry the hacker (not Harry the hamster) needs to assume your role is your session ID. Nothing more, in this example.
Harry decides to go down the route of session fixation and thus sends you the following crafty link:
5aff2, clicks on the link himself and is able to withdraw your entire life savings of 67 pence.
As sessions do absolutely no extra security checks on your behalf, the system simply thinks it is you because the session ID is correct. It is up to YOU to implement the extra security to prevent such instances from occurring.
Locks up your Daughters
Some mean looking guy approaches your door after trampling on all your pretty flowers without a care in the world, loudly knocks on the door and demands to see your daughter. He may well know your daughter's name but who is he? The who is he part is crucial - it's as crucial as not assuming that because someone has the correct session ID that you should let them in. Until the mean looking guy can answer some of your questions, you're not letting him see your daughter. Oh no, no!
To give a simple question of what you can ask the end user when it comes to sessions is:
|Are you using the same browser as you were previously?|
- You have switched your browser half way through and would like to continue your session seamlessly.
- Somebody is attempting to hijack your session using your session ID that they have acquired from somewhere
Which point, 1 or 2, would you rather assume was true? Surely assuming the former and allowing a user to carry on their session seamlessly would be less likely than the latter? Assuming the latter will also save any embarrassing security hiccups. By destroying the user's session and asking them to re-login has to be the better option just in case. Any legitimate user will not mind this slight inconvenience if they know their 67 pence is safe. After all, once the security has been breached, it is difficult to return that level of trust back to its normal levels.
Nonetheless, the browser name, version, language, etc. are all sent by the end user's browser during the HTTP call. This means that this data may not even be sent at all. It is optional. As long as you know it is optional you can check for if the intended array even exists before using it. This is important because a blank string will always produce the same MD5 or SHA1 (etcetera...) hash. A null string MD5'd will always be d41d8cd98f00b204e9800998ecf8427e no matter how many times you use MD5. Whilst SHA1 will be different to the MD5 string, it will still be the same for every single time you hash the null string using SHA1.
Shared Hosts can be Little Buggers
Now that you fully understand the following:
[Session File] (Server) [Cookie File] (Client)
You may think your session file, because it is server side, is safe. That simply isn't the case, I'm afraid. A session file can simply be opened by anybody who has access to your file system. For instance, my sessions are stored in the following directory as plain files:
Luckily the directory can be moved elsewhere or you can even use a table inside a database to store all your session data. The latter is best saved for another article to keep this 1 short and sweet (ok, shortish and sweetish). The following setting can be changed to alter the destination of our session files:
The next time somebody asks you if sessions are really the way to go, that if storing crucial information in session data is insecure, chuckle in their face and refer them to TalkPHP!