<<< Date Index >>>     <<< Thread Index >>>

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/
********************************************************************