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'.

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.

V/wontfix.

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.

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.

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.

-> reassign to default owner

yup, wontfix.