Web application firewalls have a difficult job trying to make sense of data that passes by, without any knowledge of the application and its business logic. The protection they provide comes from having an independent layer of security on the outside. Because data validation is done twice, security can be increased without having to touch the application. In some cases, however, the fact that everything is done twice brings problems. Problems can arise in the areas where the communication protocols are not well specified, or where either the device or the application do things that are not in the specification.
The worst offender is the cookie specification. (Actually all four of them: http://wp.netscape.com/newsref/std/cookie_spec.html, http://www.ietf.org/rfc/rfc2109.txt, http://www.ietf.org/rfc/rfc2964.txt, http://www.ietf.org/rfc/rfc2965.txt.) For many of the cases possible in real life there is no mention in the specification - leaving the programmers to do what they think is appropriate. For the largest part this is not a problem when the cookies are well formed, as most of them are. The problem is also very obvious because most applications only parse cookies they themselves send. It becomes a problem when you think from a point of view of a web application firewall, and a determined adversary trying to get past it. I'll explain with an example.
In the 1.8.x branch and until 1.8.6 (I made improvements in 1.8.7), ModSecurity used a v1 cookie parser. When I wrote the parser I thought it was really good because it could handle both v0 and v1 cookies. However, I made a mistake of not thinking like an attacker would. As Stefan Esser pointed out to me recently, the differences between v0 and v1 formats could be exploited to make a v1 parser see one cookie where a v0 parser would see more. Here it is:
Cookie: innocent="; nasty=payload; third="
You see, a v0 parser does not understand double quotes. It typically only looks for semi-colons and splits the header accordingly. Such a parser sees cookies "innocent", "nasty", and "third". A v1 parser, on the other hand, sees only one cookie - "innocent".
How is the impedance mismatch affecting the web application firewall users and developers? It certainly makes our lives more difficult, but that's all right - it's a part of the game. Developers (of web application firewalls) will have to work to incorporate better and smarter parsing routines. For example, there are two cookie parsers in ModSecurity 1.8.7. The user can choose which one to use. (A v0 format parser is now used by default.) But such improvements, since they cannot be automated, only make using the firewall more difficult - one more thing for the users to think about and configure.
On the other hand, the users, if they don't want to think about cookie parsers, can always fall back to use those parts of HTTP that are much better defined. Headers, for example. Instead of using COOKIE_innocent to target an individual cookie they can just use HTTP_Cookie to target the whole cookie header. Other variables, such as ARGS, will look at all variables at once no matter how hard adversaries try to mask them.