Ajax Security more than Increased Attack Surface

I got an email from Christ1an the other day asking me what Ajax Security was all about. I was just going to send him the table of contents to the book, but I thought it might be educational to see how the components of Ajax security relate, and where they come from. In Jeremiah's fascinating Web Application Professionals Survey less than 3% of people think there is nothing new about Ajax security which jives with the idea of Ajax Security acceptance.  And while over 2/3 understand that Ajax applications have an increased attack surface, many of the comments showed that some people believe Ajax security is just about an increased attack surface.

Let me assure you, if Ajax Security was only about an increased attack surface two things would have happened:

1. Addison Wesley won't have asked me to write a 500+ page book about it
2. Bryan and I would have finished a long time ago :-)
   

 There are many issues with Ajax Security and hopefully this piece will help people see the bigger Ajax Security picture.

 -Billy

Ajax makes applications more responsive. It does this by allowing client-side JavaScript to asynchronously fetch data from the web server without blocking user interaction or refreshing the web page. This seems trivial, but it is not. Everything about Ajax security stems from this fundamental shift in application architecture.

This shift means there must be code running on the client to send these requests and process the results. So what is it talking to? Web services running on the server which may or may not have been there before. Attack surface grows, so at the very least developers have more inputs that need to be properly secured. Anyone reading Full Disclosure or Secunia knows how well we are doing in that department as is. But you already knew that, so lets more on.

Ajax application straddle the network and exists on both the server and the client. So what’s in that client side code? Variables names, return values, string and numeric constants, data types, value ranges, proper program flow based on which web services are called in what order and which interdependent values. All good details about the inner working of an application. That black box is looking a little gray. What’s more there’s an interaction between the client and the server code and the attacker controls the client. Variable x is used by web service 1 and web service 3, only its value can be modified by an attacker between the two uses. An attacker can call the web services out of order, manipulate the logic, etc. Reverse Engineering of client code is a growing field, so don’t count on protecting your logic.

The fundamental unit of a traditional web app is a web page written in HTML. The fundamental unit of an Ajax web application is arbitrary data. So how do developers move data back and forth between client and server? With a data transport layer! Sure they can use name/value pairs in a query string when submitting data, but what about the format for what gets returned? JSON, SOAP, CSV, Base64, binary data, and custom formats are all fair game. And with it come the problems of implementing robust parsers and serializers while avoiding Denial of Service attacks.

And lets not forget forgot all the programming errors of writing an enterprise web application in still more programming languages. Functions like String.replace(), String.substring() and RegExs don’t work in JavaScript the way the work in most languages. It’s interpreted so everything except syntax errors are runtime errors. And it’s asynchronous, so you can have race conditions, deadlocks, livelocks, etc. Have fun QAing that. There are also odd properties of JavaScript, like dynamic reassignment of functions. And you can do a lot more then just JSON hijacking. Function clobbering, logical MITM, and even real-time JavaScript environment monitoring to attack lazy loading are all possible and explored in the book.

If developers do silly things in client-side code now, what do you think they will do when that client-side code actually does something meaning for the application? It was pretty hard to have a database connection string on the client in a traditional application because there was not much that could be done with it. Ajax applications are talking directly to data tiers and more business logic is ending up on the client. After all, the client is a place where code can execute so developers use it. They are doing more and more on the client and even adding new features to the client. Now we have client-side storage, which opens a giant can of worms. How is the data stored? It’s it session or global oriented? How much can I store? What can I store? Do I have to serialize everything to a string? More data transport layer issues! Can it auto expire or is the develoepr responsible for clean up? Does it require user interaction to clear it? What are the access controls? Which sites can access also access the data? Does exposing access to the data expose my API as well? I’m looking at you crossdomain.xml! Cross directory, cross domain, and cross port attacks, data integrity, and missing data are all concerns of the developer. And every storage method, from cookies to DOM Storage, to Flash LSO and IE’s userData do things differently. Too bad Dojo.Storage abstracts away which is being used when you application must be written with certain assumptions. Cooke storage = built in HTTP Response Splitting vulnerability.

And speaking of enabling the client, look at offline Ajax frameworks like Google Gears, Dojo.Offline, and Microsoft Sync. Now we are writing so much of a web application in JavaScript that it can do meaningful things when it’s not even connected to the Internet. There can be no isolation of business logic there. Code transparency issues just got worse. Transparent local web servers to serve cached resources that can be poisoned from other web apps (including poisoning the JavaScript logic of the offline Ajax app). Extended threading models that allow CPU intense JavaScript to run in a separate thread (think Jikto, JavaScript port scanning, or XSS-Proxy running all the time). JavaScript accessible SQL databases that can auto sync with the server are even cropping up. Yes, with offline Ajax applications you can have client-side SQL injection attacks!

The widget craze is largely possible with Ajax and thus is an important subject for Ajax security. After all, could you imagine a web page with 9 widgets that all have to do post backs with full page refreshes to exchange data with the server? The web application would always be blocking and unresponsive with nothing but “Receiving data from PageFlakes” on the screen! IFrame jails, cross widget attacks and hijacking, degrading trust of 3^rd party data sources, cross Flash communication, data leakage, and crazy/bad stuff like JavaScript implementations of RSA and SHA-256 are all covered. And let’s not forget mashups. You want to take data from numerous untrustworthy sources and load them in your security context? Cascading exploits, misplaced trust, and the Confused Deputy all play out in that arena.

And what about all this rich content you are accepting? Web 2.0 is the world of user generated content after all. RSS feeds, sitemaps, Cascading Style Sheets, JavaScript code snippets. Forget validating that a telephone number is really a telephone number, how do we validate rich content? How do you deal with phishing attacks and polymorphic JavaScript which evade widget filter functions? What about attacks that exploit nothing but DOM styles? A magician succeeds by fooling your eyes and nothing else; the same is true for presentation layer attacks.

What native security features do the frameworks like DWR, Dojo, Prototype, and ASP.Net Ajax provide? What do you have to implement yourself? What features are on by default that you don’t know about? How does a developer choose an appropriate framework? How do QA test an Ajax application when a textbox might contain a SQL injectionable web service but the ODBC message is suppressed by the JavaScript?

We’ve only just started to talk about what’s in the Ajax Security Book. There is still JavaScript malware, control flow exploitation, request origin uncertainty and more. Hopefully this little taste shows you that there is far far more to Ajax Security than some JavaScript eye candy and an increased attack surface. Developer, QA professional, and hacker alike will all find Ajax Security an enormously powerful resource to help design, build, test, and hack Ajax applications.