For the client side, here are three major areas that I see mistakes being made in the implementation of Ajax.
- Exposure of Web services
Remember, a hacker can use the Web service directly without using the nice GUI interface you think they would use. Now, how is this dangerous? Let me give you an example. Let's say a developer has decided to "Ajaxify" his existing application by putting in some nifty IntelliType functionality in his Web site's search field (e.g. Google Suggest). This piece of Ajax code calls a Web service called "GetSearchItems". As he goes through the application, the developer finds several places where he can put this IntelliType feature and ends up creating multiple Web service methods for each one. He also decides to implement this feature in the administration section for searching for user names.
Now, Joe hacker comes along, sees this Ajax functionality for the public search field and decides to view the Web service file by requesting www.site.com/autocomplete.asmx. In return, the page lists every Web method available, including the admin listing of usernames. Joe hacker now just sends the letter 'a' to the "GetAdminUsers" method and he gets access to every username that starts with 'a' in the system. The above scenario is real. This was found on a Web site that I have assessed.
The main point of the story is that most people don't think about the Web services that they expose when using Ajax in a Web application and that you have to assume that every Web service being exposed can and will be used as an attack point.
- Viewing the source of a Web page
- Displaying admin menus unless they are an administrator
- Input validation
- Password prompts
- Keeping state in the browser, such as user roles and permissions
- Insecure Web service calls
I have seen a couple of Web applications submit sensitive data over a Web service in clear text and in a simple "GET" request where the data is in the URL. For instance, there was one application that had a nice Ajax function and as soon as a user entered in a credit card number and expiration date, it would validate the data when the user tabbed out of the field. The Web service it called did not make an SSL connection, and the data was sent in the URL for full exposure in the Web logs.
For the server side issues of implementing Ajax, here are a few things I have seen.
- Input validation
This issue has plagued software forever and will not go away. With the creation of Ajax and the explosion of Web services opening up because of it, the amount of input that the applications accept multiplies by an enormous amount. This in turn means more unvalidated input. I have seen example after example of Web service functions that are "SQL injectable" or have severe input security issues. Please, I beg of any developer -- even if it puts me out of work in the security business -- to please validate your input.
- Check for authentication and authorization
It seems like most people just pick a function in their existing project and decide to make it a Web service. I have seen multiple Web service calls that do very sensitive functions, such as adding users or validating credit card numbers, without any sort of authentication or authorization. It did not matter if a normal user called the admin functions or if a third-party Web site decided to start using their Web service to validate their credit card numbers. Treat a Web service like you would treat a Web form. Protect it!
- Safely encode outgoing data
Cross-site scripting (XSS) has always a big problem with Web applications. But now with Ajax, the exploitation technique for XSS has been elevated much higher. XSS is now a much more serious problem to solve, and Ajax helps make that point. Make it a practice to not only validate your incoming data but also safely encode that data going out. This can help you solve the pesky XSS problem once and for all.