There are still several issues with WAF and its understanding of function and role.
1. One of the problems in WAF is understanding of what it does. For example there are over 30 categories or vertical markets that are functionally describing the WAF role.

2. Many so called WAF are IDS with added scripts. THen add the that seveal well known network security vendors when pressed have only 2 scripts to address SQL injection. WAF need to have reverse proxies to be truly effective.

3. Most WAF designs are using list based technology. That is black list vs white list. Intelligence must be added to the list concept in order to to identify and stop new variants and mutated virus.

We have many documented cases that an Intelligent WAF is what saved the customer from attackers getting in.

For whatever reason I didn’t parse the text in Rich’s post that way, but re-reading it I see where you are getting that from.

Other than that, I totally agree with you – there’s a lot of good WAF-like technologies out there, and if a WAF is being put to it’s intended use it should work well. I guess both of our concerns are their are not being used “correctly” and we’ve a long way to go before they are.

I still think though that at some point in the future we are going solve “most” of the XSS/SQLi issues one-way-or-the-other, and when that day eventually comes, there’s going to be a lot more to worry about because if we can’t even get these simple vulns bolted-down (and that maybe a long time – buffer overflows for example are 30+ years old and only now are we starting to see fewer of them, but they are certainly not going away) then when it comes to the harder problems I believe there’s going to be a lot of “heads in the sand”. As you say, these really will be the largest risks, and people will target them because the LHF doesn’t exist or ROI in finding them isnt worth it.

I was responding to the above remark with the quote from me that you pointed out.

BTW – As far as “Tools” go… I consider WAF as a tool just like app scanners. In fact, I think Ryan Barnett’s use of mod-security from BlackHat DC to monitor active XSS on the outbound is probably the best use of a WAF. Also see Don Ankney’s “Is XSS Solveable?” talk from LayerOne 2009 last weekend.

Another great use of a WAF is the Microsoft Anti-XSS Security Runtime Engine — and I hear that Microsoft plans to utilize a similar defense for SQLi. GDS Security’s SPF is also interesting, as well as Microsoft AntiCSRF or the Ryan Barnett mod-security anti-csrf method.

However, these low-hanging fruit vulnerabilities are really not what manages the risks to the applications. The largest risks are never XSS or SQLi. The SQLi attacks against Kapersky/etc were proof that most adversaries are not smart enough to steal data or pop boxes worth any value — at least without a nice audit trail to follow. XSS attacks, especially Caballero or BeEFYPROXY style attacks, are very much under the radar in the same way that these recent Websense-found “mass injections” just happen. The SQLi attacks that injected Javascript into SQL Server using a standard route through Classic ASP were much more visible.

I do not think WAFs are going to help with these issues — heck I don’t even think whitelisting-based technology using BlueCoat SG, Finjan NG, or Ironport S-Series is going to help. The problems are way too deep in the applications themselves. Even the botnets are beyond our modern technological controls at the “network WAF” or “network Secure Web Gateway” layers. We have *got* to get closer the apps, people!

When you have HTML/XML, CSS, or XSLT injections from the Integration Tier (see: common Core Patterns, Web 2.0 Patterns, EAI Patterns), there is no way a WAF is ever going to help. There are domain logic problems that are completely untouched by all of these tools. We need more experts… we need to train them… we need to re-purpose our risk experts and infosec experts to handle these app/data security modern issues. Get with the program, people!