SQL Injection MMM

So I introduced the concept of a Mitigation Maturity Model (MMM) in a previous post, and I created a model for Cross-Site Scripting.  In this post I would like to do the same thing for SQL Injection.

SQL Injection is both an easy and difficult attack to create a maturity model for; on the one hand the mitigations for SQL Injection are well known, on the other hand to rank them is less straight-forward.  Nevertheless, let's have a go:

1. None.  No protection.  Some protection from input validation but no effort to specifically protect against SQL Injection.
2. Basic.  Strip SQL syntax characters.  Depending on the string delimiter being used for SQL, either single or double-quote characters are stripped.
3. Intermediate.  Parameterised Queries (a.k.a. Prepared Statements).  All SQL commands are made using parameterized queries.  Any stored procedures are rigorously reviewed for potential SQL Injection flaws.
4. Advanced.  Object-Relational Mappings (ORM).  All SQL commands are replaced with ORM calls.  Any stored procedures are rigorously reviewed for potential SQL Injection flaws.

So the model I have provided here contains no surprises, but I think I have to justify why I think ORM is a more mature mitigation than a parameterized query.  I actually think both are perfectly valid mitigations in their own right, and I struggled to decide if I should choose one as more mature than the other.  In the end what tipped ORM as a more mature mitigation was simply that parameterized queries still take a string (the SQL query with placeholders), and short of reviewing all these strings, there is no way to know if that string was dynamically constructed.  For this reason I believe you can have more confidence in ORM, since there is no way for a developer to abuse it (short of using direct queries in the ORM API, but these can easily be audited).  I doubt everyone will agree with my logic on this, but I think it's a reasonable argument.

So SQL Injection is probably one of the easier attacks to put in a MMM since the mitigations are so well understood.  The real test of how useful the idea of a MMM will be is determining if it can be applied to the majority of high-risk attacks applications must face.

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.