Sessions and cookies: Adding state to a stateless protocol

Introduction

HTTP is a stateless protocol. This means that each request is handled independently of all the other requests and it means that a server or a script cannot remember if a user has been there before. However, knowing if a user has been there before is often required and therefore something known as cookies and sessions have been implemented in order to cope with that problem.

On page two we will look at cookies and sessions will be covered on page three. On page four we will talk a bit about security.

Cookies

Cookies are small text files placed on the client's computer. They are transmitted via headers sent forth between the client (in this case the browser) and the web server.

When the server tells the browser to set a cookie, the header might look something like this:

Set-cookie: has_been_here=yes

This tells the browser to save a cookie with the name has_been_here and the value of that cookie should be yes.

The full syntax of that header is:

Set-Cookie: <name>=<value>[; <name>=<value>]... [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; httponly]

We will talk about the other options later. When a browser has cookies for a specific page it will send them in a header like this:

Cookie: <name>=<value> [;<name>=<value>]...

In our above example it would then be:

Cookie: has_been_here=yes

So far so good... To make this a bit easier for us, PHP has some functions that will help us in using cookies. An important function is setcookie(). This function enables us to set cookies with the options explained above for the Set-Cookie HTTP response header.

Because the setcookie() function is sending headers, it is important that you call this function before any content has been output to the browser. Headers are always at the top of an HTTP response, so once you start outputting content you will not be able to send any more headers.

Setting cookies

The first two parameters of the setcookie() function ($name and $value) are obvious. They are setting the name and the value of the cookie, respectively. The other ones might not be so obvious. $expire is for how long the cookie should last. This is expressed with a Unix timestamp. You will have to set the date and time of when the cookie should expire. You will not be able to make a cookie that lasts "forever", but you can make the cookie last a long time (several years for instance). If you want to set a cookie that lasts 30 days, then you could get the timestamp like this:

$expire = time() + 60 * 60 * 24 * 30; // or 2592000
// ... or ...
$expire = strtotime('+30 days');

Both of those two things will get the current timestamp and add 30 days to it. You can then pass that value to the third parameter.

The fourth parameter, $path, is used to control which scripts that can access the cookie. This is relative to the document root. Say for instance you have http://example.com/forums/index.php and you want to set a cookie using that file. If you set the path to /forums, then the cookie will only be accessible to scripts within the /forums path. If you leave it blank then there is no restriction.

The fifth paramter, $domain, works much like $path does. However, this time the restriction is which domains that can access the cookie. If we say that you both have www.example.com and forums.example.com then setting $domain to forums.example.com will mean that the cookie is only accessible from the forums subdomain. You can also set it to .example.com and then all subdomains for example.com (e.g. www and forums) will be able to access it.

If you are using a free host where your domain name will be a subdomain of the host's domain (e.g. mysite.awesome-host.biz or something like that) then you might want to ensure that only your specific subdomain will be able to access your cookies so all the other users won't eat them.

$domain defaults to the hostname from which it was set. This means that example.com will not be able to get example2.com's cookies.

The two last parameters are a bit more advanced. If you set $secure to true then you are telling the browser to only send the cookie back to the server if the connection is encrypted using SSL (i.e. on a secure connection). $httponly is used to only transmit the cookie to the server, i.e. client-side scripting languages like Javascript will not be able to use them. This is a useful way of dealing with XSS.

Getting cookies

The cookies that are available will always be accessible using $_COOKIE. This variable holds an associative array of all cookies. To get the has_been_here cookie from earlier, you would access it using $_COOKIE['has_been_here']. $_COOKIE is a super-global so you will always be able to access it in PHP no matter where you are in the script.

When you set a cookie on a page it will not be immediately accessible through $_COOKIE, so don't try to use it.

An example of using cookies

Here is an example of a small script using cookies:

<?php
$visits = intval($_COOKIE['visits']);

setcookie('visits', $visits + 1, strtotime('+30 days'));

if ($visits == 0) {
	echo 'I have never seen you before, but I am glad you are here :)';
}
else {
	echo 'Welcome back! You have been here ', $visits, ' time(s) before';
}
?>

Try to upload the script to your web server and see what happens. Then try to refresh a couple of times and see the changes. We have now successfully added a state to a stateless protocol.

On the next page we will look at another way of doing this through the usage of sessions.

Sessions

Another popular method is using sessions. Sessions are very similar to cookies, but they are distinctive in a few important ways. While cookies are stored on the client machine, sessions are stored on the server.

The way sessions work are by generating a random ID for the user. This ID is stored in a cookie on the client machine. PHP will then fetch all session data related to that ID from wherever it is stored. By default it's stored on the harddisk, but it's possible to write your own save handler so you can store it in e.g. a database. By default, the cookie will be called PHPSESSID and will expire when the browser is closed.

Seeing as you are using a cookie for identifying the user you'll need a way to set the same settings for the cookie as we did before. For this purpose you can use the session_set_cookie_params() function. It has the following syntax:

session_set_cookie_params(int $lifetime[, string $path[, string $domain[, bool $secure[, bool $httponly]]]])

Using session data

Before you are able to use sessions you'll have to call session_start(). This function will, like when setting cookies, have to be called before any output has been sent to the browser. Once this has been done, storing data in sessions and retrieving the values is quite easy:

$_SESSION['has_been_here'] = true;

Like $_COOKIE, $_SESSION is a super-global as well.

An example of using sessions

This is how the script we made using cookies on the previous page will look if we decide to use sessions instead:

<?php
session_start();

$visits = $_SESSION['visits']++;

if ($visits == 0) {
	echo 'I have never seen you before, but I am glad you are here :)';
}
else {
	echo 'Welcome back! You have been here ', $visits, ' time(s) before';
}
?>

Sessions without cookies

Sessions do not always have to use cookies. Whatever value you choose for the session name (PHPSESSID by default) just have to be present somewhere. It could for instance be through the URL like this: http://example.com/index.php?PHPSESSID=jfJk87Hfja87Hajhsd97Hash or it could be through a form field (either via POST or GET). The manual has more information about this, but I would recommend you just use the cookies.

On the next page we will talk a bit about security...

Security issues

Because the cookies are transferred unencrypted (unless you are using SSL) and because they will be stored in plaintext on the client computer, it is not advised that you store any sensitive information in the cookies. Such information could, for instance, be the username and/or password. For purposes such as authentication it would be best to store a unique identifier in a cookie and store the rest of the information on the server. In that way it never leaves the server and therefore it is stored in a safe manner (providing your server is secure). Seeing as sessions do this, they would be a better choice for that purpose.

An instance where you would not want to use sessions instead of cookies would be if you need Javascript or another client-side scripting language to access the information. Seeing as session data is stored on the server, there is no way whatsoever it can be access from the client machine. Again, this information should not be sensitive.

A problem related to this is a security issue known as XSS (Cross Site Scripting). This vulnerability exists if users are able to post information (via a form or the URL for instance) and that information is redisplayed on a page without being properly escaped. In that way a malicious user will be able to execute any arbitrary Javascript code on the client machine without the user or you knowing it. The reason why this is a problem regarding cookie and session security is that cookies will be default be able to be viewed by Javascript. There are a number of different ways you could deal with this. The first and most obvious one is to properly escape all output coming from a user. The function htmlentities() can take care of that. Another way is by setting the httponly parameter for your cookies. In that way the browser will not give Javascript access to the information that cookie holds. If you are using sessions, then you can call session_regenerate_id() on every request. By doing that the user will get a new session ID each time and it means that if a malicious user ever gets a session id, chances are it will be invalid by the time he gets to try it because it changes often. You can use any combination of these three things (although you should always do the first). Stealing the session IDs and attempting to use them is known as session fixation. There are plenty of resources available regarding both XSS and session fixation available if you want further information regarding those two subjects.

Conclusion

That's all I have to say about cookies and sessions right now. With this new information you will be able to remember things about your users.