Should I use AntiXSS or OWASP's ESAPI.NET?

Feb 23, 2012 at 1:52 AM

OWASP has a .NET compatible anti XSS tool available here: https://www.owasp.org/index.php/ESAPI_DotNET_Readme

Should I use that, or this download from Microsoft?

Should I use both together?

Feb 23, 2012 at 4:29 AM

Using both is a terrible idea. More security isn't better security. Better security is better security.

You really should read a few threads in this forum before asking whether you should download this. The answer will become very clear.

Feb 23, 2012 at 4:38 AM

@eksith - Which one are you referring to that I should download?  Based on your recent comments you seem disappointed in the recent version of AntiXSS... but yet you are posting heavily on this site.  I'm guessing you are/were a fan of AntiXSS but based on the recent bug you're very disappointed in your recent rollout.  

Feb 23, 2012 at 3:21 PM
Edited Feb 23, 2012 at 3: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

edit_

I'm only using it to sanitize attributes and <code> blocks. But you can again strip these out or use HtmlEncode.

Feb 23, 2012 at 6:22 PM

Ahh I see this post now...

I'm still trying to work out the criteria for selecting an XSS framework, choosing when to use it and where to use it.  

* Usage (within Javascript, HTML attributes, HTML blobs, etc)

* Updates

* Technical vetting (it does the right job for the right purpose)

* Community Support

* Implementation (does it apply to the entire site)

* other factors

I wasn't aware that AntiXSS applied itself transparently to the whole site.  I want to make sure it works with my CSRF token, and other data such as file upload.  I also wonder how it will interact with HTTP handlers and the like.

I'm looking for a long term solution based on history and track record.  I may use your technique as a short term fix until the official one is released.

Feb 23, 2012 at 6:39 PM
Edited Feb 23, 2012 at 6:40 PM

When to use...

Any time you're using input from GET or POST in your handlers. This depends on whether you have vanilla ASP.Net or MVC et al or something custom. For me, I had an MVC requirement, so any time the code handles any sort of user input, it would get filtered first. I'm also writing a simple discussion forum as small side project and there's an InputUtility class where this is taken care of along side HtmlUtility linked above.

Where to use...

You can easily build a wrapper around that plus the HtmlUtility class and use as an input handler or just call the raw classes. I.E. MyObj.UserBio = HtmlUtility.Sanitize(collection["UserBio"]); or something similar. Together, they take care of my input validation needs. This isn't terribly sexy, but it works when you need things done yesterday.

Community support...

HtmlAgilityPack has a very strong community support base so you won't be hanging in the breeze like over here and there are dozens of examples for almost every scenario you can imagine where user input is handled and you need to clean just enough or all of it. Any wrapper or helper classes you write on your own will be simple as possible so you won't really need support for your own work.

If you really need something to apply to the entire site and you're using MVC, it's very easy to override the default encoder and build yourself a wrapper. Instead of AntiXss, just roll out your own using the above examples.

Coordinator
Feb 23, 2012 at 7:03 PM

@clamont : I wasn't aware that AntiXSS applied itself transparently to the whole site.

It doesn't.

Feb 23, 2012 at 8:53 PM
Edited Feb 23, 2012 at 8:55 PM

@bdorrans I see.. I read *every* discussion was confused between the SRE and AntiXSS.  As a newcomer, some of the terms, product changes, and lack of documentation confused me.  I understand the SRE is in CTP and only available in code form prior to version 4.x.  It also doesn't work with MVC / Azure.  

AntiXss seems like a very good library, but it has a unique feature that causes a lot of bugs, namely GetSafeHTML.  I read that this comes from the Exchange team.  Since they make OWA, we get a refresh of what's available from Exchange 2010?  I believe SP2 has some unique features in it for HTML.  Perhaps then it will be less of a "black box" (as referred to in an older post 2 years ago)

And as a final alternative, what are your thoughts on this approach for cleaning HTML http://wpl.codeplex.com/discussions/74660 

Coordinator
Feb 24, 2012 at 2:46 PM

@clamont - Yes, the confusion does exist. You're right it's still in beta, mainly because folks reports bugs with webforms apps, but never give me repros :) I don't feel comfortable releasing if there are bugs that people are seeing. The SRE automatic encoding won't ever work with MVC, because of the way MVC works - plus, as it encodes by default it's kind of meaningless.

You're right that the sanitizer is tainting the encoding libraries by association. We've been talking to the exchange team, and we're talking to the ASP.NET team about different approachs and to make it more supportable, but those discussions are still ongoing.

As for using schema validation that becomes hard with HTML as we'd need a full SMGL validator, not just an XML one. And once it validates we still need to parse and strip, and the parsing is the hard part. eksith's idea of using the HTML Agility Pack is a good one though.