Microsoft AntiXSS Library

Cross site scripting (XSS) is the most common web application vulnerability and is listed in the Top 10 web application vulnerabilities on OWASP. XSS can also be called HTML injection attack, it occurs when un-validated user input is inserted into HTML output. This allows the attacker to construct a URL with HTML input and get it executed on the browser in the user’s context. This attack can be used to extract cookie information, steal sessions, write new html tags, invoke ActiveX controls, etc. Essentially, anything that can be done with a browser can be done with this attack without the user’s knowledge.

Microsoft recently released the v3.0 beta for AntiXSS library which helps you to protect your current applications from cross-site scripting attacks, at the same time helping you to protect your legacy application with its Security Runtime Engine. The Microsoft Anti-Cross Site Scripting Library is an encoding library, provided by the ASP.NET and Application Consulting & Engineering (ACE) teams at Microsoft, designed to help developers protect their Web-based applications from XSS attacks.

AntiXSS 3.0 is a powerful tool in the Microsoft toolbox that mitigates XSS risks and provides a consistent level of security allowing you to focus on solving business problems and not on security problems.

Whats new in AntiXSS 3.0:

• Improved Performance – AntiXSS 3.0 has been completely rewritten with performance in mind, and yet retains the fundamental protection from XSS attacks that you have come to rely on for your applications
• Secure Globalization – The web is a global market place, and cross-site scripting is a global issue. An attack can be coded anywhere, and Anti-XSS 3.0 now protects against XSS attacks coded in dozens of languages
• Standards Compliance – AntiXSS 3.0 is written to comply with modern web standards. You can protect your web application without adversely affecting its UI

This library differs from most encoding libraries in that it uses the principle-of-inclusions technique to provide protection against XSS attacks. This approach works by defining a valid or allowed set of characters, treating anything outside this set as invalid characters or potential attacks and encoding it.

Cross-site scripting (XSS) attacks exploit vulnerabilities in Web-based applications that fail to properly validate and/or encode input that is embedded in response data. Malicious users can then inject client-side script into response data causing the unsuspecting user’s browser to execute the script code. The script code will appear to have originated from a trusted site and may be able to bypass browser protection mechanisms such as security zones.

These attacks are platform and browser independent, and can allow malicious users to perform undesired actions such as gaining unauthorized access to client data like cookies or hijacking sessions entirely.

In order for a malicious user to conduct an XSS attack against the application, they first need to find a page where all of the following are true:

• The application is not validating input
• The application is not encoding output that contains untrusted inputs

A malicious user can easily exploit this by tricking a user into visiting the page while passing script such as <script>alert(‘Virus Alert!’)</script> into one of the parameters. The script injected by the malicious user gets executed in the unsuspecting user’s Web browser.

To protect our application from XSS attacks we first need to understand the methods that malicious users can use to conduct such attacks. We can do using the following steps:

1. Review ASP.NET code that generates output

   Remember that in order for an XSS attack to succeed, malicious users must find a way to embed their input as part of the response data from the application; therefore, we need to identify code in the application that generates output. This might not always be an easy task, especially for large applications, and some output may not necessarily require encoding.

2. Determine if output could contain untrusted input

   Any of the output identified in the previous step could contain untrusted user inputt; if you’re unsure if the output contains untrusted input, err on the side of caution and assume it does.

3. Determine encoding method to use

   Understand which encoding method we need to use to encode our web response data. Output will require encoding if all of the following conditions are true:

   • Input is not trusted
   • Output contains untrusted input
   • Output is used in a web response data context

   Following will be helpful in determining which encoding method to use:

   HtmlEncode – Untrusted input is used in HTML output except when assigning to an HTML attribute
   <a href="http://dotnethitman.spaces.live.com">Click Here [Untrusted input]</a>

   HtmlAttributeEncode – Untrusted input is used as an HTML attribute
   <hr size=[Untrusted input]>

   JavaScriptEncode – Untrusted input is used within a JavaScript context
   <script type="text/javascript">
   …
   [Untrusted input]
   …
   </script>

   UrlEncode – Untrusted input is used in a URL (such as a value in a querystring)
   <a href="Click">http://search.msn.com/results.aspx?q=[Untrusted-input]">Click Here!</a>

   VisualBasicScriptEncode – Untrusted input is used within a Visual Basic Script context
   <script type="text/vbscript" language="vbscript">
   …
   [Untrusted input]
   …
   </script>

   XmlEncode – Untrusted input is used in XML output, except when assigning to an XML attribute
   <xml_tag>[Untrusted input]</xml_tag>

   XmlAttributeEncode – Untrusted input is used as an XML attribute
   <xml_tag attribute=[Untrusted input]>Some Text</xml_tag>

4. Encode output

   Now that we’ve determined which scenarios require encoding, all that’s left to do is add the Microsoft Anti-Cross Site Scripting Library to our project and encode the untrusted input as it is embedded in response data.

   After you’ve installed the Microsoft Anti-Cross Site Scripting Library, you can add the reference to the library in your ASP.NET using the following steps:

   1. Right-click the project name
   2. Select Add Reference … option
   3. Under Browse, look in the library installation directory and add the reference to AntiXSSlibrary.dll

   After we’ve added the reference to the Anti-Cross Site Scripting Library, we encode the output generated by the our page. To do this:

   1. Add the directive using Microsoft.Security.Application
   2. In the output method encode using one of the encoding methods:
      AntiXss.HtmlEncode(Request.QueryString["SomeParam"]);
   3. Rebuild the Web application

Additional Steps

To make malicious users’ jobs even harder, there are some additional layers of defense that can be implemented to further prevent XSS attacks in the our application.

• Set the ASP.NET validateRequest attribute to true:
  <%@ Page Language="C#" AutoEventWireup="true" CodeFile="PreventXSS.aspx.cs" Inherits="PreventXSS" validateRequest="true" %>
• Perform input validation on all inputs to the application.
  see How To: Use Regular Expressions to Constrain Input in ASP.NET
  and Validation Application Block and ASP.NET

Conclusion

XSS attacks are easily one of the most common encountered by IT teams, and with the number of Web applications increasing each day, that number is expected to continue growing. Developers need to protect their application users from such attacks by:

• Validating and constraining input
• Encoding output

NOTE: remember, a common mistake is to encode untrusted input more than once, which can result in outputs being displayed incorrectly.

For more information on XSS attacks, some good references are:

• Microsoft Patterns & Practices
• Wikipedia.com