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 Security\AntiXSS 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)
 output.Write(Microsoft.Security.Application.Encoder.HtmlEncode(value))
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

1 Response to “Prevent Cross-Site Scripting Attacks with Microsoft’s AntiXSS”


  1. 1 eksith February 14, 2012 at 12:53 am

    WPL is now at version 4.2 and unfortunately there are already people abandoning it because the pattern matching is far too aggressive making WYSIWYG use impractical.

    The only safe way to deal with XSS is to not only go with a whitelist, but to strip all non language special characters when unnecessary.

    90% of everything WPL does can also be accomplished using HtmlAgilityPack and a small helper class with a whitelist for tags and associated attributes. The few remaining allowed attributes can then be HtmlEncoded as necessary.

    Security is always a balance between practicality and functionality.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




Learning Tree International

.NET & Visual Studio Courses

Learning Tree offers over 210 IT training and Management courses, including a full curriculum of .NET training courses.

Free White Papers

Questions on current IT or Management topics? Access our Complete Online Resource Library of over 65 White Papers, Articles and Podcasts

Enter your email address to subscribe to this blog and receive notifications of new posts by e-mail.

Join 27 other followers

Follow Learning Tree on Twitter

Archives

Do you need a customized .NET training solution delivered at your facility?

Last year Learning Tree held nearly 2,500 on-site training events worldwide. To find out more about hosting one at your location, click here for a free consultation.
Live, online training

Follow

Get every new post delivered to your Inbox.

Join 27 other followers

%d bloggers like this: