Home > Guides > Security > General Security and Privacy

Security Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

How Not to Use Cookies

Last updated May 23, 2003.

Within one week's time, we stumbled across two different sites using cookies the wrong way. While the attack vectors were a bit different, both sites trusted the cookie data to secure their users’ accounts. Therefore, this week we are going to spend some time discussing cookies, when they should be used, and what can happen if they are misused.

What are Cookies?

Before a web developer can understand the dangers associated with trusting cookies to store sensitive data, it is important to recognize what they are, and what they aren't. Specifically, a cookie is just a small text file that is stored on your computer by a specific website. Cookies are not programs, they can't read your personal data, and they don't cause spam. In fact, cookies can be very helpful if used within the correct context.

Cookies are often used by marketing and advertising companies. For example, the Informit.com website placed one cookie on my computer with the following information:

Domain: .doubleclick.net
Name: id
Content: 800000a5610cc5a
Path: /
Expires: Friday, November 06, 2009 9:23:14 AM

Let's break this cookie down so we can understand its intent. First, you can easily tell who the cookie belongs to — doubleclick.net. But why did a doubleclick.net cookie come from Informit.com? Well, if you go to Informit.com website, you will see a banner ad at the top of the browser window. This content is controlled by doubleclick.net, which probably pays Informit.com (or a partner) to insert their ad at the top of the pages content.

The next significant part of the cookie is the Name and Content fields, which in this case have a value of 'id' and '800000a5610cc5a' respectively. This value pair is my personal identification code that can be used to track my movements across the internet and build a profile about my surfing habits. This is possible because a cookie can be read at any time by the domain that owns it. As a result, when I visit Slashdot.org, doubleclick.net will attempt to read its cookie that is on my computer. This will provide doubleclick.net with my id value, and their database will be updated. In other words, they now know that I like to visit Informit.com and Slashdot.org. Already their profile on my surfing habits can tell them I am probably a computer geek.

The final significant part of the cookie is the Expires value. Since it expires in 2009, doubleclick.net could gather a significant amount of data about my surfing habits, which would then be sold or used to dynamically load ads that target people with my "profile." Obviously, this has some serious privacy concerns, which is why we recommend the blocking/removal of cookies used by ad agencies.

Cookies do have many user friendly functions. For example, web applications like PHPBB (PHP Bulletin Board) use cookies to store unique session id values. These session values are used by the web application to validate a user after they have logged in to the program. This way, the user doesn't have to keep entering their user/pass each time they want to access a secure part of the website. The program will simply request the session id in the cookie, look it up in a database, and determine that the session is authenticated.

Other uses for a cookies are to store usernames/passwords, or to temporary store web application information. For example, cnn.com uses cookies to store the users preferences as to what version of cnn.com should be displayed by default (international vs. national).

Security Risks

While cookies can help web developers offer services and features that would require extensive programming otherwise, there are some significant security risks that must be understood before cookies are ever implemented into a website.

First, cookies are stored as plaintext on the user's computer. This means anyone can read them at any time from the local machine. This includes a nosy family member, but also includes the user of the website. In other words, web developers can never assume that the cookie data is a place to store sensitive data.

Second, cookies are passed as plaintext unless there is an encrypted session. As a result, anyone with a sniffer can capture the cookies contents and use them as their own. In other words, if a person logs into a web application at an unprotected wireless hotspot, an attacker can grab the session value and insert it into their own cookie, thus hijacking the session from the valid user.

Third, and possibly the most significant, cookies can be stolen via cross-site scripting exploits on a vulnerable web application. For example, numerous blogging sites have been found to have persistent XSS vulnerabilities over the last few years. If a malicious hacker wants to steal a user's session id cookie information, they can easily do this by injecting a simple "document.cookie" request into a blog post. This type attack can be used to steal hundreds of session values, all of which can be used by the attacker to collect sensitive information or create chaos by posting fake content under a stolen account.

To illustrate the problems that improper cookie use can lead to, we are going to look at one example that not only exposes user information, but also can lead to the theft of valuable gift certificates.

Restaurant.com

Restaurant.com is an excellent site that offers discounted gift certificates to restaurants throughout the nation. Recently, they held a promotion where you could buy a $25 gift certificate for $4. We like to eat out on occasion, so we purchased a couple certificates from the website. During our purchase, we were monitoring our cookies with the AnEC Cookie editor extension for Firefox that allows a user to view, delete, and edit cookies easily and quickly. During our online session at Restaurant.com, we noted that there was little in the way of a unique identifier to keep our session open, yet we were able to move about the site and maintain our login status. Figure 1 provides a shot of AnEC and a list of the cookie names.

Figure 1

Figure 1: AnEC viewing restaurant.com cookie names

Note the list of names. Normally, you would see a "session', 'id," or similar name listed. However, restaurant.com does not appear to have any per session value. So, what then could it be using to keep track of a users logged-in status?

After looking at the list, we considered the idea that the session information was stored in the web page itself and was passed as hidden form fields. This option is used by ASP.NET web application and allows a cookieless environment. While not fool proof, using the ASP.NET session tracking option is generally considered more secure than relying on cookies. However, after a quick look, it was determined that restaurant.com was not using this type of session management.

So, our attention turned back to the cookie. After reviewing the list, we took a closer look at the names and their values:

ShopperState

PA

httpref

http%3A%2F%2Frestaurant%2Ecom%2F

ShopperEmail

somevalue%somedomain%2Ecom

ShopperName

joe+schmoe

Memberlastlogindate

11%2F7%2F2006+12%3A40%3A11+AM

ShopperZip

12345

ShopperCity

noland

DateLastPurchase

09%2F31%2F2006+7%3A24%3A00+AM

DateLastLogIn

11%2F9%2F2006+12%3A40%3A00+AM

Memberemail

somevalue%somedomain%2Ecom

Memberloggedin

true

Can you guess which item might be tracking our login status?

To test our theory, we needed access to another valid account. So, we created a second account and logged into it on a different computer. This way the cookies would remain separate and not interfere with each other. After creating the account, we altered the memberemail value of our original cookie to match the email address of the new account. We then hit the refresh button on the browser and were granted access to the second account. To further confirm this, we found another person in the office that had signed up for a restaurant.com account ($4 gift certificates are popular) and asked if we could attempt to "hack" their account. They agreed and we inserted their email address into the cookie, which again gave us full access to their account information (user/pass/address) AND all their unused gift certificates.

In short, Restaurant.com keeps track of the users session by checking the email address to see if it is valid — that's it. There is no need for a password. A malicious person could use this to clean out any account they know the email address to, thus depriving the legitimate owner of their gift certificates. In addition, the attacker would be able to see the target’s password, which is probably used for many other online services.

Summary

In summary, cookies are a useful tool, but they come with a lot of potential for abuse. Not only will advertisers attempt to track your online activities, but poorly designed web applications inadvertently create security holes that malicious attacker can exploit to gain access to your account data. Since they are plaintext, and can be easily altered, cookies must never be used to store sensitive data. As illustrated, poor cookie design can lead to exposed user information and financial loss.