Slashdot Mirror
Web 2.0 Under Siege
Robert writes "Security researchers have found what they say is an entirely new kind of web-based
attack, and it only targets the Ajax applications so beloved of the 'Web 2.0' movement.
Fortify Software, which said it discovered the new class of vulnerability and has named it
'JavaScript hijacking', said that almost all the major Ajax toolkits have been found vulnerable. 'JavaScript
Hijacking allows an unauthorized attacker to read sensitive data from a vulnerable
application using a technique similar to the one commonly used to create mashups'"
How is this different from cross-site scripting?
"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."
ClutterMe.com - easiest site creation on the Net. Just click and type.
I think the very subtle difference is that this time the calls are made using site A's public Ajax API, using site A's authentication token, but are made from a script sitting on site B. The javascript calls return with data from site A, which can then be handled by site B. XSS/JS Injection is more about injecting alien javascript onto site A to make site A call site B with the info it wants.
Daniel
Carpe Diem
Upgrade to Web 3.0, quick!
Libertarian Leaning Political Discussion Forum.
Slashdot Burying Stories About Slashdot Media Owned
"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."
So essentially it means that the attacker can use the authentication cookie of the user to authenticate them again, and then run javascript with that authentication. But why are AJAX apps storing authentication in cookies? If you need to store authentication (User session id's etc), store them in a variable within the javascript. That'll stay there until a page refresh clears variable status, and how many page refreshes occur with AJAX?
AJAX apps do not need to (and should not!) store user authentication in cookies. Cookies are useful for keeping a continual session open between pages. AJAX needs no continual session. If they don't use cookies, then other sites cannot use that authentication.
Where's the problem? (What am i missing?)
PimTerry
The biggest WTF is that somebody is still using javascript. Oops. Wrong site...
(Captcha: backtotheweb1.0)
XML is now so last week. Really l33t web apps use JSON, which is yet another way to write S-expressions like those of LISP, but now in Javascript brackets.
There are several security problems with JSON. First, some web apps parse JSON notation by feeding it into JavaScript's "eval". Now that was dumb. Some JSON support code "filters" the incoming data before the EVAL, but the most popular implementation missed filtering something and left a hole. Second, there's an attack similar to the ones involving redefining XMLHttpRequest: redefining the Array constructor. (Caution, page contains proof of concept exploit.)
The real problem is JavaScript's excessive dynamism. Because you can redefine objects in one script and have that affect another script from a different source, the language is fundamentally vulnerable. It's not clear how to allow "mashups" and prevent this. The last attempt to fix this problem involved adding restrictions to XMLHttpRequest, but that only plugged some of the holes.
As a minimum, it's probably desirable to insist in the browser that, on secure pages, all Javascript and data must come from the main page of the domain. No "mashups" with secure pages.