On Wed, 22 Jan 2003, Jeremiah Grossman wrote:

> > 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.
> >
> ok, maybe the white paper wasnt clear enough. The essential pieces that
> are require for full exploitation as I define is... script on a page,
> domain-restriction-bypass flaw (not essential), and a trace supporting
> target.
>
> We are not assuming or requiring the browser to be flawed any more than
> that. Again, I see your point... if you can grab a file off their
> machine... what would be the point of all this. To state once more...
> this is not required.

If you already have a cross domain restriction bypass bug in the
browser (which is a major bug and any vendor who doesn't immediately
fix such bugs when they are discovered should be ashamed of
themself... just like any vendor that has their corporate email
system bouncing back posts to bugtraq saying the list doesn't exist
on their system) you can perform whatever actions you want on behalf
of the user using their browser, and can grab the results. The
holy grail is not the credentials, it is the application itself and
whatever operations it allows and data it contains.

You don't need the credentials if you can control the application
through the user's b rowser. Sure, grabbing the credentials makes
things a little easier. But not all that much, since they are
often only good for the session anyway.

If you do not have a cross domain restriction bypass , then this
"flaw" doesn't add anything. Nonsense about having some other way
to create content on the server is irrelelvant; if you can do that,
then see the previous paragraph.

To summarize what is new and either notable or laughable in this paper:

1. a more widespread way than previously known to grab HTTP basic
auth credentials. This is new and quite interesting, yes. There
were some ways a few years back to do this with certain browsers,
but it was not widespread and has long been fixed. You will find,
however, that few sensitive apps use HTTP basic auth for a multitude
of reasons. Being able to steal this information can be very
valuable for an attack against sites that do use it though, since
HTTP basic auth credentials normally are not session based and
remain valid for long periods of time... which is one of the
multitude of reasons it isn't normally used for sensitive apps.
Even worse, some systems use a system login and password in this
which can be exploited to gain further access to a system, even if
the access to the web application is inconsequential.

Many people, including myself, have always suggested that HTTP
basic authentication is not a very secure mechanism even when used
over SSL. It is often the easiest one though.

2. the ability to bypass the non-standard "httponly" cookie hack
that exists in a few versions of one particular web browser. This
is somewhat interesting, but has few practical implications since
this hack is not in widespread use and even with this hack in place,
it does nothing to prevent an attacker from simply controlling the
user's browser to do what they want or get the information they
want even without getting the credentials.

The whole problem with the httponly hack in IE is that it doesn't
really change anything in the bigger picture. It prevents cookies
only from being read directly by javascript in particular browsers
if the flag is explicitly set. I am as guilty as the next person
in using demonstration exploits that show stealing the cookie using
javascript as "what cross site scripting does", but realize that
is just a convenient easy to understand example of one type of web
application security. You don't need the credentials, protecting
them is a handy thing but nothing more than that.

3. a bunch of hype that comes from claiming that this, combined with
previously known cross domain restriction bugs, results in a very
serious flaw. It is actually true that it does result in a very
serious flaw, but the flaw was already there without any of this new
information by the very nature of the cross domain restriction hole.

4. The most amusing press release I have read in a while. It is
a "pandemic" and a "SERIOUS SECURITY FLAW AFFECTING ALL WEB SERVERS
WORLDWIDE" that is present in "a vast majority of commercial web
sites". And this is something that White Hat Security has to accept full
responsibility for, it is their press release.

As for what "the fix" is...

Note that I do think that the XMLHTTP control should probably know
about the httponly hack if the httponly hack is something Micorosft
wants to support. The httponly hack is documented as marking
cookies as "scriptless". The HTTP spec defines the TRACE method
as returning a message body of a content type message/http that
contains the headers from the original request.

The httponly hack says the cookie shouldn't be accessible from
script. Therefore, IE better ensure it isn't accessible using the
TRACE method. I'm not sure that I would call this a bug in the
XMLHTTP control, but more a missing feature (ie. lack of explicit
TRACE support) and a bug in how the httponly hack was thought
through since it requires the cooperation of every component that
can plug into the browser that provides access to data.

Contrast this with being able to exploit something similar using
a printenv CGI script. In that case, it isn't reasonable for the
browser to prevent access to the returned cookie from scripts because
there is nothing in the HTTP spec telling it that the response
contains the cookie. It isn't a bug in the printenv script that it
returns the cookie (although certainly you may well wish to choose not
to have such scripts available on your production servers for a variety
of reasons), it isn't reasonable for the browser to filter it out
(although it could; it could filter out anything matching the cookie
value that is present in the response... lets hope you never make
a httponly cookie with a value of "http" or any such)... it is just
a limitation in the basic concept of the httponly hack and an example
of why I think it is half-assed.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]