Our biggest complaint with AppShield is its inability to change/override some global configuration values on a per-URL basis in the rules manager. Global configuration values apply to all URLs on all protected Web sites. Loosening security restrictions to support one application (in our case, Microsoft FrontPage) caused all our applications to get the same reduced protection.

AppShield does have a few clever configuration options. You can declare certain file extensions as "always safe" and exempt from URL restrictions, useful for graphics and other static content. You can also specify different length restrictions for different HTTP headers. AppShield can even log full incoming IP packets in addition to the normal logging of HTTP-level data.

The only shortcoming we found during our attacks against AppShield was that the default character filter didn't properly stop SQL tampering. We fixed the filter by restricting the single quote character, but the effects are loud and clear: If an administrator isn't Web-attack savvy, the recommended defaults could lead to a false sense of security. You need to know when the recommendations and defaults are wrong or lacking; otherwise, an attacker can pass by unhindered.

AppShield 4.0. Sanctum, (877) 888-3970, (408) 352-2000. www.sanctuminc.com

Kavado InterDo 2.5 Web Application Firewall

InterDo 2.5 is extremely easy to get up and running. Its configuration is intuitive and direct, and the interface lets you segregate your various Web applications and apply security configuration parameters.

Rule management got a bit confusing when we had lots of Web applications, each having many URL rules, but InterDo's automated rule generation can be supplemented by the use of Kavado's vulnerability scanner product, ScanDo. ScanDo exports vulnerability reports to InterDo, which can arrange rules accordingly to protect against the discovered problems.

InterDo features native IP blocking, which can cut off addresses generating too many security alerts. This provides dynamic firewalling capabilities without requiring an OPSEC (Open Platform for Security)-compliant firewall. You will still want an upstream firewall/filter to keep the InterDo host (which is Windows under the hood) from being compromised.

InterDo handled all our URL encoding schemes and caveats, and it understands different character code pages, making foreign character support a cinch. Handling of complex tunneled HTTP protocols, like Java RMI, was manageable thanks to InterDo's "simple tunnel" pass-through support. Using simple tunnels won't provide security protection, but at least you can pass non-HTTP data without having to bypass the security proxy.

InterDo failed in only one area: protecting against form-field tampering. We changed hidden field elements and sent arbitrary checkbox and select menu values. This let us change the prices of items as we added them to our shopping cart. If Kavado were to add this feature, InterDo would be our top pick. Until then, proceed with caution or use AppShield.

InterDo 2.5 Web Application Firewall. Kavado, (800) 239-3203, (646) 274-7238. www.kavado.com

Teros Teros-100 APS

Teros' APS was the only appliance we tested. It is also the only product capable of acting as a network bridge instead of a proxy, which means it can be deployed transparently without your having to reconfigure your network. This eliminates the hassle of rearranging IP addresses of already deployed Web servers.

The APS uses an "adaptive learning" rule generator, which produces recommendations based on observed traffic. The recommendations fared well except for some of the trickier URL formats, which required manual intervention and regular-expression reworking. Rule configuration struck a decent balance between simplicity and granularity.

Administratively speaking, we have two complaints: The error and security logging messages are frustratingly vague, making it difficult to troubleshoot violations. Also, the APS' default form-field-character filter, like AppShield's, is inadequate at protecting against SQL attacks.

The APS also has a configuration nuance that concerns us: It treats form-field names as global across your site. This could be a problem on sites that use form-field names inconsistently. You'll need to use the least-restrictive filter for that field, which is less secure. The workaround is to recode your Web application to use unique form-field names--that is, if you are able to make code changes in your Web applications.

Teros-100 APS. Teros, (408) 850-0800. www.teros.com

WebScurity webApp.Secure Professional 1.1

WebScurity's webApp.Secure Professional is extremely portable and lightweight--on some platforms it requires only one executable and a single configuration file! The product does have an additional GUI, but in the version we tested (a 1.1 preview) it was underdeveloped and didn't provide functionality not already available via the command line; in fact, multiserver support was available only via the command shell. Configuration is done by editing an XML file. WebScurity told us that everything will be integrated into a GUI by the time version 1.1 ships, but we couldn't help but feel that webApp.Secure is still a work in progress.

WebApp.Secure's configuration was the easiest of all products we tested--no configuration wizard or rule generation is needed. The downside is that webApp.Secure lacks specific per-URL configurability. All configuration options affect the server globally; all URLs and form fields get the same restrictions. This lack of granularity meant we were unable to support our OWA deployment. WebApp.Secure avoids messy configuration overhead by using a dynamic rule engine based on modifying the outgoing HTML. WebApp.Secure also determines security restrictions based on special query parameters that are added to all URLs and form submissions. Any request not carrying an appropriate security parameter is denied.

We executed a successful Unicode attack against our webApp.Secure-protected Web site, but only because we relaxed some security rules to support FrontPage. This is a perfect example of how a configuration to support one Web application can introduce a security hole to exploit another. We also tickled a bug with our PHP multipart denial of service attack: WebApp.Secure infinitely retried the request because the server kept crashing from the attack. Our single HTTP DoS request was amplified into a much larger problem without any attacker assistance.

WebApp.Secure was the only product to silently filter bad characters from form submissions rather than stopping the submission dead in its tracks. This kept the site's security as it should be: transparent to the user.

webApp.Secure Professional 1.1. WebScurity, (763) 786-2009. www.webscurity.com

MultiNet iSecureWeb

The Microsoft Windows version of iSecureWeb installs as a plug-in to Microsoft IIS. The IIS server acts as a host for both the proxy and the administrative Web interface.

The configuration GUI is extremely daunting at first. You're stuck floating through many levels, sublevels and sub-sublevels of branches that contain any number of restriction rules/tests. The good side of iSecureWeb is that you can define rules and tests based on literally any aspect of incoming HTTP requests. This is powerful: You can customize every filter down to the byte to accommodate extremely complex Web applications. The dark side of this approach is that you must wield this power right away, starting from near-scratch. ISecureWeb provides the highest level of configuration specificity among all the products we tested, at the cost of having to deal with the details. This results in a longer learning curve and larger chance for incorrect configuration. ISecureWeb does have a policy-creation wizard, which produces rules as it crawls your Web site, but we found that it produced only mediocre rule recommendations that required a lot of manual intervention.

ISecureWeb lacks support for enforcing dynamically generated form values, much like InterDo. We also made an interesting discovery during our ASP buffer overflow attack: Since iSecureWeb is plugged into IIS, the ASP buffer overflow actually caused DoS problems in the security proxy! While these products may provide an extra security layer, you need to be conscious of vulnerabilities within the layer you're adding. And given iSecureWeb's dependency on IIS, you won't quite be able to escape the IIS patching rigmarole associated with Windows servers.

iSecureWeb 2.5.* MultiNet Security, (866) 682-9286, (310) 273-4554. www.multinetsecurity.com (* Information updated 03/18/03)

Jeff Forristal is a senior security consultant for Neohapsis. Write to him at jeff@neohapsis.com. Updates to this article will be available online at www.neohapsis.com/articles/webappfw/.

Post a comment or question on this story.