Re: Cross Site Cooking
On Sun, 29 Jan 2006 01:50:23 +0100, Michal Zalewski <lcamtuf@xxxxxxxxxxxx>
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).
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.
Problem #2 - these cursed periods
---------------------------------
One can set a cookie for ".com.", then bounce the visitor to
http://www.victim.com./ . This address differs from the "real" one,
and thus, unlike with #1, planted cookies would work only for this
visit - but the trailing "." is not an alarming pattern for most
In Opera this domain would be handled as described above, with a DNS
lookup, and since ".com." will not resolve the cookie will only be
accepted for the server setting the cookie.
Solution
--------
Problem #1: There is no sane solution, other than altering HTTP cookie
format so that the server gets a chance to figure out who issued that
cookie in the first place. Workarounds by listing ccTLDs that use
.xxx.xx/.xx.xx subdomains in the browser are better than nothing
at all.
RFC 2965, which is supported by Opera, already specifies such an extension
to the cookie format. See http://www.ietf.org/rfc/rfc2965.txt for more
details.
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yngve@xxxxxxxxx
Opera Software ASA http://www.opera.com/
********************************************************************