Use application firewalls to secure browser-based solutions

The application firewall is not a replacement for other layers in the controls framework. It supplements them. So what is it and why do you need it? How do you make a business case for another security control?

Web application security continues to concern security and software development managers.  Hundreds of legacy applications are left with holes created prior to developer awareness of guidelines like the OWASP Top Ten.  And although new applications may contain many fewer vulnerabilities, inevitable “bugs” still creep into applications, even those with security “designed in.”  The final line of defense against attacks exploiting these weaknesses is the application firewall.

The application firewall is not a replacement for other layers in the controls framework.  It supplements them.  So what is it and why do you need it?  How do you make a business case for another security control?

Web application security challenges

Once Web applications caught on, once business and IT managers realized the flexibility and value of delivering information via browsers, development of browser-based applications began increasing rapidly.  Today, the average large organization might have hundreds or even thousands of Web applications, ranging from small utilities to large, full-featured enterprise solutions.  Most of today’s developers are aware of common threats facing these applications, and they take steps to program securely.  However, older applications were not built with the same care.  Because most organizations don’t have the time, the budget, or the support of business managers to “fix” perfectly good apps, these legacy solutions continue to offer opportunities to black hat hackers.

Placing traditional firewalls or intrusion prevention devices at the perimeter, or at gateways into secure network segments, is not enough.  Attacks which manipulate software to achieve malicious objectives usually take place over approved traffic sessions, especially ports 80 (HTTP) and 443 (SSL).  Since blocking all browser required traffic at the port level is not a viable option, attacks ride these approved paths looking for software-level vulnerabilities.  Further, IPS and IDS services commonly inspect packets for known attack signatures, but this approach is often ineffective against application manipulation exploits.

The current state of Web application security is a problem for several reasons, including:

  1. HIPAA requires ePHI confidentiality and integrity
  2. Sarbanes-Oxley requires financial reporting integrity
  3. The PCI DSS, FACTA, and various state and local laws require protection of PII
  4. The business’ reputation is at stake
  5. Protecting sensitive data and critical systems is simply the right thing to do

One way to compensate for insecure Web application code is to implement an application firewall.

How application firewalls work

Application firewalls work at layer seven, the application layer, of the OSI model.  See Figure 1.  Traditional firewalls protect networks in lower layers by inspecting and managing packet access based on ports or IP addresses.  This works well when the goal is to either allow or deny certain types of traffic, but it doesn’t work very well against attacks over authorized sessions which target application behavior.

OSI Layers 

Figure 1

Figure 2 shows a recommended placement of an application firewall.  Packets allowed through the perimeter firewall, in this case those directed at port 80 on the application server, must travel through the application firewall.  Further, the layer-seven firewall should inspect any packet traversing the internal network to a Web.  Packets are assessed based on a positive or negative model.

Inline Application Firewall

Figure 2 

In a positive application firewall implementation, the application filter rules are built dynamically with both administrator input and learning algorithms.  Thus, the application firewall learns about the characteristics of the Web application environment, including:

  • Starting pages
  • Form fields
  • Links
  • Drop down menus

Using this information, a usage policy is built for each application session.  Any unrecognized session activity, either before or after initiation, is blocked.  The firewall also performs input validation, checking for unusual or unexpected special characters, and wild cards as well as names of accounts, files, or host systems.

Although providing similar safeguards, application firewalls operating under a negative model are signature-based, using a static policy.  

According to NSS Labs, a well designed and properly configured application firewall should stop many types of attacks, including:

  • Buffer overflow attempts
  • Hidden field tampering
  • Cross site scripting
  • Parameter tampering
  • Cookie poisoning
  • Invalid requests
  • Information disclosure
  • Broken authentication
  • SQL injection

Application firewalls and IPS

Application firewalls are not a replacement for an intrusion prevention system (IPS).  Rather, they complement IPS capabilities.  Yet, the addition of application firewall filtering on top of IPS packet inspection might add additional latency beyond the level acceptable to users.  The solution to this challenge is balance.

Neither intrusion detection nor application session monitoring must be placed inline.  You can position either or both on a SPAN port, for example, to inspect packets without affecting response time.  This approach requires effective monitoring practices and quick, practiced incident response processes.

The final word

It’s unreasonable to expect Web applications to be completely free from all common vulnerabilities, as defined by the OWASP and the WASC.  It’s also unreasonable to expect network and system administrators to apply every patch as soon as it’s released.  It is reasonable, however, to apply an application firewall as an additional layer of defense, watching for behavior or data indicative of attacks against your Web applications.

Whether management believes additional investment in security is necessary depends on how well you make the business case and management’s threshold for risk.


Tom is a security researcher for the InfoSec Institute and an IT professional with over 30 years of experience. He has written three books, Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide (to be publish...


In concept, WAFs are great. In reality, they have a number of significant drawbacks. The first gen of WAFs was untenable because you had to manually configure everything. "This app should take these parameters, of these lengths, of these types..." If all that was thought through and documented your app wouldn't be flawed in the first case. They are, which means if you're managing more than one or two small apps this is a losing proposition. So the next gen of WAFs "learn." They review traffic to discover what is normal and what should be blocked. As you might imagine this sounds better than the reality. In our shop we've done two WAF evaluations and found that most of them don't learn well enough to stop the threats an average Web app vulnerability scanner throws at them. The one that did seem actually secure was a standalone device which had a really bad crashing problem (the vendor acknowledged this), and availability problems in the name of security is beyond unacceptable. We keep putting off a WAF purchase hoping that they'll get better, but for whatever reason (perhaps these) the rate of WAF product development has slowed to a trickle and there's few new vendors on the scene. In the end, there's a reason not many people have installed WAFs. They would have great benefits - if they worked right.

Editor's Picks