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.
- 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.
Here s a summary of the dangers that AJAX introduces to applications:
- 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
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/.