Ajax security holes and how to fill them

Along with improvements in UI and client-side programming, Ajax brings security issues. Here three experts identify Ajax security shortcomings and how to address them.

Our ASP.NET AJAX series
In this three-part series, SearchVB.com takes a close look at ASP.NET AJAX development.

Part 1 takes a look at what makes programming with ASP.NET AJAX different from programming with ASP.NET.

Part 2 considers the capacity for ASP.NET AJAX applications to operate faster, and on a larger scale, than traditional ASP.NET apps.

Part 3 examines the security concerns raised by ASP.NET AJAX development and offers some thoughts on how to combat them.

 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.

[T]he 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.
Billy Hoffman
lead researcherSPI Dynamics

The dangers of cross-site scripting

Cross-site scripting, in which a hacker injects JavaScript into a web site, also presents a security pothole for developers. Traditional security tools like antivirus software do not work well for this kind of attack, said Hoffman, because all the activity takes place inside the browser.

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.

Last June, the JS.Yamanner@m worm plagued Yahoo's mail system. "It is a great example of how even though JavaScript is kind of sandboxed, you can still do nasty stuff with it," Hoffman said.

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.

There are, however, limits to the scope of these kinds of attacks. JavaScript does not give the browser the ability to run executables or to change files on the client machine directly.

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

More on ASP.NET AJAX
ASP.NET AJAX Learning Guide

Tip Series: Get started with ASP.NET AJAX development: Part 1  |  Part 2  |  Part 3

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.

Dig deeper on ASP.NET and Ajax development

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudComputing

SearchSoftwareQuality

SearchSOA

TheServerSide

SearchCloudApplications

Close