Cookie Specification Vulnerabilitiesby 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.
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.
Consider a web store at shop.provider.com. 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, hacker.provider.com, 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.
Let's dig deeper into the technical workings of cookies. For Windows users,
cookies live as multiple files in the folder
default in Internet Explorer) or as only one file,
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.
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:
A fuller cookie description is:
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure
Here are the fields and their explanations.
NAMEis the cookie's name and
VALUEis its value. You can change the
NAMEas well as the
VALUE. The name cannot contain the space, carriage return, colon, or comma characters.
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
The path cannot be changed; it stores the
PATHwhere 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.
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.
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