If you have been visited by a friendly Cisco sales engineer recently, you might have already heard about the ACE Web Application Firewall (WAF). If you’re curious enough to start investigating on your own, you might have stumbled across the WAF product description on Cisco’s Web site, which tells you … nothing.

Let’s start with an easy question: if I already have a firewall, why would I need another box with “fire” and “wall” in its name? The short answer is “Because Web programmers rarely know how to write secure Web applications.”

The long answer is somewhat more complex. Everyone is talking about “SQL injection” and “cross-site scripting” today (even if they don’t have a clue what they’re talking about), but these attacks were not widely known a few years ago. If you have a Web application that was developed more than a few months ago by an average team of programmers, chances are that at least some of the modules are vulnerable to HTML-based attacks. It’s easier to install a dedicated filter in front of your application than to dig into hundreds of thousands of lines of scripting code, trying to identify all vulnerable code segments. To make your job easier, WAF contains predefined signatures for most common attacks (the famous Top 10 attacks of 2007).

The next question should also be obvious: why can’t my existing firewall or intrusion detection system (IDS) handle these functions? Of course it could (in theory), but the attacks we’re trying to catch can be highly obfuscated. For example, a typical SQL injection attack inserts an SQL statement into a parameter of a Web (HTTP) transaction. The parameter can be passed in the query string part of the Web address (URL) or in the body of the request, where it could be escaped in several different ways to make it unrecognizable by a simple signature match. (If you want to know how many steps are needed to get an application-level value of a parameter, read the message normalization section of the WAF user’s guide.) These operations cannot be performed at the same speed as simpler TCP/UDP-based filters or simple IDS signature matches. If you implemented application-level functionality in an ASA firewall or IDS, its performance would drop significantly … and all of us would immediately start complaining.

And here is the third question you should ask before starting to dig into the WAF documentation: why would I need both a dedicated firewall (ASA or FWSM) and a WAF? Well, if you believe that you can make a fast and reliable firewall out of a Red Hat Linux system (the WAF platform), be my guest and use only WAF … but then I wonder why you had a firewall in front of your servers in the first place. You need a dedicated firewall to perform high-speed low-level inspections, catching various attacks on network and transport layers. After the firewall does its job (letting only the “clean” content through), the WAF inspects the incoming data on the application level and rejects attacks that are too complex for the ASA/FWSM.