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.
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
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.
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