Secure ASP.NET
What Makes AJAX So Dangerous?
By Don Kiely
AJAX is still one of the cool Web 2.0 technologies; for some, it is the Web 2.0 technology. It can make your Web applications look and feel almost like the richest desktop application, largely eliminating the full-page refresh that constantly reminds the user they are working in a browser. But as I introduced last month, it can introduce a huge security vulnerability (many of them, in fact) any time you innocently put a bit of AJAX code in a page.
On the face of it, this seems a bit strange. All AJAX really consists of is a ton of JavaScript, using nothing all that new nothing that hasn t been around since almost the birth of the Web. The basic problem is that JavaScript itself has security warts that hackers have discovered through the years. But that alone doesn t explain AJAX s security problems.
The problem lies in the level of usage of JavaScript and the new ways it is being used:
- The typical AJAXified Web page has orders of magnitude more JavaScript being used in far more complex ways.
- All those asynchronous calls (which typically aren t really asynchronous, but that s not pertinent here) are passing data back and forth at a furious rate as the user clicks around the page. Many applications I ve seen do little to secure that data, even though the page as a whole uses good security practices to download the page to the browser and post data back to the server.
- AJAX moves portions of what has previously been server-side processing down to the browser, opening it up to discovery and abuse by the user savvy enough to know how to poke around the client side of the application. The locations of Web services, for example, are now exposed to the client, where before they were safely tucked away on the server. Some applications make it fairly trivial to call services out of sequence to bypass, for example, an authentication service. When it was all executing on the server, there was no way for the client to know the order in which processing occurs. With AJAX, it s all right there in the code sent to the browser.
- Much of the complexity arises from going from a single call to the Web site that loads an entire page, to many more granular calls back and forth. This is replete with problems. First, you have to make sure that every single call to the server is secure, and now you have to deal with a huge number of calls. Second, the possibilities for denial of service attacks multiplies, since there are a whole lot more places to attack. The bottom line is that an AJAX application is typically far more complicated, and complication leads to vulnerabilities unless you are extremely diligent and consistently apply good security practices.
- Probably worst of all, AJAX attacks are largely invisible to users. In the pre-AJAX days, malicious code was often detected because a page refresh occurred at a weird time, when it wasn t supposed to happen. But now, a lot of the interaction is going on behind the scenes, often with no visible indication that the browser has made a new call to the server. Sometimes only by monitoring the network closely can you detect 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 policy prevents a script loaded from one location on the Internet to run or do anything with script from another location. The basic concept is that it is okay to trust script called from the same place where the currently executing code came from, but not from other places. In theory, this prevents things like certain forms of cross-site scripting. But we know from practice that the same-origin policy is pretty easy to circumvent, and plenty of attacks have worked around the limitation.
Here s a summary of the dangers that AJAX introduces to applications:
Architecture
- Increased attack surface with all the chatter going back and forth between browser and server
- Leaking information through multiple exchanges of data and transmitting as clear text
- Exposure of internal server functions, mostly through Web services but other ways as well
- Granting direct access to application APIs and Web services, often with no security protections (relying on security through obfuscation), and allowing calls out of order
Relocation of Processing to Client
- Moves business logic to client so that it is easily discoverable
- Requires a trust relationship between client and server 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 execute data 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 just because an AJAX framework any AJAX framework hasn t been successfully attacked, doesn t mean it won t be.
But the good news is that you can write secure AJAX applications. I ll continue exploring the issues and solutions in the months ahead.
Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications 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/.
