EPiServer and Microsoft Anti-Cross Site Scripting 3.0

XSS can be a pain, and trying to keep up with every single new exploit is pretty much impossible if you suppose to do anything else. So, I thought using Microsoft Anti-Cross Site Scripting library would be “good enough” for me.

After reading a few pages about the library, mostly on MSDN, I downloaded the binary package and installed it. I started to play around with the different encoding methods in the library, as described on this page (which is a bit old…): http://msdn.microsoft.com/en-us/library/aa973813.aspx

The next step was to use the AntiXssModule. It seemed to be a great idea to just install a module and specify the webcontrols and properties in a configuration file, instead of use a encode method on every single page. So, I put the module in Web.Config like this:

<httpModules>
<add name="AntiXssModule" type="Microsoft.Security.Application.SecurityRuntimeEngine.AntiXssModule"/>
<httpModules>

<system.webServer>
<modules>
<add name="AntiXssModule" type="Microsoft.Security.Application.SecurityRuntimeEngine.AntiXssModule"/>
</modules>
</system.webServer>

AntiXssModule uses a configuration file, which is supposed to be in the root folder. The filename must be antixssmodule.config. I started out with a small and simple file:

<?xml version="1.0" encoding="utf-8" ?>
<Configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<ControlEncodingContexts>
<ControlEncodingContext FullClassName="System.Web.UI.WebControls.Label" PropertyName="Text" EncodingContext="Html" />
</ControlEncodingContexts>
<DoubleEncodingFilter Enabled="true" />
<EncodeDerivedControls Enabled="true" />
<MarkAntiXssOutput Enabled="false" Color="Yellow"/>
</Configuration>

This should HtmlEncode all content for all labels. Said and done, I opened up a template page and put in a label like this:

<asp:label runat=”server” text=”<script>alert(‘XSS’)</script>” />

Time for testing! I opened up the page in my browser and what happens? An alert box pops up in my face! This is not how it was supposed to be. Back to the drawing board.

After looking at all configuration and installation objects, I figured it must be something else… but what? I gave up a few times, but I decided to download the modules source to see if I could spot something there. After I while I found the LoadConfig method, which told me the configuration should be stored in Application[“AntiXssModuleConfig”], but it was empty on my site.

One condition for load the configuration is context.Application.Count <= 0. Hmm… a quick test told me that this value seems to be set to 1 on a newly installed, clean EPiServer installation. I was sure this would solve the problem for me. After removing the condition (this may affect the security in some way I don’t know about) and recompiling the code, I replaced the assemblies on my site and gave it a shot. YES!! No alert box this time.

As happy as I was I decided to copy the full antixssmodule.config file from the Codeplex site in order to make it as safe as I could. You can find all files at http://antixss.codeplex.com/

When this was done, the next step would be adding a property to my template to store my “evil code”. Time to fire up the admin mode, aahhh… the browser window was blank. A quick remove of the AntiXssModule and the UI work again. Why?

My first idea were to add <modules> and <httpModules> to the UI’s <location>-section in web.config and remove the module. I’m not sure why this didn’t work for me. But I couldn’t give up now… I had to figure out the reason for the UI to stop working. I turned out to be this line in antixssmodule.config:

<ControlEncodingContext FullClassName="System.Web.UI.WebControls.TableCell" PropertyName="Text" EncodingContext="Html" />

I removed the line and everything worked just fine.