IT Management

What Makes AJAX So Dangerous?

AJAX is neithersecure nor mature. But, as Don Kiely explains, you can write secure AJAXapplications.

October 30, 2009

5 Min Read

Secure ASP.NET

What Makes AJAXSo Dangerous?

By Don Kiely

AJAX is stillone of the cool Web 2.0 technologies; for some, it is the Web 2.0 technology. It can make your Web applications look andfeel almost like the richest desktop application, largely eliminating thefull-page refresh that constantly reminds the user they are working in abrowser. But as I introduced last month, it can introduce ahuge security vulnerability (many of them, in fact) any time youinnocently put a bit of AJAX codein a page.

On the face of it, this seems a bit strange. All AJAXreally consists of is a ton of JavaScript, using nothing all that new nothingthat hasn t been around since almost the birth of the Web. The basic problem isthat JavaScript itself has security warts that hackers have discovered throughthe years. But that alone doesn t explain AJAX ssecurity problems.

The problem lies in the level of usage of JavaScript andthe new ways it is being used:

The typical AJAXified Web page has orders ofmagnitude more JavaScript being used in far more complex ways.
All those asynchronous calls (which typicallyaren t really asynchronous, but that s not pertinent here) are passing databack and forth at a furious rate as the user clicks around the page. Manyapplications I ve seen do little to secure that data, even though the page as awhole uses good security practices to download the page to the browser and postdata back to the server.
AJAX moves portions of what has previously beenserver-side processing down to the browser, opening it up to discovery andabuse by the user savvy enough to know how to poke around the client side ofthe application. The locations of Web services, for example, are now exposed tothe client, where before they were safely tucked away on the server. Someapplications make it fairly trivial to call services out of sequence to bypass,for example, an authentication service. When it was all executing on theserver, there was no way for the client to know the order in which processingoccurs. With AJAX, it s all rightthere in the code sent to the browser.
Much of the complexity arises from going from asingle call to the Web site that loads an entire page, to many more granularcalls back and forth. This is replete with problems. First, you have to makesure that every single call to the server is secure, and now you have to dealwith a huge number of calls. Second, the possibilities for denial of serviceattacks multiplies, since there are a whole lot more places to attack. Thebottom line is that an AJAXapplication is typically far more complicated, and complication leads tovulnerabilities unless you are extremely diligent and consistently apply goodsecurity practices.
Probably worst of all, AJAXattacks are largely invisible to users. In the pre-AJAX days, malicious codewas often detected because a page refresh occurred at a weird time, when itwasn t supposed to happen. But now, a lot of the interaction is going on behindthe scenes, often with no visible indication that the browser has made a newcall to the server. Sometimes only by monitoring the network closely can youdetect that something is going on.

What about JavaScript s Same-Origin Policy limitation?Originated way back in Netscape Navigator 2.0 all those years ago, the policyprevents a script loaded from one location on the Internet to run or doanything with script from another location. The basic concept is that it isokay to trust script called from the same place where the currently executingcode came from, but not from other places. In theory, this prevents things likecertain forms of cross-site scripting. But we know from practice that thesame-origin policy is pretty easy to circumvent, and plenty of attacks haveworked around the limitation.

Here s a summary of the dangers that AJAX introduces toapplications:

Architecture

Increased attack surface with all the chattergoing back and forth between browser and server
Leaking information through multiple exchangesof data and transmitting as clear text
Exposure of internal server functions, mostlythrough Web services but other ways as well
Granting direct access to application APIs andWeb services, often with no security protections (relying on security throughobfuscation), and allowing calls out of order

Relocation of Processing to Client

Moves business logic to client so that it iseasily discoverable
Requires a trust relationship between client andserver that often isn t there, making it exploitable by an attacker

Confusion of Data and Control Channels

Treating data as code is a recipe for disaster,as we should have learned from SQL injection and other attacks that can executedata as code

The bottom line is that AJAX is neither secure nor mature.Just because it uses dusty old JavaScript doesn t make it safe. And justbecause an AJAX framework any AJAXframework hasn t been successfully attacked, doesn t mean it won t be.

But the good news is that you can write secure AJAXapplications. I ll continue exploring the issues and solutions in the monthsahead.

DonKiely, MVP, MCSD, is a senior technology consultant, building customapplications as well as providing business and technology consulting services.His development work involves tools such as SQL Server, Visual Basic, C#,ASP.NET, and Microsoft Office. He writes regularly for several trade journals,and trains developers in database and .NET technologies. You can reach Don at mailto:[email protected]and read his blog at http://www.sqljunkies.com/weblog/donkiely/.

About the Author

Don Kiely

Don Kiely

See more from Don Kiely

You May Also Like