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.
Karl Rudd
On 4/3/07, Kush Murod <kmu...@sensorynetworks.com> wrote:
> Article below says all big JS Libraries are vulnerable including JQuery > I didn't quite understand the article, but was hoping for some feedback > on it
AJAX, as Kevin Murphy said ... "Since Ajax is in its infancy, this is fair less of a problem than, say, buffer overflows were when they first came to light, Chess noted. There are not a lot of legacy Ajax applications that will need to be fixed. So, Fortify wants to publicize its finding as loudly as possible now to nip the problem in the bud."... is still a very young way to do things... there will be alot of things to discover (good and bad), and its "cool" that this things be found in such and early stage, so that they can be corrected.
The team beyind jQuery and other libs are already working on that :) im sure.
On Apr 3, 6:55 am, Kush Murod <kmu...@sensorynetworks.com> wrote:
> Article below says all big JS Libraries are vulnerable including JQuery > I didn't quite understand the article, but was hoping for some feedback > on it
Or is it the old problem with domain wide cookies? I give a cookie for x.com on jake.x.com and you read my cookie on karl.x.com? You still can't ajax to jake.x.com.
> 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.
> Karl Rudd
> On 4/3/07, Kush Murod <kmu...@sensorynetworks.com> wrote:
> > Hi guys,
> > Article below says all big JS Libraries are vulnerable including JQuery > > I didn't quite understand the article, but was hoping for some feedback > > on it
> Or is it the old problem with domain wide cookies? I give a cookie for > x.com on jake.x.com and you read my cookie on karl.x.com? You still > can't ajax to jake.x.com.
> It sounds like disinformation to me!
> On 4/2/07, Karl Rudd <karl.r...@gmail.com> 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.
> > Karl Rudd
> > On 4/3/07, Kush Murod <kmu...@sensorynetworks.com> wrote:
> > > Hi guys,
> > > Article below says all big JS Libraries are vulnerable including JQuery > > > I didn't quite understand the article, but was hoping for some feedback > > > on it
Agreed. This comes up every few months. In this case, it looks like they're talking about JSON data being readable from any host. I guess they mean if you're getting data via the remote script tag and callback technique, other sites could do the same thing and access your data? Seems like a pretty poor way for a legitimate site to work.
IMHO, the fact that forms can be submitted via javascript (no ajax involved) is a much bigger issue, but if you design correctly, it isn't a problem.
> 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.
> Karl Rudd
> On 4/3/07, Kush Murod <kmu...@sensorynetworks.com> wrote:
> > Hi guys,
> > Article below says all big JS Libraries are vulnerable including JQuery > > I didn't quite understand the article, but was hoping for some feedback > > on it
> Agreed. This comes up every few months. In this case, it looks like > they're talking about JSON data being readable from any host. I guess > they mean if you're getting data via the remote script tag and > callback technique, other sites could do the same thing and access > your data? Seems like a pretty poor way for a legitimate site to work.
> IMHO, the fact that forms can be submitted via javascript (no ajax > involved) is a much bigger issue, but if you design correctly, it > isn't a problem.
> Regardless, this thread will likely get huge :)
> --Erik
> On 4/2/07, Karl Rudd <karl.r...@gmail.com> 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.
> > Karl Rudd
> > On 4/3/07, Kush Murod <kmu...@sensorynetworks.com> wrote:
> > > Hi guys,
> > > Article below says all big JS Libraries are vulnerable including JQuery > > > I didn't quite understand the article, but was hoping for some feedback > > > on it
I don't doubt that someone put alot of time into this particular FUD piece, but once again (just like all the other articles on this subject), no proof is given. If it's so easy, have it read an arbitrary email from my GMail and THEN I will take the arguments seriously.
In the mean time, I laugh at all the "the sky is falling" cries.
On 4/3/07, Kush Murod <kmu...@sensorynetworks.com> wrote:
> Article below says all big JS Libraries are vulnerable including JQuery > I didn't quite understand the article, but was hoping for some feedback > on it
> 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
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
