Tag Archives: cookie

Cookie path

http://security.stackexchange.com/questions/12439/cookie-path-protection-within-same-domain

 

The cookie path doesn’t provide any security (in most real-world situations).

It is important to understand that the cookie spec is ancient technology. It dates back from the earliest days of the web. The security model of the web has evolved since then, and become more carefully thought-out. The security model for cookies hasn’t evolved correspondingly.

As another example of impedance mismatches between the web’s security model and cookies, the same-origin policy treats http://www.example.com:80 as a different origin from http://www.example.com:81, but they are treated as identical for purposes of cookies. You can find more discussion of security oddities with cookies from Michal Zalewski.

Cookies can be read by Javascript. While the browser may take the path into account when Javascript tries to read cookies, this is not a security feature: the path is not a security boundary, so malicious Javascript on one page can still read cookies for other paths (e.g., by opening an invisible iframe with the proper path, injecting malicious Javascript into it, and then grabbing the cookie). The only effective security boundary is at the granularity of an origin. As a result, the bottom line from a security perspective is: malicious Javascript on http://www.example.com/dogs can read a cookie whose path is http://www.example.com/cats.

In practice, developers typically avoid these corner cases that are left over from earlier days, or at least avoid relying upon them to provide extra security. For instance, web developers should not rely upon the cookie-path to provide security (at best it reduces the number of cookies sent back, which could perhaps be used to reduce bandwidth in some situations). As another example, sites these days usually avoid serving content from non-standard port numbers, since that situation is another corner case that exposes unexpected semantics.

At this point, the cookie path is mostly a vestigial remnant of earlier days. It doesn’t serve much purpose any longer, as far as I can tell, and if the cookie-path had never been introduced, today you’d probably never notice. But browsers still need to support it, for backwards-compatibility reasons. And so it goes, on the web. It is best to think of the web not as a carefully designed artifact but as something that evolved over time — and as a result, has accumulated now-useless gunk, like our appendix.

Advertisements

Cookies

http://en.wikipedia.org/wiki/HTTP_cookie

Session cookie

A user’s session cookie[14] (also known as an in-memory cookie or transient cookie) for a website exists in temporary memory only while the user is reading and navigating the website. When an expiry date or validity interval is not set at cookie creation time, a session cookie is created. Web browsers normally delete session cookies when the user closes the browser.[15][16]

[edit]Persistent cookie

A persistent cookie[14] will outlast user sessions. If a persistent cookie has its Max-Age set to 1 year, then, within the year, the initial value set in that cookie would be sent back to the server every time the user visited the server. This could be used to record a vital piece of information such as how the user initially came to this website. For this reason persistent cookies are also called tracking cookies.

[edit]Secure cookie

A secure cookie has the secure attribute enabled and is only used via HTTPS, ensuring that the cookie is always encrypted when transmitting from client to server. This makes the cookie less likely to be exposed to cookie theft via eavesdropping.

[edit]HttpOnly cookie

The HttpOnly cookie is supported by most modern browsers.[17][18] On a supported browser, an HttpOnly session cookie will be used only when transmitting HTTP (or HTTPS) requests, thus restricting access from other, non-HTTP APIs (such as JavaScript). This restriction mitigates but does not eliminate the threat of session cookie theft via cross-site scripting (XSS).[19] This feature applies only to session-management cookies, and not other browser cookies.

 

Third-party cookie

First-party cookies are cookies set with the same domain (or its subdomain) as your browser’s address bar. Third-party cookies are cookies set with domains different from the one shown on the address bar. The web pages on the first domain may feature content from a third-party domain, e.g. a banner advert run by http://www.advexample.com. Privacy setting options in most modern browsers allow you to block third-party tracking cookies.

As an example, suppose a user visits http://www.example1.com, which includes an advert which sets a cookie with the domain ad.foxytracking.com. When the user later visits http://www.example2.com, another advert can set another cookie with the domain ad.foxytracking.com. Eventually, both of these cookies will be sent to the advertiser when loading their ads or visiting their website. The advertiser can then use these cookies to build up a browsing history of the user across all the websites this advertiser has footprints on.

[edit]Supercookie

A “supercookie” is a cookie with an origin of a Top-Level Domain (TLD) or an effective Top-Level Domain. Some domains that are considered, “Top-Level” may in fact be a secondary or lower-level domain. For example, .co.uk ork12.ca.us are considered Top-Level even though they are multiple levels deep. These domains are referred to as Public Suffixes and are not open for reservation by end-users.

Most browsers, by default, allow first-party cookies—a cookie with domain to be the same or sub-domain of the requesting host. For example, a user visiting http://www.example.com can have a cookie set with domain http://www.example.comor .example.com. A so-called “supercookie” is a cookie originating from a Public Suffix or Top-Level Domain such as, .com. It is important that these cookies are blocked by browsers otherwise, an attacker in control of malicious website with domain .com could set a “supercookie” and potentially disrupt or impersonate legitimate user requests to example.com. Thus taking advantage of the fact that .com can set valid cookies for sub-domain example.com.

The Public Suffix List is a cross-vendor initiative to provide an accurate list of domain name suffixes changing. Older versions of browsers may not have the most up-to-date list, and will therefore be vulnerable to supercookies from certain domains.

[edit]Supercookie (other uses)

The term “supercookie” is sometimes used for tracking technologies that do not rely on HTTP cookies. Two such “supercookie” mechanisms were found on Microsoft websites: cookie syncing that respawned MUID cookies, and ETagcookies.[20] Due to media attention, Microsoft later disabled this code:

In response to recent attention on “supercookies” in the media, we wanted to share more detail on the immediate action we took to address this issue, as well as affirm our commitment to the privacy of our customers. According to researchers, including Jonathan Mayer at Stanford University, “supercookies” are capable of re-creating users’ cookies or other identifiers after people deleted regular cookies. Mr. Mayer identified Microsoft as one among others that had this code, and when he brought his findings to our attention we promptly investigated. We determined that the cookie behavior he observed was occurring under certain circumstances as a result of older code that was used only on our own sites, and was already scheduled to be discontinued. We accelerated this process and quickly disabled this code. At no time did this functionality cause Microsoft cookie identifiers or data associated with those identifiers to be shared outside of Microsoft.
—Mike Hintze[21]

[edit]Zombie cookie

Main articles: Zombie cookie and Evercookie

Some cookies are automatically recreated after a user has deleted them; these are called zombie cookies. This is accomplished by a script storing the content of the cookie in some other locations, such as the local storage available to Flash content, HTML5 storages and other client side mechanisms, and then recreating the cookie from backup stores when the cookie’s absence is detected.