Ajax Exploit Threatens Web 2.0 Security
by
on April 06, 2007,
In the comments section of my review of Clipperz, CEO of Clipperz Marco Barulli disagreed with my concerns about using third-party libraries for Clipperz, as well as an open-source JavaScript cryptographic library. Fortify Software would seem to agree with me, releasing an advisory this week on a known vulnerability in Web 2.0 sites that rely on Ajax.
Fortify examined 12 popular Ajax frameworks, including the biggies - Google, Microsoft, and Yahoo! - as well as open-source releases. Their verdict? Only Direct Web Remoting (DWR) 2.0 had the goods to prevent JavaScript Hijacking. The others not only don't seem to have protection in place, but also don't mention even the threat of vulnerability in their documentation. As Fortify's press release states, "Even if an application does not use any of the frameworks listed above, it may be vulnerable if it contains AJAX components that use JavaScript as a data transfer format for sensitive data."
When I look at online apps, I do so with a coder's mindset. And while I'm a big proponent of open source programming, I also know that the more third-party components you include, the more possibility of holes in the software.
The exploit takes advantage of any system using JavaScript as a transport for information. By insinuating itself as an emulated user, JavaScript HIjacking can obtain sensitive information, then allowing the attacker to access the Web 2.0 app. The amout of damage that can be done is related to how much the application does.
There are some who will say that the Fortify advisory doesn't really address anything new, and Fortify's FAQ addresses those comments. This week we've also seen a Windows exploit that not only affects the Internet Explorer browser, but also Firefox. Ajax has made many Web 2.0 apps user-friendly and, let's face it, cool. However, it can't hurt to take a second, third, or even fourth look at security, especially when it comes to protecting users' sensitive data.
If you enjoyed this post, make sure you subscribe to profy RSS feed!
Bighorn
kalipso
Mav
Opensource 
Michael Fidler 
Since this article stems from a comparison between clipperz and PassPack, and I’m a PassPack founder, well… I’d like to put my two cents in.
Both systems (clipperz and PassPack) use industry standard encryption. These algorithms are public, and it’s widely accepted that public algorithms, which have undergone extensive testing by the cryptographic community at large, are by far more secure than any homegrown algorithm. It is actually considered irresponsible to use homegrown cryptography for anything other than playful experiments.
In the advisory you quoted, they state:
“The rest of the [ajax] frameworks do not explicitly provide any protection and do not mention any security concerns in their documentations.”
Absolutely, positively true. The various Ajax frameworks provide no level of *inherent* security. However, it is up to the developers (PassPack’s or otherwise) to examine and learn the code inside and out. That goes for any updates as well - any evolution in the framework code must undergo the same internal security testing all over again.
The entire system must be built to stave off attacks like DoS, XSS, Code Injection and friends. And the security mechanisms that need to be put in place in order to ward off these attacks need to be designed into the system regardless of what framework (or no framework) is used to handle the Ajax bells and whistles.
Whether or not you use Ajax, you’re system needs to be well designed, with security in mind form the get-go.
PassPack uses JQuery 1.1.2 which has been throughly tested internally. We also use public implementations of public algorithms, and worked for a long time with the authors to make sure that we profoundly understood every single comma, dash and dot in their implementation before actually employing the code. Many implementations didn’t make the grade for us, luckily, some did and we were able to build PassPack with the supporting code of industry experts.
You can see what code PassPack uses, and who wrote it, on our Thanks page: https://www.passpack.com/info/thanks/
Cheers to all,
Tara
Hello,
I want to confirm Tara’s comment. A site’s vulnerability can not be judged by which libraries it uses, but rather, by the quality of the project itself.
For example, I often use jQuery since it’s a compact and efficient library. By default, jQuery uses the GET method, as it uses eval() to parse JSON strings. Both of these techniques break basic security norms. Luckily, these are not *required* behaviors for jQuery to work, they are just the default behaviors. Anyone can, and should, change the default behavior. All calls in Ajax should use POST (not GET) and all parsing should be controlled, not using eval().
To be fair, I want to point out that I have analyzed Clipperz’s code and they use DRW. This is the only framework mentioned by Fortify as inherently secure. I’m afraid that you chose the wrong project to cite in the title
Best regards,
Francesco Sullo
Ciao Francesco,
I am very pleased you took the time to look into our code, and even more pleased about the kind words you have used about our project in your comment.
Thank you very much!!!
Giulio Cesare
My first paragraph is probably poorly worded. What I was trying to explain is why I would be concerned as a general case in using multiple JavaScript libraries knowing the possibilities. Francesco, you have the perfect example. You are changing the default behavior. Having to change it more than once leaves more opportunity for security lapses. I'm still wary of JavaScript, and it's probably that old-time mindset that will be hard for me to shake. Also, it depends on what version of DWR you are using.
I think 2.0 is the latest and greatest with more security. Fortify ranked the previous release pretty much the same as jQuery, if I remember correctly.
Cyndy,
I can confirm that we are definitely using DWR 2.0 for the Clipperz service. And this since long before the Fortify report.
I'm sure you all are already aware of it, but I'm posting the link here for those who might be following this conversation that DWR 2.0 RC 4 has been released, and addresses additional concerns noted in the Fortify artice. Information can be found via Ajaxian.