Encoding. It's not just a good idea ... well, yeah, it's just a good idea.

Working in primarily ASP.NET for the last 13 years, I didn't think much about Cross Site Scripting. The AntiXSS tools in ASP.NET are best of breed. Even without any input encoding, it's really, really tough to get XSS vectors into an ASP.NET site - especially Web Forms.

ASP.NET isn't the only platform out there, as it turns out. In fact, so far as the open web goes, it isn't even close to the most popular. Ruby on Rails, PHP, and JSP still show up everywhere, and they are not, by default, protected from XSS. What's more, mmisconfigured ASP.NET sites are more, not less, common. 

With the power of today's browsers, XSS is more of a threat than ever. It used to be virtual spray paint; a method for defacing a site. Not it can be used to steal credentials, alter the functionality of a site, or even take over parts of the client computer. It's a big deal.

You can make it all go away by simply encoding your inputs and outputs. There are some simple rules to help make this happen.

First, never put untrusted data in a script, inside an HTML comment, in an attribute name, in a tag name or in styles. There is no effective way to protect those parts of a page,, so don't even start.

OK, now that we have that covered, sometimes you DO need to put untrusted data in an HTML document. If you are putting data into an HTML element, such as inside a div, use the HTML encoding that is built into your platform. In ASP.NET it is Server.HtmlEncode. Just do it. Build it into your web controls, whatever. Assume that the data coming in and going out is bad, and encode it.

That's for HTML content. How about the attributes? Width or color or whatnot? Attribute encoding. There is a good reference implementation in ESAPI.

If you need to put content into a trusted JavaScript element, say for instance the text of an Alert, then JavaScript encoding is what you want. Most platforms have unicode escaping - that's your best bet. In Ruby, just use .encode() to handle it. But handle it.

In general, the idea is this: different parts of HTML pages require a different encoding style. The canonical reference for this is the OWASP XSS Prevention Cheat Sheet. When you are looking at your user control library for that next project, or a current one, or an old one, whatever: take a look. Does it encode inputs? Does it encode them correctly?

Comments (1) -

  • mgroves
    ASP.NET MVC + Razor also makes it harder to put unencoded values in a view as well. Most of the MVC HTML helpers and plain Razor will just assume that you want to encode, so you'll actually have to use @Html.Raw if you want to avoid this.
Comments are closed