26

I simply cannot believe this is quite so hard to determine.

Even having read the RFCs, it's not clear to me if a server at subdomain.example.com can set a cookie that can be read by example.com.

subdomain.example.com can set a cookie whose Domain attribute is .example.com. RFC 2965 seems to explicitly state that such a cookie will not be sent to example.com, but then equally says that if you set Domain=example.com, a dot is prepended, as if you said .example.com. Taken together, this seems to say that if example.com returns sets a cookie with Domain=example.com, it doesn't get that cookie back! That can't be right.

Can anyone clarify what the rules really are?

Evan Plaice
  • 480
  • 1
  • 5
  • 12
  • This question should have been closed/migrated back when it was asked, but since it gained a lot of attention I'm going to lock it instead of closing. See http://stackoverflow.com/questions/3089199/can-subdomain-example-com-set-a-cookie-that-can-be-read-by-example-com for the dupe, on the correct site. – Chris S Nov 10 '14 at 14:46

3 Answers3

30

Quoting from the same RFC2109 you read:

       * A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
         be accepted.

So subdomain.example.com can set a cookie for .example.com. So far so good.

       The following rules apply to choosing applicable cookie-values from
       among all the cookies the user agent has.

       Domain Selection
            The origin server's fully-qualified host name must domain-match
            the Domain attribute of the cookie

So do we have a domain-match?

   * A is a FQDN string and has the form NB, where N is a non-empty name
     string, B has the form .B', and B' is a FQDN string.  (So, x.y.com
     domain-matches .y.com but not y.com.)

But now example.com wouldn't domain-match .example.com according to the definition. But www.example.com (or any other "non-empty name" in the domain) would. This RFC is in theory obsoleted by RFC2965, which dictated things about forcing a leading dot for domains on Set-Cookie2 operations.

More important, as noted by @Tony, is the real world. For a glimpse into what actual user agents are doing, see

Firefox 3's nsCookieService.cpp

and

Chrome's cookie_monster.cc

For perspective into what actual sites are doing, try playing with wget using --save-cookies, --load-cookies, and --debug to see what's going on.

You'll likely find that in fact most sites are using some combination of Set-Cookie from the older RFC spec with "Host" values, implicitly without a leading dot (as twitter.com does) or setting Domain values (with a leading dot) and redirecting to a server like www.example.com (as google.com does).

IMSoP
  • 480
  • 2
  • 10
medina
  • 1,970
  • 10
  • 7
  • so how do www.example.com and example.com (which commonly point to the same site) use the same cookies? The leading . cannot be required in most browsers otherwise this common usage would not work. – JamesRyan Jun 22 '10 at 09:47
  • Leading dot is only forced by the more recent RFC. example.com can set cookies for "example.com" and ".example.com"; the latter can be read by www.example.com. Use the wget commands shown to see what's happening. – medina Jun 22 '10 at 12:00
  • @medina, Can a user set cookies at **x1.y.z** and read it at **x2.y.z**? – Pacerier Mar 05 '13 at 20:00
  • @Pacerier Only if (1) you set the cookie for `y.z` and (2) the user-agent implements RFC 6265. – Michael Hampton Apr 09 '13 at 21:17
  • @MichaelHampton, don't browsers implement RFC 6265? – Pacerier Apr 10 '13 at 09:04
  • @Pacerier You'll have to ask them, or check their source code. – Michael Hampton Apr 10 '13 at 15:01
2

If the browser implements RFC 6265, which any modern browser should be doing at this point, then a cookie set for .example.com will have the leading dot ignored (section 5.2.3), and the cookie will then be sent to the naked domain and to all subdomains.

Don't rely on this behavior if you have significant traffic from older browsers; this RFC only dates to 2011.

Community
  • 1
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
1

It should not be possible. However, as you said, since this isn't a widely documented standard, it depends on what piece of software you're using.

Most modern browsers adhere to a defined "web security model". The model effectively governs the behavior of browsers with regards to security, on things like cookies (specifically how they will be sent back to any given website). The model also has the rule that "browsers don't send cookies to domain names that didn't set them."

That being said, domain.com should be able to set cookies for js.domain.com. js.domain.com, however, can only set cookies for itself. But this is all depending on what browser you're using.

Tony
  • 482
  • 3
  • 3