Feb 23, 2012 at 4:21 PM
Edited Feb 23, 2012 at 4:29 PM
Let me clarify... using both together is a terrible idea. If OWASP works for you then only go for that.
As for AntiXss, "disappointed" is an understatement and "fan" is not applicable.
At work, the AntiXss library was selected for use against my objections since it would mean relying on a library that hasn't kept up the source releases to match the binaries. Considering WPL still doesn't have the new sources, my recommendation is
to avoid relying heavily AntiXss and instead use something like the HtmlAgilityPack alongside a helper class to strip out unwanted tags and attributes.
You get most of what AntiXss offers, but with far more access and the ability to change anything at will.
I've put together just such
an implementation (scroll to the bottom), but you do manually need to call HtmlUtility.SanitizeHtml on your input functions (which I think is a better way to do things anyway rather than universally applying filtering to all POST and GET
calls). In my example, I'm still using the older 4.0 library with the alleged vulnerability, but considering it's limited to attribute stripping, the attack surface has been substantially minimized if not completely eliminated.
You can avoid using AntiXss altogether by calling the base Encoder.HtmlEncode instead since I'm only using it to sanitze attributes
I'm only using it to sanitize attributes and <code> blocks. But you can again strip these out or use HtmlEncode.