In my previous post I described a potential problem with web application firewalls protecting web applications. After getting your attention it is only fair to follow up with a solution.
Firstly, the problem is not as serious as it may appear at the first glance. Secondly, the solution, in the cases when the rules might be affected, is pretty straightforward. It's a simple matter of rewriting rules to avoid the slippery path (or not writing them to be vulnerable to evasion in the first place). You should have in mind, however, that the most important step in dealing with impedance mismatch is to understand the problem exists. Everything else is just a technicality.
It turns out the impedance mismatch problem typically affects only those rules that are designed to focus on named parameters and cookies. This is a feature that is not used frequently. For example, the Core Rules project does not need to do this because it is generic in nature. It does not care what parameters are called. What it really cares is the payload (either parameter names or values) and this is where inspection takes place - irrespective of impedance mismatch.
If you do need to address problems that manifest only with certain named parameters then it's probably because you want to deal with a particular problem in the application you are using. Which means you have a context in which you work and you can take simple precautions. You should always try to avoid using the named-variable approach (e.g. ARGS:parameter) and address all variables instead (i.e. ARGS). My favourite has always been having a rule that warns about parameters with strange characters in them (a space would be a strange parameter in this context).
SecRule ARGS_NAMES "!^[][a-zA-Z0-9_.]+$"
This rule will not work equally well for all environments. You should customise it to better suit your circumstances. Strictly speaking it is not designed to deal with impedance mismatch but to unearth unusual requests. If there are unusual characters used in parameter names (and this is not by design in the application) you will want to know about that so you can investigate.
As far as ModSecurity is concerned, we will pro-actively research other web application environments and document any issues we discover.
