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.

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.