Web Application Firewalls in Practice - or - Yes, Jeremiah, Secure Software Does Matter

There's been a lot of renewed interest in web application firewalls lately. In the past, I haven't been a huge fan of WAFs - they always seemed to me to be just a band-aid stuck on the sucking chest wound of insecure code. But I bumped into Jeremiah Grossman at BlueHat, and he raised some good points in defense of WAFs, the most compelling of which was the use of WAFs as emergency first-response tools. Consider the recent mass SQL injection attacks. Fixing these vulnerabilities is going to cost a lot of time and a lot of money. What if, instead of taking the vulnerable sites down while they're getting fixed (or worse, just leaving the sites up and vulnerable while they're getting fixed), the admins put WAFs in front of the sites to keep them up and running while the security holes get patched?

Now, I like this idea a lot. In theory. But in practice, what I'm afraid will happen is that the WAF will get put up as an emergency response, and then the actual code fixes will never get written because they'll take a long time and they'll cost a lot of money and why should we bother because we're already protected from the threat anyway?

Maybe I'm being overly cynical about this. Right here, right now, I'm going to publicly change my stance on WAFs. WAFs can be an excellent defense-in-depth measure and a good emergency first-response tool, but they will never be a replacement for secure code or a secure software development lifecycle. Instead of a band-aid, think of a WAF as an all-star shortstop (or guard, or linebacker, depending on your sport of choice). He'll save you some runs, but you can't put him out on the field all by himself.