Prevent Cross-Site Scripting Attacks with Microsoft’s AntiXSS

Cross-site scripting (XSS) is a frequent way that hackers attack sites (Symantec estimated that, in 2007, cross-site scripting accounted for 80% of all documented site vulnerabilities), surpassing even buffer overflows as the most commonly reported vulnerability. The goal of XSS is to insert malicious scripts into Web pages in order to access cookies or to gain privileges that the user is not entitled to (among other goals).

Microsoft has provided its Web Protection Library (WPL) to protect ASP.NET sites from XSS (and provide some additional protection against SQL Injection attacks). While sites using ASP.NET 3.5 or 4.0 will need to download the package from CodePlex, Microsoft’s intention is to include the library with .NET Framework 4.5. Downloading the library gives you a new DLL called AntiXSSLibrary.DLL which you’ll need to add as a reference to your ASP.NET or ASP.NET MVC application to use it (after installation, I found the DLL in C:Program Files (x86)Microsoft Information SecurityAntiXSS Library v4.0).

How much safer does the library make you? The answer is probably “not much”—ASP.NET’s default protection is pretty good. However, AntiXSS uses a “whitelist” approach to preventing attacks (encoding every character that isn’t on a list of allowed characters) rather than ASP.NET’s default provider’s “blacklist” approach (encoding only those characters on a blacklist of ‘dangerous’ characters). This brings your site in line with the guidelines published by Open Web Application Security Project.

There are a number of ways to using the WPL. The most labour intensive way is to use the methods on the Encoder class to encode any HTML (or, really, any text) that you send to the browser. The easiest way is to make it the WPL Encoder class the default encoder for your site. If you wait for version 4.1 (currently in beta) the library will include a class that you can use as your site’s encoder. If you can’t wait, you can create an encoder—provided that you’re working with an ASP.NET application project (rather than an ASP.NET website project).

First, create a class that inherits from System.Web.Util.HttpEncoder. Then override each of the methods in the class with code that uses the equivalent AntiXSS method. Where there isn’t an equivalent AntiXSS method, use the method from the base class. Your code will look something like this:

Public Class PHVXSS
    Inherits System.Web.Util.HttpEncoder

Protected Overrides Sub HtmlEncode(value As String,
output As System.IO.TextWriter)
End Sub

Protected Overrides Sub HtmlDecode(value As String,
output As System.IO.TextWriter)
 MyBase.HtmlDecode(value, output)
End Sub

Finally, add this entry to your web.config file inside the system.web element to have your site use your new class:

<httpRuntime encoderType=PHVXSS, assembly name/>

It’s the necessity of including the assembly name in the httpRuntime element that prevents you from using your class in an ASP.NET website project.

Of course, while protecting yourself against XSS is a good thing, it’s only part of what you need to do in order to fully protect your site. Not surprisingly, Learning Tree has several courses on securing your application, with each course focused on a different aspect of the problem. There’s a course on penetration testing, one focusing exclusively on Web security (since I’m primarily involved in creating ASP.NET sites, I really like that course), and another on wireless security. But it’s probably a good idea to find out how much trouble you’re in first. Of course, if you’ve discovered that you’re vulnerable because someone has already done damage to your site, you might find a course on disaster recovery most useful. I’m just saying.

Peter Vogel

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.