Understanding ASP.NET AJAX Security

ASP.NET Under the Hood

LANGUAGES:VB.NET | C#

ASP.NETVERSIONS: 2.0

Understanding ASP.NET AJAXSecurity

Learning What to Look for when Working with the ASP.NET AJAXFramework

By Daniel N. Egan

Greetings ASP.NET architects and developers! In this articleI ll answer some questions about ASP.NET AJAX and security. If you havequestions that need answers, send them to [email protected]!

Q. We ve started working with ASP.NET AJAX and have beenhearing about security concerns related to AJAXdevelopment. What type of security issues should I look out for?

A. AJAX andWeb 2.0 are hot topics today and have infused the development community withnew excitement. One of the main reasons AJAXis taking off now when the technology has been around for years is because ofthe proliferation of AJAXframeworks hitting the market. Using AJAXframeworks like ASP.NET AJAX makes it easy for developers to add asynchronouscapabilities to their Web applications. When using any type of AJAXframework, no matter how easy it makes it, you need to make sure you understandwhat is going on under the hood so you don t inadvertently leave holes in yourapplication that hackers can take advantage of. In this article we ll touch onsome of the issues that are important to ASP.NET developers, as well as how theissues relate to AJAX.

The AJAX SecurityDebate

When talking about AJAX,the conversation inevitably turns to the question of whether AJAXapplications are secure. The short answer is that AJAX,as a technology, does not create any new security threats, but instead exposesmore ways for hackers to utilize current Web attacks. As a developer, whetheryou are developing AJAXapplications or not, security and threat modeling should not be an afterthought,but something that permeates your design planning from beginning to end. Inthis article, we ll cover some of the more prevalent security concerns you willface as a Web developer and how they relate to AJAXapplications.

Increased Attack Surface

In a traditional Web application, you can control thesecurity of your page by securing the endpoint, or point of contact, with yourserver(s). Like a house with only one door, it is easy to see where a hacker islikely to attack (see Figure 1).

Figure 1: A non-AJAX page.

The dynamic nature of AJAXapplications allows Web pages to automatically update different sections ofyour page which may also make them less secure. Every point in your pagewhere you are using AJAX tovalidate, aggregate, or update creates another location that is potentiallyvulnerable to attackers. To achieve the rich experience users expect on the Web,AJAX relies on Web services toprovide data that can asynchronously update pages without the appearance of afull round trip.

Most of your logic in a non-AJAX application, if not all,will reside on the server. In an AJAXapplication you expose Web service calls via JavaScript, which is easily readby viewing the source of a page. You can obfuscate your JavaScript to make thisdiscovery slightly more difficult, but it will only serve to slow down awould-be attacker (see Figure 2).

Figure 2: An AJAXpage.

To counteract the effect of an increased attack surface,you and your development team need to practice threat modeling. More precisely,you must carefully review all the endpoints your application exposes anddetermine the appropriate measures to counteract each threat. We ll discusssome of these threats in the remainder of this article.

Client Validation as Security

Client-side validation is a technique used to avoidround-trips and ensure that data passed back to an application is formattedcorrectly. These can take the form of UI elements, dropdown lists, regularexpressions, and pure JavaScript. While these validation control measures canhelp ensure your input data is formatted correctly, far too many developers usethese techniques to implement input security in their Web applications.Client-side validation should never be used as a security measure. These simplemeasures can very easily be bypassed by any number of localhost proxy tools(see Figure 3). These tools can be a great asset to developers by allowing themto monitor, inspect, and debug their AJAX-enabled applications.

Figure 3: Localhost proxies allowyou to intercept requests and manipulate the results before they reach theserver.

But this same power can also be used to manipulaterequests by would-be attackers and circumvent any client-side validation. ASP.NETAJAX specifically addresses this issue by allowing you to authenticate usersaccessing your services. This can be accomplished by using the Microsoft AJAXLibrary authenticationService to verify credentials stored as part of theASP.NET membership services, or by accessing the user portion of theHTTPContext object on the server. This can be combined with a hashed tokenembedded into the HTML output, retrieved during the call, and compared on theserver to help confirm the authentication of each request. For a spirited discussionof this approach, check out Matthew Mullenweg s blog at http://photomatt.net/2005/08/28/ajax-and-xss/.

Cross-site Scripting (XSS)

Cross-site Scripting (XSS) is a security exploit wheremalicious scripts are injected into the URL or form fields of a site and thenrun by unsuspecting victims (see Figure 4).

Figure 4: This guestbook applicationillustrates how an XSS attack is perpetrated.

In a traditional guestbook application, users are allowedto use a form to add their name and a greeting to the guestbook database. Whenother users view the guestbook, they are able to see the names and greetings ofprevious users. If users are allowed to enter unfiltered data into the form,attackers can have their malicious entries saved to the database simply by typingthem into the Web form fields. When an unsuspecting user views the guestbook,thus retrieving the malicious code from the database, the scripts will be run.The important point is this; the attacker has to somehow get you to run thescripts on your machine, either by having you access his Web page or byinjecting the script into a public Web page. To view the many ways scripts canbe used for this attack, check out the XSS Cheat Sheet at http://ha.ckers.org/xss.html. Usingthis technique, attackers can attempt everything from account hijacking,changing of user settings, cookie theft/poisoning, or false advertising.

In a recent and well-known attack, the author of the SammyMySpace Worm used AJAX andJavaScript to add himself as a friend to anyone who visited his MySpace page.In addition, he injected into the unsuspecting victim s page script that wouldinfect anyone visiting their page, as well. In less than 20 hours, Sammy had1 million friends on MySpace and caused the site to shut down for severalhours. Although MySpace had taken steps to protect themselves against XSS,Sammy found ways to get past the filters and thwart their protection measures. Checkout Sammy s entertaining post for a full technical description of how he gotaround the MySpace filters (http://namb.la/popular/tech.html).

There are many things you can do in your ASP.NETapplication to help protect yourself from this type of attack the first ofwhich is on by default. The validateRequest attribute set in your web.configfile will automatically block what it determines to be dangerous tags enteringyour application through open Web forms:

If an attempt is made to enter script tags into your form,an error will be thrown and the request will abort. In some instances, thissetting may be too restrictive for your application s needs. If this is thecase, you can turn this off by setting it to false either in the web.config oron individual pages:

<%@ Page ... validateRequest="false" %>

If you do this, you ll have to filter potentiallydangerous tags like ,