Every data theft, security breach and Web site vulnerability that grabs headlines further emphasizes the need to secure Web applications. As developers begin to move to Ajax and ASP.NET AJAX programming, security takes on a new level of importance.
Although the technology does not introduce any new security holes per se, Ajax does increase the attack surface open to hackers, since both browsers and servers are vulnerable, and makes it easier for hackers to launch attacks from a browser while the user is unaware of the activity.
Three security experts recently spoke to SearchVB.com about the types of security predicaments presented by Ajax development -- such as cross-site scripting and bridging attacks -- and offered their thoughts on how to combat them.
Billy Hoffman, lead researcher at SPI Dynamics, said in a recent interview with SearchVB.com that ASP.NET AJAX does not really change Windows security. "Rather, it magnifies the damage and the amounts of places that can be attacked compared to traditional web apps," he said.
Moreover, developers familiar with the Web, and even with Ajax, may still be at a loss. According to John Carpenter, DevPartner SecurityChecker product manager at Compuware, most Ajax development manuals don't address Ajax security. On top of that, Ajax can expose the browser as well as the server. "This is setting the stage for hacks, because the attack surface is so large and the Ajax developers tend to be inexperienced," he said.
Hoffman agreed. "A lot of programmers writing ASP.NET AJAX applications are desktop programmers [who] are not familiar with writing Web applications. Developers need to be even more aware of security practices."
The value of input validation
One key strategy for addressing Ajax application security is to ensure that all data submitted through Ajax applications is properly validated. One of the popular strategies for hackers to get into Web sites is to send data into online forms, which crashes the application and enables them to access supposedly secure data and application on the back end. Hoffman said this is the kind of approach often used to steal credit card numbers.
There are two main methods of input validation -- white lists and black lists. White lists specify what kinds of characters and input are considered valid, whereas black lists specify characters and data that are prohibited.
Hoffman recommended that programmers focus on white lists. Typically, programmers use black lists to specify characters that have been reported to be used in a new style of attack. However, hackers are constantly finding new creative ways of using infrequently used characters to compromise security.
A typical Web site might only have a few forms used to gather data from users. Hoffman noted that, as soon as you Ajax-ify your site to make it more responsive, you open it up to more inputs, each of which is a potential security hole.
"If there is one thing to walk away with with Ajax, it is that the same kind of flexibility and ability to be responsive and have everything take place in the background also means attackers can do this stuff in the background. From the user's point of view, nothing is happening," Hoffman said.
The dangers of cross-site scripting
Normally, when some foreign code takes over a browser, a Web surfer would notice his browser was doing something strange. But with Ajax, a lot of the activity is executed in the background, making it difficult for the user to notice that his browser is in the process of doing something like sending out hundreds of spam message from a Yahoo email account.
First, he explained, the worm executed as soon as a user opened his email and before he or she downloaded any attachments. Then it sent out copies of itself to everyone on the user's contact list in the background. Finally, it sent a list of everyone on the contact list to a site in Russia. "Over a high-speed Internet connection, the user's browser could send out hundreds of emails in a matter of minutes without the user being aware of what was going on," Hoffman noted.
Avoiding bridging attacks
Another potential security hole amplified by Ajax is the use of bridging attacks. Here a hacker is able to compromise Site A and then use this to better attack a more secure Site B, which has a trusted related with Site A. Hoffman has not heard about any bridging attacks in the wild but said he would not be surprised if one were to emerge within the coming year.
ASP.NET AJAX addresses bridging attacks well, as it only allows Web services calls to be made within the same domain, noted Jeff Procise, co-founder of Wintellect.
The downside is that, without bridging, it is hard to build a mashup, which is a page the aggregates data from lots of Web sites. Mashups are proving quite popular in the world of Web 2.0, as contributor Mike Gunderloy points out in Mashing: It's not just for potatoes any more.
Developers can still do bridging with ASP.NET AJAX, Procise said, but they have to go through their own Web server.
Code protection tools: few and far between
At the moment, there are few resources for developers to create secure AJAX code.
SPI Dynamics offers the DevInspect development tool, which integrates into Visual Studio to check for security holes as applications are being developed. It includes a library of 70 regular expressions, which makes it easier to use white lists for input validation.
Meanwhile, Compuware's Carpenter said the company plans to include improved Ajax security measures in the upcoming update to its DevPartner Security Checker.