Understanding ASP.NET <st1:City><st1:place>AJAX</st1:place></st1:City> Security

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

ASP.NET Under the Hood

LANGUAGES: VB.NET | C#

ASP.NET VERSIONS: 2.0

 

Understanding ASP.NET AJAX Security

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

 

By Daniel N. Egan

 

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

 

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

 

A. AJAX and Web 2.0 are hot topics today and have infused the development community with new excitement. One of the main reasons AJAX is taking off now when the technology has been around for years is because of the proliferation of AJAX frameworks hitting the market. Using AJAX frameworks like ASP.NET AJAX makes it easy for developers to add asynchronous capabilities to their Web applications. When using any type of AJAX framework, no matter how easy it makes it, you need to make sure you understand what is going on under the hood so you don t inadvertently leave holes in your application that hackers can take advantage of. In this article we ll touch on some of the issues that are important to ASP.NET developers, as well as how the issues relate to AJAX.

 

The AJAX Security Debate

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

 

Increased Attack Surface

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

 


Figure 1: A non-AJAX page.

 

The dynamic nature of AJAX applications allows Web pages to automatically update different sections of your page which may also make them less secure. Every point in your page where you are using AJAX to validate, aggregate, or update creates another location that is potentially vulnerable to attackers. To achieve the rich experience users expect on the Web, AJAX relies on Web services to provide data that can asynchronously update pages without the appearance of a full round trip.

 

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

 


Figure 2: An AJAX page.

 

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 and determine the appropriate measures to counteract each threat. We ll discuss some of these threats in the remainder of this article.

 

Client Validation as Security

Client-side validation is a technique used to avoid round-trips and ensure that data passed back to an application is formatted correctly. These can take the form of UI elements, dropdown lists, regular expressions, and pure JavaScript. While these validation control measures can help ensure your input data is formatted correctly, far too many developers use these techniques to implement input security in their Web applications. Client-side validation should never be used as a security measure. These simple measures 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 them to monitor, inspect, and debug their AJAX-enabled applications.

 


Figure 3: Localhost proxies allow you to intercept requests and manipulate the results before they reach the server.

 

But this same power can also be used to manipulate requests by would-be attackers and circumvent any client-side validation. ASP.NET AJAX specifically addresses this issue by allowing you to authenticate users accessing your services. This can be accomplished by using the Microsoft AJAX Library authenticationService to verify credentials stored as part of the ASP.NET membership services, or by accessing the user portion of the HTTPContext object on the server. This can be combined with a hashed token embedded into the HTML output, retrieved during the call, and compared on the server to help confirm the authentication of each request. For a spirited discussion of 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 where malicious scripts are injected into the URL or form fields of a site and then run by unsuspecting victims (see Figure 4).

 


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

 

In a traditional guestbook application, users are allowed to use a form to add their name and a greeting to the guestbook database. When other users view the guestbook, they are able to see the names and greetings of previous users. If users are allowed to enter unfiltered data into the form, attackers can have their malicious entries saved to the database simply by typing them 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 the scripts on your machine, either by having you access his Web page or by injecting the script into a public Web page. To view the many ways scripts can be used for this attack, check out the XSS Cheat Sheet at http://ha.ckers.org/xss.html. Using this 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 Sammy MySpace Worm used AJAX and JavaScript 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 would infect anyone visiting their page, as well. In less than 20 hours, Sammy had 1 million friends on MySpace and caused the site to shut down for several hours. Although MySpace had taken steps to protect themselves against XSS, Sammy found ways to get past the filters and thwart their protection measures. Check out Sammy s entertaining post for a full technical description of how he got around the MySpace filters (http://namb.la/popular/tech.html).

 

There are many things you can do in your ASP.NET application to help protect yourself from this type of attack the first of which is on by default. The validateRequest attribute set in your web.config file will automatically block what it determines to be dangerous tags entering your 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, this setting may be too restrictive for your application s needs. If this is the case, you can turn this off by setting it to false either in the web.config or on individual pages:

 

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

 

If you do this, you ll have to filter potentially dangerous tags like ,