Sanitize HTML before storing in the DB or before rendering? (AntiXSS library in ASP.NET)

Question

I have an editor that lets users add HTML that is stored in the database and rendered on a web page. Since this is untrusted input, I plan to use Microsoft.Security.Application.AntiXsSS.GetSafeHtmlFragment to sanitize the HTML.

• Should I santiize before saving to the database or before rendering the untrusted input into the webpage?
• Is there an advantage in including the AntiXSS source code in my project instead of just the DLL? (Maybe I can customize the white list?)
• Which class file should I look in for actual implementation of the GetSafeHtmlFragment

Answer 1

• Both
• Only if you plan on changing it, which I would not do personally
• The AntiXss class (since it's called as AntiXss.GetSafeHtmlFragment())

Answer 2

You can use the in the page directive the parameter ValidateRequest="true". In this way all the Request data is validated and if there's a validation problem you can always catch the error. It also prevents sql injection threads and others not only possible XSS.

With numeric data, you can validate integer overflow or misuse of data types with Int32.TryParse() or any other of the TryParse family (Byte.TryParse Int16.TryParse...)

No need to use any other class or additional sanitizer method.

Answer 3

I disagree with the selected answer for two reasons

1. If you stored encoded data, you have to pick an encoder before you store. What happens if you have stored something as HTML but also want to push it out in another format, for example as a JSON response, or as part of an XML document? You now have a an HTML encoded format you must decode, then encode in the correct format.
2. What if we discover a bug in the encoders and push a new version out? Now, because you're not encoding at the point of output all your old data may contain things that have been incorrectly encoded. You can encode again, but then you hit double encoding issues which can be painful to filter correctly.

Generally you encode at the point of output and treat any data coming from a data store as untrusted by default - after all, what if someone manages to edit your database directly or via SQL injection?

Answer 4

Have a listen to the OWASP podcast 67 with Jeff Williams on XSS. He talks about not sanitising or encoding before storage. The primary reason is that if (when) libraries evolve in response to new vulnerabilities your data is going to be stuck back in the old version. Of course this doesn’t stop you from running any input against a whitelist at the entry point and rejecting anything outside acceptable range.