Message-ID: <Pine.LNX.4.58.0601290016400.27170@dione>
Date: Sun, 29 Jan 2006 01:50:23 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ne.ids.pl>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...sys.com, webappsec@...urityfocus.com
Subject: Cross Site Cooking



(Why, yes, I came up with the name, and had to find some bugs to be able
to post this.)

Summary
-------

  There are three fairly interesting flaws in how HTTP cookies were
  designed and later implemented in various browsers; these shortcomings
  make it possible (and alarmingly easy) for malicious sites to plant
  spoofed cookies that will be relayed by unsuspecting visitors to
  legitimate, third-party servers.

Impact
------

  Many commercial websites may be attacked to overwrite or delete
  stored preferences, session identifiers, authentication data,
  cart contents - with results ranging from minor annoyances to
  a possibility of fraudulent activity, depending on site design
  (bugs #1 and #2).

  On sites where authentication data is tied on a server to a session ID,
  the attacker may be able to acquire credentials by tricking the
  visitor to authenticate within a session initiated by the attacker
  (bugs #1 and #2)

  Some websites may be susceptible to malicious-activity-by-proxy
  attacks (bug #3).

  There is no immediate universal threat to life as we know it, but
  numerous web scripts are an easy target of specific variants of the
  attacks described below.

Discussion
----------

  Let's begin with a quick primer on cookie parsing: when a new cookie is
  issued to the browser (via "Set-Cookie" header in a HTTP response), the
  server is expected to specify the domain and URI for which the cookie is
  meaningful. This mechanism is present so that pages could limit the
  scope of their cookies if needed, and prevent the data from being sent
  to unrelated addresses in the same domain. For security purposes, the
  browser will (theoretically) reject a cookie that is set for a domain
  that is either defined too broadly, or does not match issuer's location
  at all.

  (In other words, http://www.example.com/ may set a cookie that will be
  sent to http://mail.example.com/, but not to http://forums.example.com/;
  it cannot configure a cookie to be sent to all .com servers, nor to an
  unrelated server, example.co.uk, however.)

    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.

    Problem #2 - these cursed periods
    ---------------------------------

    Another twist on the story is that there is no checking if there's
    anything between periods in domain name - and extra trailing periods
    are accepted by most resolvers as a way to override local domain
    search path.

    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
    users. In fact, seasoned users recognize it and sometimes purposefully
    append it - and as such, they won't be tempted to be suspicious, and
    may interact with the website (perhaps even authenticate within
    the session ID supplied by and known to the attacker).

    A surprise of sorts... I'm not the first person to spot this:
    http://www.nihongo.org/snowhare/utilities/triple_dot/ - credit
    goes to Benjamin Franz... vendors were notified in 1998, and certainly
    are not in a hurry to fix this.

  Ok, let's go back to cookie handling for a while...

  All the verification of domain path is limited to client-side; when
  the server receives a cookie ("Cookie" header in a HTTP request), there
  is no information about the original issuer. It is assumed that the
  browser behaves rationally, and is sending the cookie to a site or a set
  of sites that previously issued it. The only other option is that the
  user willingly tampered with the request, and is OK with any eventual
  consequences of his actions.

  This is a mistake.

    Problem #3 - it's the address that counts
    -----------------------------------------

    The attacker may easily force random visitors to accept and relay
    arbitrary cookies to a third-party site by a) setting up
    http://example.com; b) issuing all visitors a cookie that mimicks
    victim's cookies, but is valid for *.example.com; c) setting IN A
    record for evil.example.com to the IP address of its victim; d)
    redirecting users to http://evil.example.com. This will cause
    visitor's browser to send attacker's cookie to victim's server exactly
    as if it were a cookie originally issued by the victim himself.

    This trick alone does not compromise, disclose, erase, or supersede
    user's settings should he later access the site through its proper
    address; and since a bogus address is displayed in URL bar, the
    user is not tempted to interact with the website. (There are some
    brain-damaged examples of sessionID-in-URL redirects, but these
    have a fair share of other problems.)

    I do believe there is some risk, however: using this trick, a brand
    new identity may be temporarily bestowed upon the user, and used to
    perform certain undesirable or malicious tasks on the target site
    before he has a chance to object (hiding attacker's identity or
    bypassing IP-based limits). DDoS or session ID brute-forcing uses are
    also tempting.

    That said, this alone is not a major problem for a well-designed
    website and a savvy user; alas, websites should be designed with the
    knowledge of this possibility; and furhter research on specific
    applications of this technique to existing backends might be quite
    valuable.

  Well... that's the story...

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.

  Problem #2: Browsers should strip "idle" periods in cookie
  domain data. Browser vendors should take less than 8 years to address
  security problems.

  Problem #3: The immediate fix to this problem is requiring and carefully
  validating HTTP/1.1 "Host" header on all requests (this ensures that the
  browser's idea of who he's talking to matches the site's canonical
  name).

Lame plug
---------

  http://lcamtuf.coredump.cx/silence/

Cheers,
/mz


-------------------------------------------------------------------------
This List Sponsored by: Watchfire

Watchfire's AppScan is the industry's first and leading web application 
security testing suite, and the only solution to provide comprehensive 
remediation tasks at every level of the application. See for yourself. 
Download AppScan 6.0 today.

https://www.watchfire.com/securearea/appscansix.aspx?id=701300000003Ssh
--------------------------------------------------------------------------

Powered by blists - more mailing lists