First, with an AJAX application, you have to view the application as being broken into two parts. In the old Web 1.0 days, we didn’t worry much about “client-side” code in our web apps. That is, there wasn’t much code of significance executing in the web browser. In AJAX applications, there is significant code running in the web browser. It makes decisions, keeps track of state, and controls a lot of the user’s experience. We now must test this code to make sure that our application executes correctly. If we don’t, we’re omitting a significant chunk of the application from our tests.

The next important fact to realize is that AJAX applications require many application programming interfaces (APIs) on the server. Rather than being web pages or servlets that serve up complete HTML, these APIs respond with XML or JSON data that the JavaScript (in the web browser) parses and interprets. In the old days, we could spider a web application and look for all the JSPs, ASPs, or other public pages, and we were pretty confident that we knew all the access points and input points. With AJAX, you now need to know all the individual APIs that different AJAX objects may invoke, and they’re not obvious from spidering a website.

Lastly, you have to realize that failures can happen in both directions. That is, the client can send malicious data to the server, or the server can send malicious data to the client. Either kind of attack can create a security issue. Proxying tools like TamperData, WebScarab, and Burp are essential because they allow you to manipulate both directions of the communications channel.

So what are some common security failures that we test for in AJAX applications? One of the most common failures is in the security design of the APIs. Most big parts of an application (JSPs, ASPs, servlets, etc.) will perform proper authentication and authorization. They might include JavaScript, however, that invokes AJAX APIs with no authentication or authorization. That is, the AJAX APIs may not pay any attention to cookie values, who the user is, or any part of the session’s identity. Imagine a bank application, for example, that uses a servlet to show you a summary page with all your accounts on it. Clicking a plus sign next to the account invokes JavaScript that calls a server API to fetch the five most recent transactions. The JavaScript expands a box on the page to show those recent transactions. A common mistake in a design like this is for that server API to fail to check the authorization of the requesting browser. That is, the server API accepts an account number and returns the most recent five transactions without checking to see if the current session is authorized to view transactions on that account. Such mistakes, though obvious, are unfortunately quite common.

Another key security mistake in AJAX applications is to trust the client’s data without verifying that it is logical and obeys business rules. Imagine that the server sends a list of files and their associated permissions so that the JavaScript code in the web browser will show some files as deletable and others as permanent. Some server applications assume that the JavaScript in the web browser will always execute correctly a false assumption. So when the browser requests to delete a file, the server assumes that the file must be one of the files that was listed as deletable, without actually checking.

One final note about AJAX and Web 2.0: although we have been speaking exclusively about JavaScript executing in a web browser, Flash-based web applications operate in much the same way. The Flash applets make HTTP requests behind the scenes, much the same way that JavaScript objects do. The biggest difference is that Flash applets are opaque to us. We cannot see their source code and know how they work internally, whereas the source code of JavaScript objects is available to us through our web browser. If your web application is Flash-based or has some Flash elements in it, these techniques will work well for you. And the security failings that happen in AJAX applications happen just as often in Flash applications.

Spec India is a Custom Software Application Development and Software Solutions Company based in Ahmedabad, India. Our Services includes iPhone Application Development, Android Application Development, ORACLE, .Net, and Mobile Computing.

Find More Ipad Apps Articles