EXPERT RESPONSE
First off, I would like to clear up what I feel is a big misunderstanding to the world on Ajax security. Ajax itself does not have any security issues. It is how Ajax is implemented that causes security problems. Ajax is nothing more than the combination of Web services and JavaScript. I look at it like SQL Injection. There is no vulnerability in the SQL language itself, SQL injection attacks result from the way the language is implemented when using user input. So now that I have gotten that out, here are my tips for securely implementing Ajax on both the server side and client side.
For the client side, here are three major areas that I see mistakes being made in the implementation of Ajax.
- Exposure of Web services
With everyone implementing some sort of nifty Ajax capability these days developers are starting to convert (open up) major back-end APIs to Web service methods. Some of these methods are for public consumption, and some are not. Since JavaScript is used to access these services, any curious person can go through the code and identify all points in which a Web service is available to call.
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.
- Relying on JavaScript for any type of restrictions
Many Web sites will use JavaScript to restrict a user from doing something. Here are some examples:
- 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
Realize that all JavaScript can be reverse engineered. Don't put anything in JavaScript that you would not feel safe handing over to a bunch of hackers. DO NOT depend on JavaScript to do any input validation.
- 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.
As a final point, JavaScript and XML are not necessarily dangerous. Just be careful how you implement them. Remember -- Ajax is really just useful for making user interaction much more pleasant and smooth for the user. Don't start putting Ajax everywhere in your application just because it looks cool. Really analyze your application and identify where and how Ajax can add a real benefit and carefully implement it while keeping security in mind.
More information
|
