Steve is the man, check this out: http://blog.stevensanderson.com/2007/12/19/aspnet-mvc-prevent-xss-with-automatic-html-encoding/
His technique of hooking the compilation step is absolutely brilliant
If you look at the code:
- He creates a class (SafeEncodingCSharpCodeProvider) that implements CSharpCodeProvider
- in there he overrides GenerateCodeFromStatement(System.CodeDom.CodeStatement statement, TextWriter writer, CodeGeneratorOptions options)
- then finds a CodeMethodInvokeExpression that is a Write
- and wraps the parameter in a call to SafeEncodingHelper.SafeEncodingCSharpCodeProvider.EncodeHtmlIfNeeded
This is a massive step on the right direction, but there are a couple things that we should also take into account:
- encoding is done with the HttpUtility.HtmlAttributeEncode which is not as sounds as the AntiXSSLibrary (note how he added an extra patch to encode ' )
I also like the ability to change the framework the developer is coding on top, and make it secure by-default. This is another example of making security invisible since it allow us to add security in a way that it is invisible/transparent to developers. In that worlds, the devs only need to care about security when they are doing security-sensitive actions (which must still be supported, but should be the exception, not the norm).
One interesting question is where we want to do this change as a hardcoded compiler step (Steve's example), or do it directly on the code before it is compiled (as I show in the Fixing/Encoding .NET code in real time (in this case Response.Write) example)?