24 August 2009
How to Create Totally Secure Cookies
-->
0
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
Cookies are simply key/value pairs that let us get around HTTP being a stateless protocol. When a developer has data they wish to last for more than one connection they can use cookies to store that data on the client side. While this tends to get handled by the programming language being used it is accomplished using HTTP headers.
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.
The Problem
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.
Getting Started
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?
There is also a forth option used by newer browsers to restrict access to cookies by javascript.
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.
Cookie Options
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
This HttpOnly flag is used to tell the browser that it should not allow javascript to access the contents of the cookie. This is primarily a defense against cross site scripting, as it will prevent hackers from being able to retrieve and use the session through such an attack.
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)Summary
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.
- Make the cookie HttpOnly so its not accessible to javascript.
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.
Enjoy this article?
If you liked this article, feel free to re-tweet it to let others know. Thanks, we appreciate it :)
This post was written by
Robert Hafner
Robert is the cofounder of SolunaNet, a web development firm in Massachusetts. His most recent projects include application and server development for Malwarebytes and the open source project Mortar. You can follow him on Twitter at @tedivm.
Related Articles
We love .net Magazine
We're big fans of .net so they've hooked us up with a rad deal: Save 50 percent on your subscription.
24 באוגוסט 2009
How to Create Totally Secure Cookies
הירשם ל-
תגובות לפרסום (Atom)
אין תגובות:
הוסף רשומת תגובה