Preventing XSS exploits using the type system as Joel suggested

Question

In Podcast 58 (about 20 minutes in), Jeff complains about the problems of HTML.Encode() and Joel talks about using the type system to have ordinary strings and HTMLStrings:

• A brief political rant about the evil of view engines that fail to HTML encode by default. The problem with this design choice is that it is not “safe by default”, which is always the wrong choice for a framework or API. Forget to encode some bit of user-entered data in one single stinking place in your web app, and you will be totally owned with XSS. Believe it. I know because it’s happened to us. Multiple times!

• Joel maintains that, with a strongly-typed language and the right framework, it’s possible (in theory) to completely eliminate XSS — this would require using a specific data type, a type that is your only way to send data to the browser. That data type would be validated at compile time.

The comments at the blog post mention using static analysis to find potential weaknesses. The transcript Wiki isn't done yet.

Is it possible to implement Joel's suggestion without having a new ASP.NET framework?

Might it be possible to implement it simply by subclassing every control and enforcing new interfaces based on HTMLString? If most people already subclass controls in order to better able to inject site-specific functionality, wouldn't this be fairly easy to implement?

Would it be worth doing this instead of investing in static analysis?

Answer 1

To use HtmlString everywhere, you would essentially have to rewrite every property and method of every web control. System.String is sealed, so you can't subclass it.

An easier (but still very time consuming) approach would be to use control adapters to replace web controls with safe alternatives. In this case, you would subclass each web control and override the Render methods to HTML-encode dynamic content.