Stomp Out Cross-site Scripting Attacks

Secure ASP.NET

Stomp Out Cross-site Scripting Attacks

By Don Kiely

Long after its threats were first widely known, cross-sitescripting remains a threat to Web applications. In case you aren t current onattack types, cross-site scripting lets an attacker inject scripting code intouser inputs, which causes the script to execute whenever the data is displayedon a Web page. There are many variations, limited only by the creativity of theattackers.

Microsoft has long recognized the problem, providing whitepapers like How To: Prevent Cross-Site Scriptingin ASP.NET and introducing the validateRequest attribute for sites and pageattributes in ASP.NET 1.1. The latter was a breaking change, something thatMicrosoft introduced with only the most careful consideration so it is clearthat they take the problem seriously.

Last week Microsoft released another tool in thecross-site scripting arsenal: version 1.5 of the Microsoft Anti-Cross SiteScripting Library. This new version goes well beyond the original version ofthe library, which had limited support for encoding. I wrote about it in my March2006 Secure ASP.NET column, Better HTML and URL Encoding Functions.

Version 1.5 has turned the library into a real tool thatyou can use to proactively reduce your exposure to cross-site scriptingthreats. It expands the number of methods to those shown in the table below:

The library works by defining a set of valid charactersand encoding everything else. Here are the characters it considers safe (notall 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 ofinclusions, because it is sometimes hard to see the danger in some othercharacters. Nonetheless, it was the right design decision because it severelylimits the characters an attacker can use. TheSystem.Web.HttpUtility.HtmlEncode and other encoding methods in that namespaceexclude unsafe characters, or at least the ones known to be unsafe. That is adifferent approach, one that encodes fewer characters but leaves it open tonew, innovative scripting attacks.

I was pleased to find that the library is decorated withthe AllowPartiallyTrustedCallersAttribute, meaning that it is callable frompartially trusted applications. The assembly also has theSecurityTransparentAttribute, which tells the CLR that the code cannot cause anelevation 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.0applications, running on Windows 2000, XP, 2003, and Vista.(There is no mention of Vista in the documentation, butMicrosoft has confirmed that it works on Vista, aswell.)

The only downside to the library is that it isn t builtinto the .NET Framework. Being a part of the framework would dramaticallyincrease the convenience of the library, but, more importantly, it would makepossible server controls with built-in cross-site scripting prevention.Microsoft promises such controls in a future version of the library. For nowyou ll either need to write code to call the library s methods or deriveenhanced versions of the server controls that take user input. That s a smallprice to pay for the security benefits.

Get information about the library and download it at http://msdn2.microsoft.com/en-us/security/aa973814.aspx.

DonKiely, MVP, MCSD, is a senior technology consultant, building customapplications 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 readhis blog at http://www.sqljunkies.com/weblog/donkiely/.