Traditional firewalls - when properly configured and managed - do a good job of thwarting many network-level attacks, but do little to address gaping holes in Web applications where intruders commonly attack Web sites directly through form submissions or URL manipulations.

A new class of products - often-dubbed Web application firewalls - attempt to thwart Port 80 focused attacks by using blacklist- and whitelist-style input filtering. We examined six software-based offerings: eEye Digital Security's SecureIIS, KaVaDo's InterDo, MultiNet's iSecureWeb, Sanctum's AppShield, Turillion Software's eServer Secure and webScurity's webApp.secure. We tested all the products on Microsoft's Internet Information Services (IIS) but most also work with Linux and Apache. A future review will cover hardware-based products.

InterDo and AppShield stood above the rest in terms of ability to defend against attacks and suitability for large-scale Web site deployments. While extreme flexibility is the key to InterDo, the dynamic policy generation and strong default configuration of AppShield gave it a slight edge in our evaluation and earned it our World Class award.

Common attack methods come into play
To understand Web application firewalls you have to understand what they attempt to defend against. The most basic application attacks modify an HTTP request to cause a problem on the server or force it to divulge useful information. Generic attacks might use long URLs to trigger buffer overruns, attempt to traverse the site's root directory to run trusted commands, or exploit extended HTTP features to support online collaboration using WebDAV. WebDAV (Web-based Distributed Authoring and Versioning) is an extension of HTTP that lets users collaborate via the Internet.

More sophisticated attacks rely on knowledge of how the Web application works. In database-driven sites using dirty URLs like http://www.sitename.com/app.asp?id=5, SQL commands might be appended to the URL in an attempt to dump useful data or gain write access to the back-end database. Forms also might be open for SQL injection, and tampering with hidden data fields and manipulation of maximum data size limitations, which can lead to buffer-overrun problems. Given the multitude of possible attack methods, any data from the user - be it a simple HTTP request, URL or form submission - should not be trusted implicitly.

Divergent defensive strategies
To combat potential exploits, a Web application firewall will take one of two approaches. A negative model or blacklist product looks for common attack signatures and warns the administrator or blocks the user when it encounters one. A positive-model or whitelist firewall determines all the allowable requests, and inputs and disallows everything else. Some products try to blend the two approaches, but, essentially, all the products tested emphasize either a positive or negative model.

A few of the products also addressed common Web server information leakage issues such as masking server headers or sending back generic or configurable error pages. It was disconcerting, however, to see how easy it was to identify some of the application firewall products via hard-coded error pages or telltales (some signature response that is different enough for the intruder to know what kind of tool is in play) in response headers. Trying to improve security simply by obscuring potentially dangerous information is not true security. Such blatant information leakage seems foolish in a security product and fails to address the well-known fact that reconnaissance is a key part of successful intrusion strategies.

These tested products spread an obvious spectrum of cost vs. functionality. Those employing the positive model generally are more expensive and sophisticated than the products that use the negative-model approach. Another key cost factor is the underlying architecture. EServer Secure appears intended for single-server implementations, while AppShield, InterDo and webApp.secure serve more as proxies, capable of protecting multiple servers. Higher-end products AppShield and InterDo also possess remote-management capabilities and distributed architectures, features designed with server farm deployments in mind.

Raise your AppShield
Sanctum's AppShield boasts a fully distributed architecture designed for server farm deployments. Components include a crisp Java-based management console, a configuration server (mysql is used for database support) and one or more firewall nodes.

AppShield uses a positive model built around what Sanctum calls its Dynamic Policy Recognition Engine. Outgoing pages are scanned and the appropriate whitelist of allowable inputs is constructed accordingly. Such dynamic policy generation is a considerable help in getting the product up and running quickly, and maintaining security policies as the site/application changes. The general policy defaults put in place when one chooses the desired security level are easily loosened by browsing or crawling the site using a trusted IP address, if you find that the default level is too strict for a site or application.

AppShield has a "passive mode" that logs but does not block requests that would violate policy. This mode lets policies be tested, which the administrator can modify selectively in real time by right-clicking the request that is in violation. If there are multiple AppShield nodes deployed in a server farm, the passive mode role could be permanently given to a single node. That node could then serve as a monitor or honeypot for the entire farm. In general, AppShield gets high marks for ease of configurability.

AppShield's dynamic policy generation worked well to prevent forceful browsing by automatically restricting traffic patterns to legitimate navigation paths and limiting form-field tampering. AppShield's default policies, however, were more restrictive than other products tested when it came to preventing simple SQL injection. The default policies also block standard attacks such as buffer overruns, directory traversals and suspicious URLs. For preventing repeated attacks that violate security policies, AppShield can notify a Check Point firewall using the Open Platform for Security (OPSEC) standard that a particular IP should be blocked at the network level.

Customizable error pages are provided, but there are some shortcomings. Although the error page is passed with an HTTP reason code to display, the page itself is retrieved using a redirect, meaning that the underlying HTTP response code is always a 302 (a redirect) followed by a 200 (Ok) - not the code that reflects the actual state of the response. Like many of the firewalls, AppShield runs fast and loose with HTTP response codes, which is troubling from standards compliance and raises the possibility that potential hackers might fingerprint the security software in place from non-standard responses.

On a side note, AppShield takes advantage of being a proxy to provide some interesting security-oriented features that go beyond the usual menu of application firewall options: URL mapping (including regular express matching) and the ability to globally prohibit direct downloading of image and multimedia files, often dubbed "leeching." This interesting feature suggests the possibility of application firewalls eventually merging with authorization and access-control functionality to provide a complete application security framework.

InterDo can do
KaVaDo's InterDo was designed with a large distributed deployment in mind. One or more server nodes communicate with the Java-based management console via built-in Secure Sockets Layer (SSL) encryption - a feature none of the competing products equal. The application server nodes run as a set of services (in the Windows environment).

Although there is no central configuration server, administration of all nodes can be done from a single console. Strict password requirements and the ability to set up multiple users with different administrative privileges show that InterDo is serious about keeping its house in order, while supplying security for the Web application.

InterDo uses a positive-model approach with some novel architectural concepts. Trusted and untrusted zones are joined by what KaVaDo calls "tunnels," an abstraction describing a connection between trusted and untrusted IP address and port combinations. Within the metaphor of a tunnel, security policies are segregated into functional areas called "pipes," several of which can be combined within a single tunnel and selectively applied to one or more applications in a configurable order of precedence. Examples of pipes include general vulnerabilities (URL, header and entity pattern matches), database issues (parameter screening), cookies and HTTP methods. Default pipes do a good job with common buffer overruns, directory traversals and SQL injection. The default settings did not stop form manipulations by default, but it is possible to set up custom tunnels and rules.

InterDo gives administrators a great deal of flexibility in configuring security policies - more so than any other product we tested. On the downside, initial configuration is nowhere near as easy as AppShield's and is probably best undertaken only after reading the manual very carefully.

There is a "lean mode" that lets administrators monitor and selectively modify certain pipes in real time, and requests that run afoul of the security policies are blocked while these refinements are made. This is a safe and helpful way to manage the complexity of configuring multiple pipes.

Another helpful management feature is the update service that can securely update pipes in real time using SSL and digital signatures.

InterDo has an IP-blocking feature that temporarily prevents continued access from visitor IP addresses that have generated enough security policy violations to constitute a suspect pattern of malicious behavior. Suspect attackers are given a security score (high, medium or low) and blocked for varying durations. The response to further requests from a blocked IP is simply a dropped connection, but it might be better - especially for Level 1 attacks - to have the option to show the possibly malicious user a configurable message. For those with a Check Point firewall, InterDo is also OPSEC-compatible for firewall-based network blocking.

SecureIIS: URLScan on steroids
EEye Digital Security's SecureIIS has by far the best user interface of all the products tested. The program uses an interface similar to Microsoft Outlook's that makes configuring this negative-model application firewall trivial. Unfortunately, SecureIIS lacks the depth of many of the other products and appears to do little beyond what a capable administrator could do with Microsoft's free URLScan tool.

While SecureIIS could deal with malformed requests exceeding size limits and basic URL tampering, it couldn't detect and block any form tampering or careful SQL injection.

Furthermore, the product sent back the inappropriate 406 "Not Acceptable" HTTP response code on request rejection, rather than 403 "Forbidden" or 404 "Not Found" message, as it probably should. This is the wrong response code and informs a potential intruder that SecureIIS is being used.

SecureIIS does have some nice features to ease deployment in a multi-server environment by letting policies easily be replicated to other systems. The product also has some basic file-integrity monitoring features that could be useful if an intruder penetrated a machine, but they seem out of place in an application firewall offering.

SecureIIS is targeted at users looking to have the support and ease of use missing from URLScan. Interestingly, eEye recently announced a free personal-use version of its software that makes this product an obvious replacement for URLScan and obvious first step for those IIS administrators new to application firewalls.

EServer Secure for the entry level
Turillion's eServer Secure is designed specifically for the IIS Web server environment. Based on Internet Server Application Program Interface (ISAPI) technology, eServer Secure combines a host-based architecture with the flexibility of a Web-based management interface.

This is a strictly negative-model firewall, with a respectable blacklist of attack signatures that are blocked by default - long URLs, disallowed methods and directory traversals, for example - and the ability to revise these policies for tighter security. These attacks were blocked as expected.

SQL injection can be combated, but this is addressed through keyword filtering, and you likely will want to strengthen the default policies to make them more robust. This product does not obviously address manipulation of form-field sizes. An update subscription service is offered to keep the attack signatures current. Error pages are fully configurable.

The HTTP management interface is a convenient way to handle remote administrative duties but is also a liability. Security for remote management is provided via basic IP filtering. This is a nice feature, but the wise user most likely will want to employ SSL as well to further secure communication with the firewall.

The Web interface suffers from the statelessness and latency one would expect from HTTP, and some quirks exist - probably a function of the tricky interprocess communication between the ISAPI extension that supports the user interface and the ISAPI filter that is responsible for actually carrying out the security policies.

Changes to the administration interface do not always seem to take effect immediately or consistently, and some of the integrated reporting and statistical features display disconcerting inaccuracies. For example, a single request generated approximately 60 "requests processed," and a number of common attacks were miscategorized.

In general, eServer Secure struck us as a good example of an entry-level product. In that sense, its most direct competitors in this review are iSecureWeb and SecureIIS. Among those products, eServer Secure does not stand out for having any major flaws (apart from its user interface quirks) but neither does it distinguish itself as superior.

WebApp.secure: Positive model on the cheap?
WebScurity's webApp.secure [www.webApp.secure (link no longer active)] attempts to bring the benefits of positive-model application firewalls within reach of smaller organizations.

Like most positive-model firewalls, webApp.secure bases its security model on a whitelist of permitted requests called Intended Use Guidelines. In webApp.secure's case, this is a list of legal URLs for the entire site, which is built through the use of what webScurity calls "entry points." Entry points let administrators adjust the relative "porousness" of a site/application, by forcing users to come into it through certain pages but not others and also to control URL jumping within the site.

During configuration, entry points that the administrator has designated are treated as starting points for building the map of permitted URLs and navigational paths between them. Essentially, a trusted user (or script) must navigate from each designated entry point to all the pages that are to be treated as legally accessible from that entry point. From this configuration-time traversal, webApp.secure learns where traffic is allowed to enter the site, and where it is allowed to go, establishing positive-model access control. In theory this should be quite useful in combating exploits that depend on URL jumping and other forceful browsing techniques. However, during testing it didn't always work correctly.

WebApp.secure also shines in protecting against form-field manipulation and in blocking the usual run of common attack signatures. SQL injection and cross site scripting are not well defended against by default, but lexical blocking is available by disallowing specific characters in form field values - an example of where the positive model implementation gives way to standard negative model techniques, with a resulting extra burden on the administrator.

Implemented as a proxy that is controlled via an XML configuration file, webApp.secure also provides a native - but somewhat awkward - Windows GUI for administration. When inspecting the configuration or making changes, we often preferred to access the XML configuration file directly.

The product has a number of shortcomings that suggest a lack of overall polish. The error/block pages are hard-coded, making them impossible to edit. Without such modification, the software immediately tells the potential intruder what kind of countermeasure software is installed. However, Version 2.0 of webApp.secure was released after testing and many of these issues might have been addressed.

MultiNet iSecureWeb focuses on Microsoft's IIS
MultiNet's iSecureWeb also is built with ISAPI technology and intended for deployment on IIS hosts. A proxy site (the "Gateway") is set up to filter incoming requests headed to an origin site. Policy administration is done via a stand-alone interface (the "Studio") that can be installed on a separate box. Studio is a two-pane, native Windows affair. Getting used to navigating around its multi-tab, multi-level tree view control - and learning how to make sense of it all - takes a considerable investment of time and patience.

As for the security capabilities of the default rules, common buffer overflow, the default policies handle the illicit character sequence and directory traversal attacks well. However, neither SQL injection nor form-field manipulations are dealt with adequately.

The predominant approach is clearly negative-model, which limits the reach of the default rule set and makes post-installation configuration a must for a secure setup. At that point, considerable power is available to the administrator - especially one willing to wade through the intricacies of the user interface and, in the case of certain rules, deal with the complexities of regular expression syntax. There is probably no Web-based attack that one cannot stop with an iSecureWeb rule, if you've got the patience and knowledge to create and apply it properly.

Error pages are easily located and edited, a good anti-fingerprinting measure. However, it is all for naught because our installation of iSecureWeb doubled the HTTP headers in every response and certain HTTP response codes lacked the usual response message following the numeric code. Not only does such behavior make a host easy to fingerprint, it raises serious doubts about the soundness of MultiNet's proxy implementation in general. Before running iSecureWeb in a production environment, we would want more assurance that it can be set up in a way that makes it fully HTTP-compliant.

Conclusion
The products we tested fall into two distinct classes. The low-end products -SecureIIS, webApp.secure, iSecureWeb, and eServer Secure - are useful but have configuration or occasional operational problems. SecureIIS - while potentially the least capable - is probably the best bet for someone looking for some simple protection for the most basic attacks. However, for those administrators who want to get serious about application-level protection, it is really only a choice between InterDo and App.Shield, with AppShield having a slight advantage in our assessment. However, both have significant learning curves and might require consulting services for correct usage.

In the final analysis there is a lingering question of whether some of the "exploits" these products protect against shouldn't be dealt with during the Web application development process.

Obviously filtering out bad requests is a wise addition to a Web server, but shouldn't a Web application keep track of field sizes and allowed data directly? It would be less expensive and more effective to design security into a Web application in the first place.

Given Sanctum's recently released developer-focused product AppScan DE, it would seem that even Web application firewall vendors understand the need to have security designed into the application from the start. However, the cost of reworking an existing Web application might be significant enough to make even expensive Web application firewalls cost-effective additions to the Web administrator's security arsenal.

How we did it
We used a pair of Dell PowerEdge 6000 servers running Windows 2000 and Microsoft Internet Information Server 5.0 as the testing platform. The test sites installed used ColdFusion and Active Server Pages for dynamic database access and did not have input sanitization built in. Testing covered exploits such as URL tampering, form-field manipulation, SQL injection and many known IIS server specific exploits. Two other machines on a connected network using automated security audit tools and manual attacks performed testing. A third machine was used as the administration console for altering and configuration where possible. Server interaction was monitored not only at the browser level but the underlying HTTP discussion was monitored to ensure standard interaction between systems.

Originally published on Network World, Published: August 18, 2003.