Apr 21, 2009

Eating your own dog food, or how do you really protect against XSS in ASP.NET?

There is a lot of literature that discusses ASP.NET and output encoding. There is even more literature discussing cross-site scripting (XSS) vulnerabilities and their exploitation. However, there is no particular literature that discusses how to fully solve the cross-site scripting problem in ASP.NET.

ASP.NET is built around a set of controls that the .NET framework transforms into HTML when outputting data to the browser. As any ASP.NET developer would agree, using these controls as well as any other functionality that is provided by the .NET framework makes the development of new applications a joy rather than a burden. However, as part of their functionality, some ASP.NET controls call the HttpUtility.HtmlEncode method to encode parts of their output (see this reference table). What is the problem with this? The HtmlEncode function uses a black-list approach to solve this encoding problem. It searches for the <, >, &, and " characters and replaces them with their HTML equivalents. The security problem with this approach is that if HTML specifications change, applications relying on this method might become vulnerable to script injection attacks. As proven in the past, most solutions that rely on such approach (e.g. WAFs, ASP.NET request validation) get bypassed at some point by some determined attacker.

To address this problem, Microsoft tries to give more momentum to its AntiXSS library, which uses a white-list approach... that is only known good characters (namely alpha-numeric) are left as is and everything else is encoded. The AntiXSS is also the recommended approach to use for encoding output by the Microsoft SDL methodology as it provides a longer lasting solution to the script injection problem. This, however, comes with a cost -- not all ASP.NET controls can work with the AntiXSS library. If a developer tries to use the AntiXSS library, he/she might run into the issue of double encoding output. If that developer does not use the AntiXSS library, his/her code might be become insecure.

IMHO, the best way to address this problem is to allow developers to override the encoding routines within the ASP.NET controls. This way the .NET framework will give developers more control over what is encoded and how it is encoded.

No comments: