preventing xss in .net OWASP guidelines

Question

I've read the OWASP guidelines regarding preventing XSS. The guidelines seem to only refer to having a whitelist and encoding output. However, this leaves open the problem with so called free text fields e.g. the text box im writing in to make this post.

Are there any preventative measures besides a black list (not desirable) that can be done server side when accepting free text fields.

From the OWASP guidelines i get the impression that xss should just be allowed to be stored in the database and just sanitise it when ever it is displayed to the front end. I am however, a bit uncomfortable with this. Or do i have it wrong, is there a better way?

Answer 1

i get the impression that xss should just be allowed to be stored in the database and just sanitise it when ever it is displayed to the front end

That is correct. Whichever anti-XSS encoding library/function you use to do the encoding will prevent the XSS attempt from working, by preventing the dodgy code being rendered as HTML when it is added to the page output.

You should not attempt to scrub the input before storing it for much the same reason that you do not maintain a black list - it is too easy to get it wrong, and either scrub too much, or not enough. If you are going to attempt to scrub the input, you better know what you are doing.

Answer 2

XSS is an output problem. You can't have one catch all encoding or input validation function that works for all xss. Even by converting an input string to their htmlentities, your application can still be vulnerable to xss in dom events as well as another of other vectors. Its hard to keep all of these rules straight. Make sure to test your code, there are free XSS scanners such as Sitewatch and Skipfish.

Storing HTML in the database isn't a vulnerability, but displaying it would be persistent XSS. Which is the worst form of xss. It is common to store the un-encoded version in the database because its makes the data consistent and better for text comparisons and matching. In SQL injection for MS-SQL you can stack queries so its possible to introduce an xss payload into the database. For instance select...; insert into comments (post)values('<script>alert(xss)</script>'). Don't trust your database.

Answer 3

I lead the OWASP Guide, and I have matured my view on this since the Guide 2.0 was written back in 2004/2005.

In my view, there's two phases you need to deal with:

Input validation - you should always avoid allowing the incursion of XSS vectors into your data if at all possible. I have Views™, but honestly, the best bet is to strongly type and length restrict as far as you can. There's no point in allowing boolean or integer variables to be stored as a text column. The residual risk will be text areas stored in text blobs, which should be obvious when coding the presentation layer, whatever that may be.

Output encoding - when the original Guide was written (2002), we were doing the Big 5, that's no longer true. You need to correctly output encode for the context, so if you're outputting to Ajax, you need to make it both JSON and JavaScript safe, as well as HTML safe.

There's a new version of the Guide in the works, OWASP Guide 2013. I will be making sure this is correctly updated.

Please log an issue on our project's Issues tracker, as you have a very valid concern:

Log an issue in the OWASP Guide 2013 issue tracker

The days of simply encoding for the big 5 are well and truly over. Particularly, as HTML is fairly unlikely to be the primary presentation layer going forward.

Andrew van der Stock, OWASP Guide 2.0 / 2013 Guide Lead.

Answer 4

So there are two things to note here.

Input validation on the way in is done to make sure the data is valid according to the domain, and this stops some attacks, but definitely not all.

Output encoding is done to make sure the data is not somehow parsed as HTML or javascript. So as described by Rook it is an output problem. You should see the OWASP XSS prevention cheat sheet which explains how to avoid XSS directly in the HTML page, and the OWASP DOM based XSS prevention cheat sheet to understand how to avoid XSS triggered by javascript reading and writing unsanitized or unencoded data.

As mentioned by Rook, do not fall for the temptation of encoding or scrubbing the data on the way in, unless of course it's invalid according to your domain. There really is no way to encode properly before the output, because that's when you know which context you are encoding for. Is it an HTML attribute, a javascript string, a javascript string in an HTML attribute etc.

And as mentioned by Rule#6 in the OWASP XSS prevention cheat sheet, if you want to allow some HTML user a white-list based engine like OWASP AntiSamy or HTMLPurifier.