3 Ways to Prevent XSS vulnerabilities in ASP.NET web applications

May 14th, 2008 | security, technology

Cross Site Scripting (XSS) vulnerability is one of the most prevalent security issue today. Prevention of XSS is pretty straightforward if you know the different options available to you. Let’s look at 3 easy options when using the .NET framework.

.NET "ValidateRequest" Approach
Microsoft introduced ValidateRequest in .NET 1.1. The idea is that the framework checks incoming requests for any constructs indicative of Cross Site Scripting issues. If any problems are found, an error is raised and the request does not even get to the web application. The directive can be placed in Machine.config, web.config or at the page level. This option is turned on by default in ASP.NET.
Microsoft has made it clear that you should not rely ONLY on this method:

Do not rely on ASP.NET request validation. Treat it as an extra precautionary measure in addition to your own input validation.

It is clear why Microsoft adds the precaution. This is a blacklist based approach and every blacklist has limitations. In addition, if there is a business need to use constructs that are blacklisted by validateRequest (e.g., Ajax apps that send xml back and forth), you may need to turn off this feature.
Lets check what validateRequest does by cracking open the relevant dll’s.

.NET Framework 1.1 does the following checks as seen from the disassembly:

Reading through the code, we see that the following items are checked - expression strings, JavaScript script and OnXXX handlers, ‘<’ followed by alpha characters and "&#". It is a decent list that
catches most common XSS vectors.

.NET Framework 2.0 does the following checks as seen from the disassembly:

In this case, the following items are checked - ‘<’ followed by alpha characters and "&#".
It appears that MS decided to dumb down request validation when .NET framework went from 1.1 to 2.0.
An important point to remember about "validateRequest" is that these protections are given to only certain parts of the request. Query Strings, Form variables and Cookies are protected. Header values, Server Variables, viewstate, information inside multi-part forms (e.g., file upload) are not validated.

From a developer’s perspective, the usefulness of this class is limited by the fact that it cannot be overridden or extended.
Anti-XSS Library
The Anti-XSS library is an exhaustive blacklist. The following screenshot shows all function calls in the library (ver 1.5).
As seen in the disassembly above, the coverage of Anti-XSS library is quite good as it looks at JavaScript, VbScript, XML. Being a public class, it is possible to extend and override methods to suit your application needs.Use of this library entails downloading the latest dll and adding a reference to your web application project.
Output Encoding
This method involves the use of HttpUtility.HtmlEncode() call whenever you send information to the presentation layer. This process is not as automatic as the first two methods because the developer has to be more aware of where they are displaying data.

0 comments ↓

There are no comments yet...Kick things off by filling out the form below.

Leave a Comment