Re: Cross Site Cooking
Yngve Nysaeter Pettersen wrote:
> > Problem #1 - trouble with these pesky foreigners
> > ------------------------------------------------
> >
> > The mechanism for preventing overly relaxed cookie domain
> > specification seems to be broken in all major browsers. Some ancient
> > documents invoke the following flawed but reasonable rule:
> >
> > "Two dots are required if the top level domain is: .COM, .EDU, .NET,
> > .ORG, .GOV, .MIL, or .INT. Three dots are required for any other
> > domain. This is to prevent the subdomain from being set to something
> > like .COM, the subdomain of all commercial machines."
> >
> > [ http://www.ciac.org/ciac/bulletins/i-034.shtml ]
> >
> > This is repeated ad nauseam in various cookie tutorials and FAQs,
> > but my initial tests indicate that the rule is quite simply not true.
> > Both MSIE and Firefox seem to be perfectly happy with two-period
> > ccTLDs domain cookies (.xxx.xx).
> >
> > In other words, one can set a cookie for *.com.pl or *.com.fr, and
> > override or corrupt credentials or other parameters on hundreds of
> > thousands e-commerce websites in that country. It will be also
> > possible to plant attacker's session ID on visitor's computer,
> > and effectively, steal his credentials when he decides to sign in
> > on the target site.
>
> When this problem was (to my knowlegde) first published in December 1998,
> this was called the "Cookie Monster Bug". See
> http://help.netscape.com/kb/consumer/19981231-1.html (the original
> advisory page is gone).
>
> The problem about the two internal dot rule for ccTLDs is that many ccTLDs
> are using a flat structure similar to the generic .com TLD, not a
> hierarchical structure like the one used by the .UK domain. To make
> matters worse, many ccTLDs are actually using a combination of the two
> structures.
>
> As far as I know there is no reliable algorithmic way to determine if a
> domain name is a valid domain (like company.tld) or a subTLD (like co.uk).
This is a meaningless distinction. No matter how many components a
domain has, subdomains can still be delegated to distinct entities.
For a university, should the student union website be sent cookies set
by the registrar's site?
If an ISP gives each customer a subdomain, should customers be sent
each other's cookies? Does it matter how many components the ISP's
domain has?
[The correct answer to all of the above is "no".]
The whole concept of trying to infer boundaries from the domain is
broken by design. At least with the ancestor/descendent case, the
administrators of the parent domain could alway redirect the entire
domain to their own server, so you aren't really losing anything by
allowing cookies to travel up or down the tree. But any mechanism
which allows cookies to be transferred to "sibling" domains is
fundamentally flawed.
> One method could be a blacklist for common subTLDs like co.tld, com.tld,
> ac.tld, etc., but it is dificult to make such a list complete, and some
> ccTLDs also have multilevel subTLDs and also uses geographic names in such
> second level domains, e.g. city.state.us, and many countries have national
> names for their subTLDs. Last time I checked http://www.govcom.org/
> indicated that at least half of the ccTLDs had some form or hierarchical
> structure, but an unknown percentage of these are using a hybrid structure.
>
> Opera's current approach (which is not perfect) is to use a DNS lookup for
> non-generic (only those in Netscape's original list are considered generic
> in this context) that are either second level domains or two levels up
> from the server setting the cookie. If there is an IP address defined for
> the domain name, the cookie is accepted for the domain, otherwise it is
> only accepted for the server
> setting the cookie.
>
> We are investigating ways to improve on this method, but as far as I can
> tell, any improvement will require a coordinated effort by all the gTLD
> and ccTLD registries.
Any improvement will require that browsers only pass cookies to
domains which are explicitly permitted by the setter, and pass the
setter domain to all recipients alongside the cookie. IOW, a protocol
change. Anything else is papering over the cracks.
--
Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx>