So this is my last post in my series on XSS and I hope to follow up on my previous 3 posts by offering more detail on how you might implement a solution to XSS by progressing through the stages of the XSS Mitigation Maturity Model (MMM).
There isn't much point in offering any advice for the None and Basic levels; there is nothing to do for the None level, and the Basic level is what people currently do if they follow the advice online.
The purpose of the Intermediate level is to automate output encoding. The reason this is an advantage over the Basic level is it takes the burden off of developers to manually apply (the correct) output encoding everywhere in the application. Relying on developers to do this perfectly is unreasonably and to be honest not really where you want them focusing their efforts.
If you are fortunate you may be using a web development framework that offers automated contextual output encoding, however I am not familiar with enough different frameworks to know how broadly supported such a capability is; I'm going to assume not very. Implementing this yourself involves extending your framework that writes data and code to web pages to understand the context of where the data or code is being written. Typically this will have mixed results, it will work well for simple pages, but not so well for complex pages or pages where a combination of data and code is written simultaneously. This limitation is acceptable though as we can use it to isolate those areas where we cannot use automated contextual output encoding and make those areas the focus of XSS testing. For testing purposes your security team should be able to come up with a suitable range of tests or tools that test for basic XSS attack vectors.
Whereas the Intermediate maturity level can be applied to existing code with a manageable amount of effort, the Advanced maturity level implies creating a web page that is designed to be secure against XSS. It's important to understand that the design of a web page should never just be about mitigating XSS, that wouldn't be very practical, but we can design pages so that speed, size and functionality are not the only considerations; we also consider security.
At the beginning of my first post in this series I talked about FireFox 4 as offering exciting new defenses against XSS, I was referring to it implementing the Content Security Policy (CSP) proposed standard. The CSP allows a browser to restrict the scripts that run in the page to a white list provided by the server (as an HTTP header).
As with the Intermediate level, any exceptions to designing security into a web page need to rigorously tested.
So there you have it. It wasn't that painful was it? Clearly I have only touched upon the topics involved and you would have to do some research yourself in order to flesh out a detailed technical solution at each maturity level. But hopefully this post has given you some ideas about where to start.