Security DevCenter
oreilly.comSafari Books Online.Conferences.


Cookie Specification Vulnerabilities

by Alexander Prohorenko

Why Do We Need Cookies?

The HTTP protocol is "disposable" in one sense. Each time the user requests a page, he begins all over again, no matter what he entered and which changes he made. There's no state to the protocol.

Cookies help to create the illusion that the site remembers a user. The user does not need to enter the same information from page to page or from session to session, because of the cookie stored on the user's disk. It is possible that the user can always edit or replace this information, too. A cookie can store various data -- for example, the quantity of page hits and their time. Cookies make it possible to create interesting web applications, such as a small organizer or a basket in virtual shop.

Cookie Insecurities

Many people dislike cookies because of their insecurity. However, many different analysts claim that there is no a problem, that it's absolutely impossible to make anything harmful with cookies. I deeply disagree: if someone can read the information from a cookie, it is already unsafe. I'll provide several theoretical examples that are easy to implement in reality.

  1. Suppose a user visits a webmail site and has filled in the form with his login and the password. These are stored in a cookie, though the site uses SSL. A burglar has emailed the user an HTML-formatted message with JavaScript capable of reading the cookie and its password, then tricking the user into sending the information to the burglar by popping up a false message such as "JavaScript Errors." This will even fool some experienced users into pressing OK and passing along the data. Alternately, the bad guy could add an invisible frame to hold cookie information at the bottom of the letter. This is all easy with HTML forms and a little JavaScript.

  2. Consider a web store at While making purchases in this shop, the site stores user information in a cookie. In parallel or before browsing the shop, the user browsed the attacker's page,, where malicious code could adjust the shop's cookie, changing the quantity of purchases, a name, the address, and anything else stored in the given cookie. It would be unpleasant to purchase unknowingly a few monitors for someone else, or to have your purchases sent to another user. This is a simple enough attack once you have a page in the second or third level of the shop's domain.

There are other similar ways to harm systems, including several different JavaScript tricks including removing all of your cookies.

Inside Cookies

Let's dig deeper into the technical workings of cookies. For Windows users, cookies live as multiple files in the folder %WINDOWS%\Cookies (by default in Internet Explorer) or as only one file, cookie.txt (if you have Netscape Navigator or other browsers). Sites periodically add or remove cookie information. Naturally, the cookie specifications stipulate some elements of protection.

  • You can have only 300 cookies.
  • Cookies cannot exceed 4kb in size.
  • You cannot get more than 20 cookies from one second-level domain (including sub-levels).
  • A cookie created by one second-level domain is invisible to other second-level domains.
  • Cookies are not cached even if the HTML document is.
  • Cookies can be read and written over SSL.

When the browser reaches 300 cookies, it should throw out the earliest cookies. If a cookie exceeds 4kb, the browser should cut out the first bytes.

Cookie Format

Netscape maintains a full cookie specification. Describing it goes beyond this article, so I will include here only general information.

Cookies store information as VARIABLE = VALUE pairs. One document can consist of a few cookies (less than 20). The absolute minimum cookie description is:

Set-Cookie: NAME=VALUE;

A fuller cookie description is:

Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME;

Here are the fields and their explanations.


    NAME is the cookie's name and VALUE is its value. You can change the NAME as well as the VALUE. The name cannot contain the space, carriage return, colon, or comma characters.

  • expires=DATE

    This is the date when the cookie will expire. You can change only DATE. If expires is not set, the cookie will persist until the user closes her browser.

    expires=Mon, 10-Apr-2002 03:00:00 GMT
  • path=PATH

    The path cannot be changed; it stores the PATH where cookie will be sent. By default, if this field is not set, cookie will work only in the current directory. If the path is /, this cookie will affect all directories on the server.

  • domain=DOMAIN_NAME

    This sets the domain name where this cookie is active. It will also work for all sub-domains. This works only with COM, EDU, NET, ORG, GOV, MIL, and INT. It does not work in regional or other zones.
  • secure

    If this field exists, it means that this cookie will only work with HTTPS (HTTP with SSL). If it does not exist, HTTP is OK.

Pages: 1, 2

Next Pagearrow

Sponsored by: