Phil Haack has just blogged how to write an encoding provider for ASP.NET 4.0 which uses AntiXSS. He beat me to it – one of the reasons I’ve switched WPL to VS2010 is so I can include an assembly which does this in the next public release. Encoding providers will work for both ASP.NET 4.0 WebForms and MVC applications, but the HttpEncoder class only encodes HTML, HTML attributes, HTTP headers and URL and URL paths. If you’re using the JavaScript encoding bits you’ll still have to do that manually. The decoding functionality will be based down to the .NET framework as we don’t provide decoders.

This does mean there will now be four assemblies where there was once two, as I talked about on the team’s blog.

• AntiXSS will be returned to its own assembly, enabling you to use it in medium trust and is built against .NET 2.0. It will also be marked as AllowParitallyTrustedCallers.
• A new .NET 4.0 assembly will be available for you to use to switch the encoding used as Phil details.
• The HTML sanitization bits will be in a separate assembly which requires full trust because of its optimisations. This assembly also requires .NET 3.5.
• The SRE stays in its own assembly and requires .NET 3.5.

Such is the price of flexibility and multiple framework support.

I’ve noticed some people using AntiXSS and WPL interchangeably, so it may be worth explaining the distinctions. The original project was AntiXSS – a bunch of encoding functions which use a whitelist approach rather than a blacklist approach, which provides better security. AntiXSS also had a couple of extra encoding functions which the base framework doesn’t provide.

AntiXSS was great, but it didn’t help people who didn’t know they should be encoding. For the folks that did know they had to encode sometimes it’s hard to know which controls properties are encoded and which aren’t (Sascha Faust has a good list if you’re interested). Out of this realisation the Web Protection Library (WPL) was hatched (side note: my single executive decision was to try to get everyone to pronounce WPL as Whipple. That’s taken off *grin*). The WPL plugged itself into the ASP.NET pipeline and examined every control on every page, encoding correctly as needed, without any changes needed to the underlying source code – acting as another layer of a defense in depth strategy. WPL uses AntiXSS to do its encoding and so was rolled up into the WPL. Then more detection methods were added, the first being a SQL injection detection which takes each parameter and tries to build a valid SQL command from it – if that succeeds then it may be a SQL injection attempt. Again this works without any changes to your code, it’s just a validation step added to the ASP.NET pipeline, and because it uses the pipeline it will work with MVC applications as well.

So AntiXSS is an encoding library that is included in the Web Protection Library, but you don’t have to use the WPL to use AntiXSS, you can use AntiXSS manually as much as you like.

We have a list of new mitigations and detections we want to add, which we’ll make public soon so you can help us prioritise them