XSS (Part 3) - XSS defences grow up.

My previous posts laid out the technical solution to XSS but raised the issue that knowing the technical solution isn't enough to remove the XSS vulnerabilities in your application.  The purpose of this post is to sound out some ideas on a systematic approach to mitigating XSS.

When it comes to integrating security into a larger business process we fortunately have some prior art to draw on, namely the several Security Development Lifecycle frameworks that exist today, such as Microsoft's SDL, BSIMM, etc.  These frameworks take an approach to security whereby they attempt to lay out a strategy and well defined goals that can be integrated into you software development process.  Some of them also use an optimised or maturity model so that security can be integrated in stages rather than trying to shift the mountain that is your 'current practice' all in one go.

I really like this approach.  I think this approach can be applied to mitigating threats as well.  Even better, I'm going to give it a catchy name, a Mitigation Maturity Model (MMM).  Alliteration fans go wild.

The reason why I think a maturity approach works well for mitigations (admittedly not all of them), is that it is a business reality that the ideal technical solution cannot magically be applied to any large application.

To make this more concrete I have come up with an XSS MMM.

1. (None) - No specific mitigation.  Input validation may prevent some XSS.
2. (Basic) - Manual mitigation.  Specific output encoding is being applied on a 'best efforts' basis.  Developers have been trained in the problem and the solution and perhaps an encoding library has been developed to simplify the process.  There is no testing for XSS.
3. (Intermediate) - Automate mitigation.  Automatic contextual output encoding is being done based on a 'best effort' at detecting where code/data is being written to HTML/JS/CSS.  There are likely some exceptions to this in certain places where the complexity makes automating the process difficult, but most pages get the benefit.  Developers receive mandatory training on the dangers.  Testing is focused on those areas that do not get autmated encoding.
4. (Advanced) -  Mitigation by design.  Rigerous automated contextual output encoding is applied,  made possible by the complete separation of HTML from JS from CSS.  A handful of exceptions exist but these are rigerously tested.

As much as it pains me to say it, the security community could probably come up with a better XSS MMM than I have.  To be honest I hope they do.  There are some purposeful omissions as well, things like penetration testing haven't been explicitly called out since that should be part of a larger framework.  I have also been vague from a technical point of view and focused more on the 'what' needs to be done than the 'how' you would actually do it.  The reason for that is simply that there is unlikely one solution at each maturity level that would suit everyone.  However, in my next post I hope to provide some concrete technical solutions at each maturity level that would hopefully be applicable to many situations.

I also believe that the MMM can actually be applied separately to existing code and new code; they needn't be at the same level.  It makes sense that new code should aim to be at a higher maturity level than existing code.  The effort to mature exsiting code can be considerable, and it's always going to be a business decision to spend time refactoring old code.

Finally, one last parting shot at the XSS mitigation advice out on the Internet today.  If we look at the XSS MMM as I have laid it out, at what maturity level would the standard advice of contextual output encoding sit?  Basic.  It's no wonder then that XSS is still such a massive problem on the Internet if that is the maturity level of the advice the security community is offering.