RELATED: "Protecting Legacy Web Applications with AntiXSS" and "The Anti-Cross Site Scripting Library Reborn"
The Anti-Cross Site Scripting (AntiXSS) library has been a useful tool for preventing various kinds of script injection attacks against ASP.NET websites. AntiXSS is part of the Web Protection Library (WPL) along with a Security Runtime Engine (SRE). The SRE is an HTTP module that can automatically encode almost all at-risk output. For the most part, this means any output that’s generated from untrusted user input is encoded. Microsoft released these tools under its liberal Microsoft Public License (MS-PL) that lets you do anything you want with the library.
The AntiXSS library consists of an assembly with a set of encoding functions for any kind of user input, including HTML elements and attributes, XML, CSS, LDAP, and JavaScript. It uses a white list, which causes the library to encode anything not included in the white list. It is designed as a protection against cross-site scripting attacks, which are one of the most insidious ways that an attacker can break an application. AntiXSS helps you practice one of the fundamental tenets of web security: Treat all user input as dangerous and toxic threats.
The big news is that Microsoft is incorporating the core AntiXSS library features into version 4.5 of the .NET Framework in the System.Web.Security.AntiXss namespace, exposed through an AntiXssEncoder object. You can use methods of that type to encode data in various ways, but the easiest way to use the library is to configure an ASP.NET application to use the AntiXSS features by default. You can do this by adding the encoderType attribute to the httpRuntime element in web.config, as in the following example:
<httpRuntime ...
encoderType="System.Web.Security.AntiXss.AntiXssEncoder, System.Web,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
Here’s a list of encoding features from the AntiXSS library that Microsoft plans to incorporate into the framework:
- HtmlEncode, HtmlFormUrlEncode, and HtmlAttributeEncode. These methods encode data for use on HTML pages.
- XmlEncode and XmlAttributeEncode. These methods encode XML data.
- UrlEncode and UrlPathEncode. These methods encode URL content, including query string parameters.
- CssEncode. This method encodes input strings used in CSS elements values.
The current library namespace is Microsoft.Security.Application, so if you use the library today you’ll need to update code to use the new System.Web.Security.AntiXss namespace. Because it will be part of the .NET Framework, you won’t have to worry about deploying the AntiXSS library DLL to an application. One less detail to worry about.
The other component of the WPL, which won’t become part of the .NET Framework, is the SRE. It inspects each control reflected by ASP.NET and encodes data for the properties of vulnerable controls as appropriate. You register the module in web.config, as you do with any other HTTP module, and configure its behavior and the controls it affects in a separate antixssmodule.config file. A ConfigGen.exe utility generates the antixssmodule.config file for you, based on the application's assemblies. The SRE can be a useful tool for large websites where you don't want to write a lot of code to protect against XSS.
Although Microsoft claims that it's making the move to bring AntiXSS into the .NET Framework because of the library’s popularity, I suspect that it’s more because including AntiXSS directly as part of .NET will make it easy to use and more accessible to developers. Even in this day and age, I’ve found that relatively few developers go out of their way to implement strong security features that aren’t the default. Building them into the library will reduce the reluctance to implement the library’s features.
