263931 - Cross domain cookie set in Set-Cookie header if domain attribute is set

Status: RESOLVED WONTFIX

(Core :: Networking: Cookies, defect)

Description

[Ben Jones]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

When a Set-Cookie header is sent with a domain attribute, the resulting cookie
domain on the client is cross domain.

For example:

Set-Cookie: remembrance=9034da7c8a5a487d7a9dddc794eacf99; expires=Tue, 11-Oct-05
21:25:40 GMT; path=/; domain=goober.dorkwad.com

Results in a cookie on the client that can be read by *.goober.dorkwad.com (set
as '.goober.dorkwad.com')


Reproducible: Always
Steps to Reproduce:
1. Send a cookie header to client with a domain attribute


Actual Results:  
The resulting cookie on the client was set with a '.' preceding the specifiec
domain, making it readable to *.my.domain.com

Expected Results:  
My understanding is that the domain should not have been set with the preceding
'.', unless that is how the domain attribute was set in the Set-Cookie header.

Cookie setting on client are 'Accept All' but 'Ask'

Sorry to call 'security!' if it's out of line. However it seems to me that if I
set a cookie with 'my.domain.com', then I should be able to expect that it not
be read by 'malicious.my.domain.com'.

Comment 1

[Daniel Veditz [:dveditz]]

Not a security bug, known cookie behavior.

If you want a host cookie do not set domain=. The RFC says 

  Domain=domain
      Optional.  The Domain attribute specifies the domain for which the
      cookie is valid.  An explicitly specified domain must always start
      with a dot.

We tried enforcing that once or twice and broke big-name sites. It might be
their fault for violating the spec but the user blames *us* for having a broken
browser. The de facto spec is: with or without a dot, if you specify a domain
cookie then it *is* a domain cookie; if you want a host cookie leave off the
domain= part.

Comment 2

[benc]

V/wontfix.

Comment 3

[Daniel Veditz [:dveditz]]

It's been claimed that IE 6 enforces the spec, and if so then any broken sites must have been weeded out by now. If so we should do the right thing here.

Comment 4

[ziation]

Yes it is true that IE6 handles the cookie reading correctly when the domain is set.  The standard states, as was posted previously, whenever a domain attribute is used it should be preceeded by a dot (.)

The issue that seems to have been the original posters problem was FF used to attach a preceeding dot when one was not set to adhere to rfc standards.  This is a good thing in my opinion.  Even when a domain attrivute is set, FF should read main domains seperately from cnames of these main domains.

The problem I expereinced was doing development on a cname of one of my hosts.  Lets say my host name was foo.com.  On my perl/cgi application that handled user login, a cookie name USERID, PASS, UNAME, etc. were set with the domain attribute being "domain=.foo.com".

Now on my development cname, dev.foo.com, I was developing another site that handled user logins and just for the sake of ease, I named these cookies the same, USERID, PASS, UNAME, etc..  Now when reading cookies for dev.foo.com, FF would read in the cookies from foo.com which is a completely seperate site, system, application, etc..  This annoying at best and a possible security issue at worst.

Comment 5

[Daniel Veditz [:dveditz]]

What does this bug have to do with the EffectiveTLD stuff? This bug complains that we are violating rfc 2109 by supplying a leading dot if the domain value doesn't have one, but it's asking us to violate that same RFC by treating these as host cookies.

RFC 2109 section 4.3.2 explicitly says the UA should reject cookies if the domain does not start with a dot.

The cookie 2 spec (rfc 2965) blesses our current behavior:
   Domain=value
      OPTIONAL.  The value of the Domain attribute specifies the domain
      for which the cookie is valid.  If an explicitly specified value
      does not start with a dot, the user agent supplies a leading dot.

So I argue again that this should be WONTFIX. If we change we run the risk of breaking lots of sites. If we don't change sites that want this new behavior can get what they want by dropping the domain attribute and following the spec themselves.

Comment 6

[Darin Fisher]

-> reassign to default owner

Comment 7

[[e-mail]]

yup, wontfix.