Hi. Markus gets it right. There is a vulnerability. This vulnerability has always been there. This vulnerability effects ajax calls among other things, so if you want to call it new on that basis then go ahead.
I've heard this called session riding. If I know bank of america's URL for a transfer funds service, I can code that into my page as the source of an invisible iframe. Should you visit my page WHILE logged in to your bank of america account, the browser will activate that page AS IF you had visited it directly. Switch iframe with ajax and you have this "new" attack. If you are doing ajax with XHRs this vulnerability does not apply to you (although if you have an XSS vulnerability it opens session riding back up again). It applies not just with JSON or other JS though, cookie and image based "ajax" are also vulnerable. Basically anything that allows for mashups also allows for session riding, hence the saying "web 2.0 treats security as damage and routes around it" Session based authentication verifies that you are logged into the application. What's called for is to verify that the action being asked for is part of a valid user-directed activity flow. This can be done (as Markus pointed out) by adding secret one time tokens to forms and links. Look at how Amazon handles this. LOTS of people are logged into their amazon accounts all the time. There are three levels of activities you could do with your amazon account. The first can be done with the always on login and so is easy to fake using session riding: - add to wish list - see your recommendations - use the gold box - order by one click - view your account page (a page of choices) The next level you have to log in using an online form and lets you do: - change your shipping address - change your one click settings - view your orders - have an order sent to anyone else than yourself It's easy to fall out of this second login state if you wait to long or play around with it in other ways. That's because amazon is keeping track of your user activity flow (is there a term for this?) to prevent session riding attacks. Then there are things you just can't do, like reading your own credit card number. Since people right now are often doing ajax for the first time, I think there are common sense precautions like this that are getting missed. Startups are also notorious for sacrificing security in favor of growth (in fact it's sometimes explicit in their business plan). So ajax is likely to get a bad security rep for a while. ----->Nathan .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:. Nathan Young Cisco.com->Interface Development A: ncy1717 E: [EMAIL PROTECTED] > -----Original Message----- > From: jquery-en@googlegroups.com > [mailto:[EMAIL PROTECTED] On Behalf Of Markus Peter > Sent: Tuesday, April 03, 2007 3:56 AM > To: jquery-en@googlegroups.com > Subject: [jQuery] Re: Web 2.0 is vulnerable to attack > > > 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 - [EMAIL PROTECTED] > 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 >
