Securing cookies and sessions is vital to keeping an application secure. Many tutorials have been written on the subject, but as the internet (and browsers loading it) evolve so do the methods you can use to keep your application secure.
In this article we’re going to break down the various components of a cookie and what they mean for security. This will include limiting the cookie to certain domains and paths on those domains, choosing what information to store, and protecting the cookie from cross site scripting exploits. In a second article we will go into more depth in how to protect everyone’s favorite cookie, the session ID.
How Cookies Work
When the server wants to set a cookie it passes back a header named “Set-Cookie” with the key-value pair and some options.
On subsequent requests the client will send along its own header to let the server know the name and value of its stored cookies. The server will not continue to send back the cookies, it will only send them if there is a change.
You can see all the headers for yourself using the LiveHeaders plugin for Firefox.
This data is completely in control of the client- it is trivial to change the values of a cookie. That means that, just like post and get data, all cookie data must be validated in some way. At the same time you’ll want to avoid storing sensitive information, such as passwords, as cookies are stored in cleartext and anyone with access to the computer later can easily pick those up (I know of at least one security forum that was hacked in this way). It is also important to note that HTTP does not encrypt the headers in any way. If the connection isn’t over SSL then it will not be protected from snooping eyes.
Session cookies are no different than any other cookie- their value is just a simple ID. Those IDs are susceptible to all of the same limitations as other cookies. The real power behind sessions happens server side, where the ID is used to pull out data stored on the server. This has many benefits over storing data directly into the cookie itself- data can’t be manipulated by the user, large amount of data can be stored without having to send it back and forth with each request, and you can store data you otherwise wouldn’t want the client to have access to.
The first step towards securing your cookie is to restrict that cookie to only your application. This is especially important in environments that support multiple sites or applications (the type of shared hosting you often see on corporate or university domains). By restricting the cookie to only the applications that need it you reduce the chances of it being sniffed while also keeping the cookie namespaces clear for other applications that use them.
There are three options that can be sent along when creating a cookie that, when used properly, will keep the cookie limited to only your application. Before setting these options you will need to ask yourself a few questions-
- What parts of the website need access to the cookie?
- Will the cookie need to work across sub domains?
- Will the cookie need to persist if the user leaves an SSL portion of the site?
As you will see, how exactly to restrict the cookie really does depend on the exact purpose for that cookie. A banking or ecommerce site may restrict their cookies to only SSL, while a blog or news aggregator may want to leave things more open.
Send The Cookie To Only Your Application
The Path argument specifies what paths on the site to send the cookie. The default value of “/” means every request will get the cookie, while “/forums/” would limit the cookie to just that path. This path is going to be based on the actual URL the browser uses, before any mod_rewrite or other URL mapping.
Don’t Share With Sub Domains
The Domain option allows you to specify whether or not to send the cookie to subdomains. Setting “www.example.com” will mean only the exact domain “www.example.com” will be matched, while “.example.com” will also match again any subdomaim (forums.example.com, blog.example.com).
Require a Secure Connection
Using the Secure option you can tell the browser (or other http clients) to only send the cookie over SSL connections. This means the cookie will not be available to any part of the site that is not secure will not have access to the cookie, but it also makes it much less likely that you’ll accidentally send the cookie across as cleartext.
Protect Against XSS Exploits
The HttpOnly option is not by any means full proof. As a client-side defense mechanism it relies on browser support to work, but is only supported by a few browsers (Firefox 3+ and IE 7+, with partial support from Opera 9.5, IE6 and Chrome).
Configuring the Cookie
In PHP, setting the arguments for cookies is done through some optional arguments on the “setcookie” function:
setcookie( name, value, expire, path, domain, secure, httponly); // Open setcookie( 'UserName', 'Bob', 0, '/', '.example', false, false); // Locked Down setcookie( 'UserName', 'Bob', 0, '/forums', 'www.example.com', isset($_SERVER["HTTPS"]), true);
To change the cookie values for the session cookie requires the “session_set_cookie_params” function, which needs to be called before the session is started.
session_set_cookie_params($expire, $path, $domain, $secure, true); // Open session_set_cookie_params(0, '/', '.example', false, false); // Locked Down session_set_cookie_params('o, /forums', 'www.example.com', isset($_SERVER["HTTPS"]), true)
Cookies remain the basic method of identify tracking on most websites and keeping them secure is a vital part to keeping applications as a whole locked down and secure. In this article we went over four methods for protecting cookies on a general level.
When using cookies its important to remember to:
- Limit the amount of sensitive information stored in the cookie.
- Limit the subdomains and paths to prevent interception by another application.
- Enforce SSL so the cookie isn’t sent in cleartext.
Please check out the second half of this series, where we’re going to take the next step with an in depth guide to securing sessions.