Secure ASP.NET
Stomp Out Cross-site Scripting Attacks
By Don Kiely
Long after its threats were first widely known, cross-site scripting remains a threat to Web applications. In case you aren t current on attack types, cross-site scripting lets an attacker inject scripting code into user inputs, which causes the script to execute whenever the data is displayed on a Web page. There are many variations, limited only by the creativity of the attackers.
Microsoft has long recognized the problem, providing white papers like How To: Prevent Cross-Site Scripting in ASP.NET and introducing the validateRequest attribute for sites and page attributes in ASP.NET 1.1. The latter was a breaking change, something that Microsoft introduced with only the most careful consideration so it is clear that they take the problem seriously.
Last week Microsoft released another tool in the cross-site scripting arsenal: version 1.5 of the Microsoft Anti-Cross Site Scripting Library. This new version goes well beyond the original version of the library, which had limited support for encoding. I wrote about it in my March 2006 Secure ASP.NET column, Better HTML and URL Encoding Functions.
Version 1.5 has turned the library into a real tool that you can use to proactively reduce your exposure to cross-site scripting threats. It expands the number of methods to those shown in the table below:
|
Encoding Method |
Encoding |
Excluded Characters |
|
HtmlEncode |
Input strings for use in HTML |
None |
|
HtmlAttributeEncode |
Input strings for use in HTML attributes |
Space |
|
JavaScriptEncode |
Input strings for use in JavaScript |
None |
|
UrlEncode |
Input strings for use in URLs |
Comma, Space |
|
VisualBasicScriptEncode |
Input strings for use in Visual Basic Script |
None |
|
XmlEncode |
Input strings for use in XML |
None |
|
XmlAttributeEncode |
Input strings for use in XML attributes |
Space |
The library works by defining a set of valid characters and encoding everything else. Here are the characters it considers safe (not all methods exclude all the characters; see the table above for exclusions):
a-z A-Z 0-9 , . - _ (space)
This is a rather harsh technique, called the principle of inclusions, because it is sometimes hard to see the danger in some other characters. Nonetheless, it was the right design decision because it severely limits the characters an attacker can use. The System.Web.HttpUtility.HtmlEncode and other encoding methods in that namespace exclude unsafe characters, or at least the ones known to be unsafe. That is a different approach, one that encodes fewer characters but leaves it open to new, innovative scripting attacks.
I was pleased to find that the library is decorated with the AllowPartiallyTrustedCallersAttribute, meaning that it is callable from partially trusted applications. The assembly also has the SecurityTransparentAttribute, which tells the CLR that the code cannot cause an elevation of privilege.
You have to be careful to not encode data more than once. Because of the way that it encodes data, you ll end up with gibberish.
The library is usable with version 1.1 and 2.0 applications, running on Windows 2000, XP, 2003, and Vista. (There is no mention of Vista in the documentation, but Microsoft has confirmed that it works on Vista, as well.)
The only downside to the library is that it isn t built into the .NET Framework. Being a part of the framework would dramatically increase the convenience of the library, but, more importantly, it would make possible server controls with built-in cross-site scripting prevention. Microsoft promises such controls in a future version of the library. For now you ll either need to write code to call the library s methods or derive enhanced versions of the server controls that take user input. That s a small price to pay for the security benefits.
Get information about the library and download it at http://msdn2.microsoft.com/en-us/security/aa973814.aspx.
Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications as well as providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office. He writes regularly for several trade journals, and trains developers in database and .NET technologies. You can reach Don at mailto:[email protected] and read his blog at http://www.sqljunkies.com/weblog/donkiely/.
