- Silicon Valley's 19 Coolest Places to Work
- Is Windows 8 Development Worth the Trouble?
- 8 Books Every IT Leader Should Read This Year
- 10 Hot Hadoop Startups to Watch
Network World - 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.