Quote:
Originally Posted by mcevoys  Web 2.0 is vulnerable to attack
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," Chess writes in a white paper published today.
And Fortify now claims that attackers can exploit this loophole to log into Ajax applications pretending to be their victims, and then receive any data that this application would ordinarily serve up using JSON.
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. Any ideas if there are security implications for ZCS? |
Fortify has a long history of doing everything they can to scare the bejezus out of people so that they can get new big huge customers. I've dealt with them before, and each time got a taste left in my mouth much like the taste I got when dealing with Arthur Anderson before they went under.
This attack is basically your standard cross site request forging, plus a little tweaking of the javascript to make things better.
The problem here isn't with the Ajax community, so much as it is with the vendors, and the JavaScript spec. While Firefox and IE properly block client scripts from accessing data directly if they are from different sites, it's still possible to override the JavaScript Object definition (JavaScript is prototyped base rather then class based, which means that you can dynamically add methods to classes in Javascript) to bypass this restriction. However, the <script> tag still have to be used from inside of the secure context to begin with, and bogus JSON has to be passed from the script to be able to access the secure information.
Is Zimbra exposed? I am not sure, but at least one of the security mechanisms mentioned in the paper (application specific authentication cookies) is already used in Zimbra for authentication. (This is why it's possible to have two separate windows up in Zimbra on the same browser logged in as two separate users).
The Zimlet mechanism certainly allows for some interesting (and probably dangerous security wise) extensions directly into the Zimbra source code, but most of the Zimbra code does XHR directly rather then script (from my own trivial viewing of the code).
Bugzilla
Wiki
Source
Ajax vulnerability: How 'bout ZCS? 
Linear Mode
