On Wed, 2003-01-22 at 15:25, Marc Slemko wrote:
> 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.
Ok... the example you specify definitely achieves the same end this new
attack does. But it does so without using any of the bugs you assume in
your examples.
Comparing apples to oranges really.
Also, I dont recall ever seeing a browser bug where you could compromise
the HTTP Basic Auth creds without have access to a target server. Maybe
if we stretch it to URL trickery ok. But this was not done using purely
JavaScript as the paper clearly states.
> The reality is that there are many cases where the server returns
> information to the user that is confidential. TRACE is one of
> those.
Any other request methods that do that I am not aware of?
> 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 view 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.
I definitely see your point and its valid. There are indeed many ways to
get the web application to echo credentials which are not stored
security. Such as URL, etc. What we are attempting to relate is that for
your type of attack to work, you NEED a web application that is in some
way flawed.
What we propose is that you no long NEED a web application to be flawed,
simply a supporting TRACE web server and the creds are yours.
> 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?
because thats all you need... nothing more. and supported in all
browsers. NOT relying on a bug in this manner. Only need a bug to
increase the exposure.
> 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.
I also apologize if you took the media coverage to be a bit much. We
dont control the media however, surely Marc from experience you know
that.
Received on Jan 23 2003
Intro
