Web 2.0 Inherently Insecure?

When I first heard a number of claims that AJAX applications were inherently more insecure than standard web applications, I thought that was ridiculous. After all, as long as you don't do anything stupid like do validation of user input only on the client, what would you have to worry about?While on one level that may be true, it looks like in the general case I was wrong. Splitting web applications into two distinct programmatic components, one that runs in the browser, and one that runs in the server is more complicated (at the very least you've got to be proficient now in two different languages), and there are definitely new types of vulnerabilities that are specific just to AJAX applications. Fortify Software's Javascript Hijacking Vulnerability advisory had a title that originally set off my... well, we'll just call them "Bad Stuff" detectors. It sounded like traditional vendor hype about a problem that when you look closely isn't really all that bad. Except in this case, it might just be that bad.

The crux of the paper is that a number of pre-existing AJAX frameworks are trivially vulnerable to a type of exploit that Jeremiah Grossman first reported on over a year ago.

While the X in AJAX stands for XML, many Web 2.0 applications don't actually use XML as a container for the data being passed back and forth between the client and the server. After all, it's a bit heavy on the network and the code just to pass a few variables back and forth. Instead, implementations like JSON pass data between the web server and the client that is either a Javascript object, or even code that can be directly evaluated in Javascript. This simplifies the processing needed to be done on the client-side and many popular frameworks and applications utilize this methodology.

The problem as pointed out by Jeremiah originally in Gmail and Fortify more generally, is that CSRF (Cross-Site Request Forgery) attacks that succeed because other websites can cause your browser to make requests to another domain name with your current session cookie for that site (indeed, if they couldn't the WWW wouldn't be a very interesting place) can trivially over-ride default Javascript functions to obtain access to the data being returned by the remote server (a violation of the browser's same origin policy).

This means that a lot of applications are going to need to be updated. If the framework developers can't get it right, what are the odds that the average developer is going to be able to learn the techniques needed to keep himself secure? Hopefully the browser vendors and the framework and toolkit developers will be able to help the average Joe Developer out and create secure options instead of making him do it all on his own.Of course, one upside is that I'm working on the rolling review of web application scanners and their ability to handle AJAX that starts with our May 14th issue, so make sure to check that out if you're interested in reading more.