Web application firewalls (WAFs) are hardware or software devices positioned to monitor website traffic, with the ability to enforce policy on browser/server transactions. WAFs are specifically designed to inspect HTTP(s) traffic and regulate data contained within headers, URL parameters, and web content. On top of that if an attack dose find a way to sneak past a WAF, it still has the ability to prevent sensitive information from leaving the trusted network.
Application firewalls or proxies certainly do offer several advantages over packet filter and stateful packet inspection firewalls. Although these types of firewalls can prevent various network-level attacks, they cannot block the gaping holes found in most Web applications that allow hackers to attack Web sites directly through URL manipulation. However, they can permit or deny specific applications or specific features of an application given a great degree of granular control. Application firewalls can also authenticate users directly. This means, for example, that they can allow or deny a specific incoming telnet command from a particular user, whereas other firewalls can only control general incoming requests from a particular host.
They also provide better content filtering capabilities as they have the ability to examine the payload of the packet and make decisions based on actual content. Having the ability to examine the entire network packet rather than just the network addresses and ports means they have more extensive logging capabilities too, such as application-specific commands, which provide valuable information for dealing with security incidents and policy implementation.
So, given these obvious security advantages why application isn’t firewalls the default option? Well, the main reasons are cost and performance. Since all incoming and outgoing traffic is inspected at the application level, it must pass through all seven layers of the OSI model prior to being inspected, whereas packet filtering and stateful packet inspection methods just look at traffic at the network layer. Because the firewall must consume CPU cycles reading and interpreting each packet, the inspection process requires more processing power, which has the potential to become a bottleneck for the network. This means application firewalls are more susceptible to distributed denial of service attack and therefore are less suited to high-bandwidth or real-time applications. The firewall can also be vulnerable to the security loopholes of the underlying operating system.
Another disadvantage of application firewalls is that each protocol, such as HTTP, SMTP, etc., requires its own proxy application, and support for new network applications and protocols tends to be limited. Although most firewall vendors provide generic proxy agents to support undefined network protocols or applications, they tend to allow traffic to tunnel through the firewall, negating many of the reasons for operating an application firewall. Alternatively, stateful packet inspection firewalls, like packet filtering firewalls, have very little impact on network performance, can be implemented transparently and are application independent. Scalability can also become a problem as the number of clients or the number of proxies increases. Application firewalls typically require clients on the network to install specialized software or make configuration changes to be able to connect to the application proxy. This can have quite an impact on larger networks. To reduce the load on the firewall, a dedicated proxy server may be needed to secure less time-sensitive services, such as e-mail and most Web traffic adding to the overall costs.
A mistake in configuration, a signature that doesn’t work, or a zero-day attack all can create a hole that attackers could slither through.
Secure Socket Layer (SSL). One of the most crucial things to consider, especially for retailers or anyone with a sensitive site, is how the WAF you choose manages SSL. Because SSL traffic typically is decrypted by the web server, the WAF will must be able to decrypt SSL traffic to check if a data payload has any harmful content. If your WAF can’t do this, its usefulness is limited significantly. Typically, WAFs can support SSL in the following ways:
1. The SSL decryption operation is moved from the web server to the WAF. The WAF inspects data and passes only good requests on to the web server.
2. The WAF somehow is embedded in the web server or has hooks that the web server can call after decrypting the data. The WAF then can check the validity of each request.
To conclude this I should say that WAFs don’t displace code reviews or vulnerability assessment. WAFs should supplement, not replace, thorough security code reviews. WAFs aren’t perfect and can break down; as a result, all software must be developed and hardened properly. For commercial software, that includes evaluating the software with a web application scanner, and performing a thorough security code review of all custom-built applications. A mistake in configuration, a signature that doesn’t work, or a zero-day attack all can create a hole that attackers could slither through.