We invited Array Networks, CipherTrust, Kavado, MultiNet Security, NetContinuum, Sanctum, Spearhead, Teros (formerly Stratum8), Ubizen, WebScurity and Whale Communications. Array Networks and Whale Communications declined to let us test their offerings. CipherTrust said it felt its product was not a good fit for this review and NetContinuum said it didn't have any units to spare. Spearhead withdrew its NetGap appliance because of a pending architecture enhancement--no sense testing the old stuff. Ubizen never responded to our invitation.
Two other vendors, Gilian and NetScaler, are not included here because Gilian didn't start offering application security modules until our tests were finished, and we were not aware of NetScaler's offerings in time for this article. In addition, there are many host-based Web security products, including eEye SecureIIS and Microsoft UrlScan, that we didn't test because we focused only on proxy-based Web application firewalls.
We gathered Kavado's InterDo, MultiNet's iSecureWeb, Sanctum's AppShield, Teros' APS and WebScurity's webApp.Secure in our Chicago Neohapsis partner labs and tasked them with protecting two horribly insecure test Web sites (for details see "How We Tested Web Security Proxies").
Successful attack prevention was not our only comparison criteria; product configuration flexibility is crucial as well. In theory, these products are similar to regular network firewalls: Open too little and you impact traffic; open too much and you expose your network to security risks. In reality, however, Web security proxies are much more complex than network firewalls, and their configuration can be tricky. The proxy must understand the inner workings of your Web applications. If your security configuration is not symbiotic with your Web applications, you risk leaving vulnerabilities exposed. Therefore, the easier it is to adapt the product to your site, the stronger your security will be.
Plan Before You Deploy
After months of testing, we found that adding a Web security proxy will give you a defensive advantage only if the configuration is perfectly tuned. Deciding which security proxy to deploy depends largely on the Web applications you're protecting; in fact, to gain the highest level of security, you should design your Web sites and applications in concert with the nuances of your selected security proxy. Here are a few tips:
• Separate your Web apps. Global configuration limitations mean that accommodating one application may reduce the protection of another. The solution: Separate large, complex Web applications and deploy multiple security proxies, each tuned for the security needs of its application. Global configurations for an online e-commerce site differ widely from those for an intranet running Microsoft Exchange OWA (Outlook Web Access); using a single security proxy to protect both results in one-size-fits-all protection. You could do better.
• Implement client-side form-field filtering. Many security proxies abruptly halt insecure HTML form data submissions, possibly confusing or scaring off users who accidentally include restricted characters. You will need to implement client-side form-field filtering via active scripting to keep users from accidentally triggering malicious character alerts.
• Beware proprietary data formats. There's little help available for applications that tunnel proprietary data formats via HTTP, such as Microsoft RDS (Remote Data Service) or Java RMI (Remote Method Invocation). You may be able to get a security proxy to pass the arbitrary data, but don't expect the proxy to secure it let alone understand it. For example, none of the products we tested could defend against our vulnerable FrontPage Web site because the products didn't understand the proprietary RPC (Remote Procedure Call) mechanism used by FrontPage.
• Check your HTML. Some proxies parse HTML pages as they are sent to the client. Using well-formed HTML and avoiding client-side JavaScript form manipulation helps the proxy understand your application better, and thus protect you better.
• Run security tests. Have your configuration reviewed or have a security-penetration test performed against the deployed security proxy to ensure the configuration is sound. One wrong regular-expression rule can leave your site vulnerable, but it may not be obvious. Contracting a standard Web application security assessment with any of the numerous security-services companies on the market is a start--if they find any vulnerabilities in the (supposedly) protected Web site, you know the security proxy is not configured properly. In addition, some security-proxy vendors offer configuration training and on-site implementation review. Some, like Teros, even include this in the initial purchase cost.
• Patch your servers. Finally, security proxies do not negate the need to patch your servers. Removing the vulnerability is always a better solution than merely denying access to it (see "PatchLink Helps Keep Windows Closed").
Go Deep
By adding a security proxy, you erect one more layer between you and would-be attackers. If you implement this layer effectively, you will be able to protect against Web vulnerabilities to which you were previously susceptible.
The products we tested had pluses and minuses in different environments, and none is the security silver bullet we'd dreamt of. The Teros-100 APS is only a solid median solution, iSecureWeb is complex to configure, and webApp.Secure is not complex enough. The battle came down to two--Kavado InterDo and Sanctum AppShield--which tied on points. And though InterDo is easier to handle and offers more features, its lack of protection for dynamic form values cost it the trophy. We gave AppShield our Editor's Choice award.
RSS
