Following my obituary for Cisco’s WAF, Packet Pushers did a really great WAF-focused podcast with Raven Alder, appropriately named Saving the Web with Dinky Putt Putt Firewalls. If you have more than a fleeting interest in protecting business web applications, you should definitely listen to it. Just as an aside: when they were recording the podcast, I was writing my To WAF or not to WAF post ... and it’s nice to see we’re closely aligned on most points.

There’s just a bit I’d like to add to their ponderings. What Raven describes is the “proper” (arduous, time-consuming and labor-intensive) use of WAF that we’re used to from the layer-3/4 firewalls: learning what your web application does (learning because the design specs were never updated to reflect reality) and then applying the knowledge to filter everything else (what I sometimes call the fascist mode – whatever is not explicitly permitted is dropped).

You could also use a WAF in a “catch the known exploits” mode, similar to what we do with IDS and virus scanners: most WAF products come preloaded with patterns matching well-known exploits (like SQL injections or XSS attacks). These patterns will stop most of the attacks that use “common knowledge” exploits; they will be (obviously) unable to stop those attacks that are crafted with the knowledge of the business logic of your web application.

Did I just embrace the “quick-and-dirty just good enough” mentality? I must be going nuts.

Last but not least, now that I’ve mentioned IDS: some people think that you can program your IDS to provide functionality similar to WAF. Forget it; as I’ve explained more than a year ago, HTTP+HTML provide too many ways of obfuscating the content you want to sneak past the IDS, or as Raven put it (approximately): “the moment you start writing IDS rules that emulate WAF, you’ve started developing a completely new product”.