On 03.04.2007, at 08:07, Karl Rudd wrote:
> Bah, it's not a new vulnerability, it's always been there and always
> been known about.
> I call FUD on this.
> The following is an excerpt that is the keystone of the whole thing:
> "In an example attack, a victim who has already authenticated
> themselves to an Ajax application, and has the login cookie in their
> browser, is persuaded to visit the attacker's web site. This web site
> contains JavaScript code that makes calls to the Ajax app. Data
> received from the app is sent to the attacker."
> Firstly _don't visit suspect sites_.
> Secondly their "example attack" is flawed. As far as I'm aware
> JavaScript code on one page does not have access to the cookies of
> other webpages. If it does it's a security flaw in the browser,
> nothing a JavaScript library can do about it.
I would not call this only FUD - the newspaper article is bad and
FUD, especially the conclusion that the libraries are "vulnerable"
where in reality the developers using them were probably clueless,
but the original paper it refers to has a point. It maybe helps if
you read the original paper at
http://www.fortifysoftware.com/servlet/ downloads/public/JavaScript_Hijacking.pdf
You're right in so far as it's an old hat - nevertheless most people
don't think of these kind of attacks even though Google already fell
prey to it several times.
Unfortunately, many people seem to misunderstand the way, the attack
works:
Cookies are not accessed by "other webpages" by this attack. Instead,
the attack relies on the fact, that browsers will always
automatically send cookies to the original domain. It's just plain
old cookie-based XSS applied to JSON data.
What happens is, that if you e.g. have a JSON-outputting URL on your
page like /api/ultrasecretdata which is secured by cookies and
another page simply does
<script src="http://yourdomain/api/ultrasecretdata"></script>
then the browser will load the page and execute it as JavaScript. As
the request goes to your server, your cookie will rightfully be sent
with it and the request is authenticated, so the server will output
the data.
Now, it's of course "only data" but what most people forget is, that
JSON data is executable JavaScript Code: Arrays and Objects are
constructed, and therefore, their constructors are called. If you
override the constructor before the script tag, you'll receive the
data in your own code.
Of course, you could still say, that browsers should not allow
scripts of different pages interact that way - but they do work that
way at the moment and it will likely never be changed as too many
things nowadays rely on the fact that scripts from different servers
can interact with each-other if they're loaded on the same page - so
you _have_ to fix it in your application.
There are basically two ways to fix it:
1. Include a secret into the URL. Our own application for example
always includes the Session ID of an authenticated user as a request
parameter to the API calls, because then the URL is not guessable
anymore and it's not possible to include the data on other pages
2. Include some breaker code in the output of your APIs before the
actual data like e.g. /* */ comments and then remove that data before
evaling your JSON code.
The second fix is rather easily applied to legacy code, but it's
plain UGLY and it somehow destroys the reason for using a standard
format like JSON.
What these guys obviously mean, when they say that frameworks are
"vulnerable" is, that no frameworks support the developer with that
task (solution 2) by offering automatic support to throw away the
execution breakers. I'm actually glad about that - JSON should stay
JSON and data exchange formats should stay standardized - otherwise
we're thrown back straight into the 90ies with proprietary APIs.
Now, solution 1 is easily done with jQuery and probably all the other
libraries mentioned - simply include your secret, most probably the
session id, as a parameter with every request to APIs which should be
secured. My suggestion would be to actually extend the jQuery AJAX
documentation (or include a link to some tutorial in the Wiki or so)
to point out the issue, if you use JSON only secured by cookies.
That's the most sensible change to do - I do not think this issue
justifies any changes to the jQuery code itself as it's only an issue
of most application developers not thinking about a certain type of
attack.
--
Markus Peter - w...@spin.de http://www.spin-ag.de/
SPiN AG, Bischof-von-Henle-Str. 2b, 93051 Regensburg, HRB 6295
Regensburg
Aufsichtsratsvors.: Dr. Christian Kirnberger
Vorstände: Fabian Rott, Paul Schmid
