Exploring ASP.NET & Web Development
Fighting Cross-Site Scripting with Anti-Cross Site Scripting Library 3.0
By Don Kiely
One of the most insidious attacks on websites has long been cross-site scripting (XSS). Like other injection attacks, such as SQL injection, XSS is hard to defend against because it requires careful vigilance through the design and development of every page in a website. Get sloppy on just one page, and your entire site could be lost to an attacker. A good source of information about cross-site scripting is this Wikipedia page: http://en.wikipedia.org/wiki/Cross-site_scripting.
One of the best defenses against XSS is to carefully validate all untrusted inputs to the application from any source, including user input, databases, uploaded files, and any other inputs used in the site. Once you've done that, you can provide another strong layer of security by encoding all dynamic outputs that contain data from untrusted inputs. Encoding involves changing dangerous characters, such as angle brackets, to another form that can't be interpreted by a browser as command or control characters, such as their ASCII or Unicode forms.
ASP.NET 2.0 introduced the ValidateRequest attribute of the @Page directive. Set to true by default (a good default!), it causes the page to validate all input data against a blacklist of dangerous values. If it detects any of those dangerous values, the page throws an HttpRequestValidationException exception. This feature is fine as far as it goes, but is limited in that it checks only input for the current page and is fairly inflexible. It helps with input validation, which is only one part of a defense against XSS.
Back in 2006, Microsoft released the first version of its Anti-Cross Site Scripting Library, which I wrote about in asp.netNOW in the article "Stomp Out Cross-site Scripting Attacks," at http://portal.aspnetpro.com/newsletterarticle/2006/12/asp200612dk_l/asp200612dk_l.asp. The first version of the library was a huge improvement over the HtmlEncode and UrlEncode methods of the HttpServerUtility class in the System.Web namespace of the .NET Framework.
AntiXSS Library 3.0 Components
Microsoft recently released a beta of version 3.0 of what is now called the Anti-Cross Site Scripting Library (AntiXSS Library 3.0), a substantial upgrade of the library. It still uses whitelisting to allow a web page to display what the library deems to be safe characters, encoding all others. This uses what is commonly called the principal of inclusion. The library considers safe all lowercase and uppercase letters, all numbers, a space, period, comma, underscore, and hyphen. It also supports a lot of characters in non-English languages.
The latest version of the library consists of three components. First is the library, which has various methods you can use in code when dynamically outputting data on a web page. The method you use depends on how the data will be used in the page:
HtmlEncode: used in HTML output, other than HTML attributes
HtmlAttributeEncode: used in HTML attributes
JavaScriptEncode: used within JavaScript
VisualBasicScriptEncode: used within VBScript
UrlEncode: used in a URL, such as query string parameter
XmlEncode: used as XML tag content, other than attributes
XmlAttributeEncode: used as XML attribute content
You should use the library methods when you want control over how and when to encode page output.
The second component is the Security Runtime Engine (SRE). This is an HTTP module that you can use to automatically encode almost all at-risk output. 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 any other HTTP module and can configure its behavior and the controls it affects in a separate antixssmodule.config file. A ConfigGen.exe utility will generate the antixssmodule.config 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.
The third component of AntiXSS Library 3.0 is a test harness. This is a console application that automates validation and performance tests for the AntiXSS Library. It includes an XSS Validation Test Bench to show blocking of cross-site scripts and a Performance Test Bench to benchmark the performance of the HtmlEncoding method as compared to the .NET Framework's HttpUtility.HtmlEncode method. Clearly Microsoft included the latter test bench to counter criticism that protecting against XSS is too much of a performance drain.
There is a lot to learn about and like in this latest version of the AntiXSS Library. For the most part, I've found the features easy to learn and to implement. You'll need to know the basics of XSS in order to use the protection wisely without going overboard. The only thing that I don't like about the library is that it isn't built into ASP.NET and the .NET Framework, and there is no indication this will change in the upcoming version 4.0. Nevertheless, the AntiXSS Library is a worthy addition to any website where security is an issue. In other words, every website!
Don Kiely ([email protected]), MVP, MCSD, is a senior technology consultant, building custom applications and providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office.
