Home > Uncategorized > Application Layer Firewalls

Application Layer Firewalls

There has been a lot of discussion about application-layer firewalls over the last few years, and the popularity of these devices has grown considerably. Wikipedia defines application firewalls as “…a computer networking firewall operating at the application layer of a protocol stack. It operates by monitoring and potentially blocking the input, output, or system service calls which do not meet the configured policy of the firewall. The application firewall is typically built to monitor one or more specific applications or services (such as a web or database service), unlike a stateful network firewall which can provide some access controls for nearly any kind of network traffic.”

There is a very obvious need for application-layer firewalls. The main two targets of today’s cyberattacks are browsers and Web applications. Although application-layer firewalls cannot do much to stave off attacks against browsers, they can do much to protect against attacks against Web applications.

I’m familiar with most of the leading application firewalls and agree with the vendors’ claims that these firewalls need to be deployed to protect applications from attacks against them. What greatly concerns me, however, is that the majority of these vendors seem to convey the message that if somebody buys and implements their products, these products will protect that person’s organization against all kinds of Web application attacks. I am sure that these products will protect against some (and perhaps even many) attacks, but what these vendors don’t tell anyone is that these firewalls are to at least some degree generic. Mechanisms that reflect an understanding of the specific ways that information flow works in these firewalls and the kind of user input that is needed at each point in every user-application interaction cannot be built into application firewalls unless a vendor knows which particular applications an organization has and tailors the firewall accordingly.

A few examples should help make my argument more clear. Every firewall, whether or not the firewall is an application firewall, should keep the following type of user-supplied input from reaching any application:

#rm –rf / *.*

It should also stop input that is excessively long or that has user-supplied single or double tick marks embedded within any SQL query. But what application firewalls fail to do is to determine whether the following input to any application is legitimate:


This input looks like a phone number, and indeed, that was my intention. If a user has entered these numbers in a field in which the user is supposed to enter, say, his/her work number, the input would be legitimate. If, on the other hand, this input were entered in a field in which the amount of money to be withdrawn from a banking account, the input would be bogus (unless, of course, some multi-billionaire were trying to withdraw $9,254,444,444 from one of his/her accounts—a very unlikely scenario!).

The point I am trying to make is that application firewalls can and do protect against well-known attacks against applications, e.g. attacks that attempt to exploit PHP vulnerabilities and programming errors. But unless these firewalls are custom-tailored with respect to the applications they are supposed to protect, they simply do not go far enough. As such, the most effective application firewalls are custom built and then modified regularly to keep up with changes in applications. As with so much else in information security, the easy way out (having a more-or-less generic application firewall) is not the best way, and application firewalls are just one case in point.

Categories: Uncategorized Tags:
  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.