ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá














     áòèé÷ :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-alerts] Cross Site Cooking



> ------------------------------
> 
> 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, 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
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 
> End of Full-Disclosure Digest, Vol 11, Issue 66
> ***********************************************
> 



 




Copyright © Lexa Software, 1996-2009.