Michal Zalewski
30/01/06, 17:00
(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
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