Robert Hurlbut Blog

Thoughts on Software Security, Software Architecture, Software Development, and Agility

Anti-Cross Site Scripting Library for .NET web applications

Thursday, February 23, 2006 Comments

 .NET  ASP.NET  Security  Web Services 
Share:   Share on LinkedIn    Share on Twitter    Share on Facebook   

I heard about this sometime ago, and now it looks like the Microsoft Anti-Cross Site Scripting Library V1.0 has been released [found by way of Jason Haley -- if you have no other RSS feed you subscribe to, get Jason's!]

Cross Site Scripting (XSS) is listed on the OWASP Top Ten list of the most critical web application security vulnerabilities at the #4 spot:

The web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user's session token, attack the local machine, or spoof content to fool the user.

More information can be found here: Information on Cross-Site Scripting Security Vulnerability. Also, Keith Brown did several labs recently that are posted on Channel 9; there is one on Cross Site Scripting as well.

The new .NET library from Microsoft indicates it is supported on Windows 2000, Windows XP, and Windows 2003, and can be used with .NET 1.0, .NET 1.1, and .NET 2.0. The library exposes these two methods: HtmlEncode and UrlEncode (taking a single string paramter). These are the same methods as found in the System.Web.HttpUtility namespace in the .NET Framework today.

Why is there a new set of functions? The standard .NET functions use what is called "black-listing" or implementing the "principle of exclusions". This means they look for specific characters to encode only (such as < (less than), > (greater than), & (ampersand), and " (double quote)). While this is good, certain other characters could slip through that could cause problems. The new library takes the opposite approach with a method called "white-listing" or implementing the "principle of inclusions". This means instead of looking for what's bad and filtering it out, the new methods now look for what's good and considers everything else as bad and replaces those characters with their escape character equivalents. I checked this directly through Reflector, and this is happening underneath. I am surprised this wasn't already done in the Framework, especially for .NET 2.0.

Here is a chart that shows what the new library considers "good" characters (from the documentation):

Method

Valid Characters Not Encoded

AntiXSSLibrary.HtmlEncode(string)

  • a-z (Lower case alphabetic)
  • A-Z (Upper case alphabetic)
  • 0-9 (Numbers)
  • , (Comma)
  • . (Period)
  • - (Dash)
  • _ (Underscore)
  •  (Space)

AntiXSSLibrary.UrlEncode(string)

  • a-z (Lower case alphabetic)
  • A-Z (Upper case alphabetic)
  • 0-9 (Numbers)
  • , (Comma)
  • . (Period)
  • - (Dash)
  • _ (Underscore)

If you are writing ASP.NET applications (with any of the .NET Framework versions), take a look at this as a more secure solution to guard against XSS.

Share:   Share on LinkedIn    Share on Twitter    Share on Facebook