New Web Vulnerability - Cross-Site Tracing

[Pete Soderling]

I thought this news might interest the group ...

ExtremeTech (http://extremetech.com) just released an article on a new type of vulnerability recently reported to CERT, Cross-Site Tracing (XST).

"After months of extensive research, San Jose California-based WhiteHat Security has unmasked a flaw in one of the Web's cornerstone protocols which places all e-commerce sites, as well as scores of Internet users, in jeopardy.

This threat was discovered by application security research firm WhiteHat, and is detailed in David's story below. White Hat Security was started by a former CTO from Ungermann-Bass, and an Information Security officer at Yahoo!."

Read the entire post at: http://www.extremetech.com/article2/0,3973,841047,00.asp

--petesoder

[Marc Slemko]

On Wed, 22 Jan 2003, Pete Soderling wrote:

> I thought this news might interest the group ...
>
> ExtremeTech (http://extremetech.com) just released an article on a new type of vulnerability recently reported to CERT, Cross-Site Tracing (XST).
>
> "After months of extensive research, San Jose California-based WhiteHat Security has unmasked a flaw in one of the Web's cornerstone protocols which places all e-commerce sites, as well as scores of Internet users, in jeopardy.
>
> This threat was discovered by application security research firm WhiteHat, and is detailed in David's story below. White Hat Security was started by a former CTO from Ungermann-Bass, and an Information Security officer at Yahoo!."
>
> Read the entire post at: http://www.extremetech.com/article2/0,3973,841047,00.asp

Wow, what a misinformed article. The whitepaper available on
WhiteHat's site is better (http://www.whitehatsec.com/news.html)
but it still requires very careful reading to appreciate what parts
of it are talking about things that are due to other known holes
and which are actually news.

Essentially what it boils down to is that Microsoft's "httponly" cookie
hack is half-assed, and doesn't really work very well in reality, and
that because MS has a horribly record of cross domain security
holes that they refuse to patch in a timely manner then somehow
this hole is a new all pervasive attack.

Trying to pass all this off as some flaw in TRACE is... obscene.
Combining existing holes that already have a huge exposure, then
adding in a few little new pieces appears to be a strategy designed
to hype the importance of the issue.

The only new thing here is that this provides a way to get HTTP
basic authentication credentials and, while this is indeed a notable
discovery, it is unfortuante that is presented in the overhyped
way it is. It has been possible to obtain basic auth credentials
in the past both from browsers that improperly allowed newline
characters to be embedded in fields in the request (allowing the
authorization to end up in the request body) and browsers that
could be tricked into thinking they are sending a request to site
x while really sending to site y, but AFAIK those holes are all
fixed in any recent versions of common browsers.

The reality is that there are many cases where the server returns
information to the user that is confidential. TRACE is one of
those. Embedding session IDs in returned links is one (very commonly
done on app servers that support cookie based session tracking with
a fallback to url based). Returning a user's bank account number
when they their account is another. I don't see trying to disable
every way that the server can send sensitive data to the browser as
being a very effective path to try to take to solve such issues.

The bottom line: Why do you even need to steal the user's
authentication token if you have full access to get their browser
to submit requests and the ability to grab the contents of the
results? And having access to those two things is exactly what
this whitepaper is assuming. Yes, there is a small incremental
exposure to being able to take the authentication token away with
you and use it yourself but that is marginal compared to the exposure
from the holes being assumed to be there before the new TRACE issue
can be exploited.

[Andrew Clover]

Pete Soderling <pete@petesoder.com> quoted WhiteHat Security:

> "After months of extensive research, San Jose California-based WhiteHat
> Security has unmasked a flaw in one of the Web's cornerstone protocols

No. The fault seems to me not to be anything to do with TRACE, but just
(another) bug in Microsoft's XMLHTTP component.

XMLHTTP should *not* add cookie and authentication headers to outgoing
requests. It is only appropriate to send these headers when it is known
the response will be handled by the user agent itself, and hence only
available to scripting code through the usual browser security same-
origin policy.

TRACE is IMHO a silly feature, but it's unrelated to the real problem.
After all, a simple GET request sent by XMLHTTP could ask for a page from
a user's online bank and read the balance off the reply.

TRACE would be a danger if there were a legitimate way to persuade a browser
to make a TRACE request and display the results as text/html, but as far as
I know there isn't. Certainly <form method="TRACE"> doesn't do it.

'httpOnly' really doesn't have anything to do with this issue either.

> which places all e-commerce sites, as well as scores of Internet users,
> in jeopardy.

Not any more than they already are. This is a browser bug in IE, and there
are already many cross-site scripting bugs in that browser.

I hope this was properly reported to MS... it's an IE hole, *not* a
general-purpose the-web-is-falling design flaw.

--
Andrew Clover
mailto:and@doxdesk.com
http://www.doxdesk.com/