> ------------------------------
>
> Message: 2
> Date: Sun, 29 Jan 2006 01:51:10 +0100 (CET)
> From: Michal Zalewski <lcamtuf@xxxxxxxxxxx>
> Subject: [Full-disclosure] Cross Site Cooking
> To: full-disclosure@xxxxxxxxxxxxxxxxx
> Message-ID: <Pine.LNX.4.58.0601290150560.27170@dione>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> (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, may set a cookie
> that will be
> sent to , but not to
> ;
> 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."
>
> [ ]
>
> 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
> . 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:
> - 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
> ; 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 . 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
> ---------
>
>
>
> Cheers,
> /mz
>
>
>
> ------------------------------
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter:
> Hosted and sponsored by Secunia -
>
> End of Full-Disclosure Digest, Vol 11, Issue 66
> ***********************************************
>
