First of all, let's get this out of the way.....AJAX itself does not introduce any new vulnerabilities to your applications....period.
The problem with AJAX is the way an AJAX application is implemented-- the same [old] mistakes are being made -- AJAX itself brings nothing new to the table. Quite honestly, if you review the common components of AJAX, you will see that there are really no new technologies being introduced with the framework ... developers are simply making the same errors in developing the application. Let's face it ....there is a pretty buzz around AJAX right now and folks are flocking to the solution like Bill Gates is flocking to the iPhone (you know he's going to buy one).
So....let's start from the beginning.
- User Interface -- Presentation using XHTML and CSS
- Document Rendering-- Dynamic display and interaction using the DOM
- Transport of Data -- Data interchange and manipulation using XML
- Messaging Handling -- Asynchronous data retrieval using XMLHttpRequest
One of the key differences (and there are many) between a standard web application and an AJAX-based application is the method that data is exchanged between the client and the server. With a standard application, the client browser will make one large request to the server with everything it needs....an example HTTP Request would be:
GET /index.html HTTP/1.1
Accept-Encoding: gzip, deflate
Once this request is submitted, the browser will flash, objects will spin, the planets will align and all this neat stuff happens in the background. On the other side of the fence, we do not "see" most of what is happening with an AJAX application due to the use of XMLHttpRequest object which is the technology that really performs much of the magic.
[server side logic]
By removing some of the logic from the server/application environment, we end up with ....
[server side logic]
You can see that much of the logic is now exposed to the client. With much of the logic now exposed, you can imagine that the surface area of the application is now represented to the end user.....these points of attack are a very common gateway for an attacker to now get in to the application.
Are we leaking information?
One concern for applying more logic to the endpoint is now much of your application is now mapped out for the end user. A few items to note would be that:
- Function and Variable Names
- Inputs and Validators
- Parameters, Data Types and Return Types
Using solutions such as a localhost proxy, firebug or many other inspection tools might allow an attacker the ability to modify the code as it's being submitted and received in the connection.
If you haven't been exposed to firebug, I would absolutely recommend you seek it out. Firebug is an add-on which inserts itself directly into the Firefox browser. Keep in mind that Firebug is NOT a tool for security testing your web applications, but is simply (in my opinion) a debugging tool. After you have installed firebug, you can generate traffic and it provides you with a nice little tool for object inspection.....it really gives you a great visual on exactly what the XMLHttpRequests are doing in the background.
If you are interested (on the other hand) in assessing your AJAX applications, there is a very nice little tool provided by the folks over at The Denim Group in San Antonio called Sprajax. To quote the OWASP site...."Sprajax is an open source black box security scanner used to assess the security of AJAX-enabled applications. By detecting the specific AJAX frameworks in use, Sprajax is able to better formulate test requests and identify potential vulnerabilities."