Proxies Add a Protective Shield

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 DeployAfter 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.Sanctum AppShield 4.0 | Kavado InterDo 2.5 Web Application Firewall | Teros Teros-100 APS | WebScurity webApp.Secure Professional 1.1 | MultiNet iSecureWeb

Sanctum AppShield 4.0

We tested AppShield 4.0 with Service Pack 2 and Option Pack 1 applied to gain additional support for handling OWA WebDAV queries. AppShield has been around the longest of the products tested, and its maturity is obvious. It has a full complement of features and a flexibility that makes it adaptable to nearly every standard Web environment.AppShield's URL-restriction rules were the easiest to configure among the products we tested. The alert log can feed rules into the rule manager based on what caused the alert, making it easy to troubleshoot erroneous violations. However, the rule manager is a bit clunky in supporting complex Web applications. We had to enter six separate rules (for the six WebDAV methods OWA uses) because the rule manager wouldn't let us put multiple HTTP methods on a single rule.

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.comKavado 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 159.3. MultiNet Security, (866) 682-9286, (310) 273-4554. www.multinetsecurity.com Jeff Forristal is a senior security consultant for Neohapsis. Write to him at [email protected]. Updates to this article will be available online at www.neohapsis.com/articles/webappfw/.

Post a comment or question on this story.Remember when most attacks hit at the network layer? Those were the days. Now, with the proliferation of Web services and introduction of protocols like SOAP, who knows what evil is trying to slither in via HTTP tunnels? Think you're safe? How many different applications run in your Web environment? Have you done a security assessment of all that source code? We didn't think so.

One possible answer is a Web application-level firewall. We installed proxy offerings from Kavado, MultiNet, Sanctum, Teros and WebScurity in our Chicago Neohapsis partner labs and tasked them with protecting two deliberately insecure Web sites. We tampered with cookies and form fields, threw Microsoft FrontPage into the mix, then sat back and watched the destruction. We also evaluated ease of configuration, a huge concern unless you have strong application-security chops on board.

None of the products could stop every attack, but Kavado InterDo and Sanctum AppShield came closest. We were impressed by InterDo's feature set, but it let dynamic form value attacks slip past, giving Sanctum the edge to win our Editor's Choice.Our plan: Take off-the-shelf Web application platforms, like PHP and JSP, sprinkle in common programming mistakes, and see if the security proxies can defend the applications against our offensive onslaught. You'll find a full list of our attacks on page 56.

We used a range of Web technologies to create challenges for the security proxies. Our first Web server was a full-functioning e-commerce site for ordering books, la Amazon.com. It comprised an Apache Web server hosting PHP and JSP pages via a Caucho Technology Resin Java server. We went with SAP for the back-end e-commerce database. The second test Web server was based on Microsoft Windows 2000 Small Business Server and hosted both a small IIS intranet site and an Exchange 2000 OWA (Outlook Web Access) deployment. The intranet site connected to Microsoft SQL Server behind the scenes and used Microsoft FrontPage to publish HTML content. We used slightly older versions to ensure we had vulnerabilities to exploit.We specifically chose Resin JSP, FrontPage and OWA to evaluate how well the security proxies support nonstandard Web applications. Complex Web applications may use proprietary data or URL formats, which typically fall outside the range of "normal" as defined by the security proxies. OWA uses WebDAV queries (a file publishing extension on top of HTTP) for handling e-mail. Microsoft FrontPage, another file publishing extension over HTTP, tunnels data in proprietary RPC formats via CGIs. Some JSP servers, like Resin, embed session IDs in the URLs. Overly paranoid security proxies may not be able to accommodate these types of anomalies. Other proxies may require a reduction in protection to allow nonstandard applications to work--in some cases, this reduction disables the security protection altogether. Microsoft FrontPage was so alien to the security proxies that none was able to understand what it was doing within all those RPC requests--which was, in our case, defacing the Web site.

We also used custom Web scripts coded from scratch. The custom scripts featured many common programming mistakes seen in Web applications. The sites also included many nonstandard (but still valid) URL and form tricks occasionally found on the Internet that could cause the protection devices to get confused.

We generated client traffic using custom client scripts and manual Web browsing with different browsers. Attacks were scripted or done manually through a browser, using the same tools and exploits attackers would use.

The security proxies were dual-homed, ensuring the only way to access the Web servers was by going through the security proxy. We configured the proxies to listen on two external IPs and forward requests to the two respective internal Web servers. All software products were installed on identical Windows 2000 Advanced Server SP2 platforms sporting 1.2-GHz CPUs, 512 MB of RAM and 10-GB hard drives.

To create initial configurations, we used the products' automated learning/policy generation tools. We reviewed all automated policies and tweaked them based on a set of configuration minimums, and then modified them further to ensure all test site functionality worked. We gave partial credit to products that recommended an insecure rule--one we found inadequate after exploiting the related vulnerability. This approach is fair because many admins will likely use the configurations produced by the adaptive learning tools. All products used the highest security settings available, except where reduced to accommodate test site functionality.To determine how well the security proxies we tested protected against attackers, we had to unleash some attacks of our own. Here are details on our arsenal:Forceful browsing: Making a request to a nonpublic directory to get a directory listing of contents. Our /inc/ directory on the server contained sensitive logic scripts.

Username/password SQL tampering: Attempting to log into the application by submitting a password that manipulates the SQL query into providing access for any valid user name, without needing the appropriate password.

Hidden field-price manipulation: The price of an item is passed to the shopping cart as a hidden form parameter; by changing the hidden value, we could change the price we were charged for the item.

URL query SQL manipulation: Manipulation of a URL query parameter to cause a SELECT/LIKE statement to display additional data.

PHP multipart DoS: (CVE-2002-0081) Certain versions of PHP contain buffer overflows as well as denial of service attacks within the multipart file upload code. By sending a multipart upload data with a malformed Content-Disposition header, we could cause PHP (and thus the Apache child process) to crash.Cookie tampering: Our Web session IDs are tracked via cookies. By changing the value of the session ID, we could access other users' sessions. The test site used sequential session IDs, making it easy to guess valid values. Our application also uses a cookie to hold the user name of the logged in user; by changing the cookie value, we could change our login identity.

Cross-site scripting: JavaScript was inserted/appended into various query parameters in an attempt to have the JavaScript executed in the browser.

Server headers exposed: The server header (often referred to as a "banner") tells the attacker what version of Web server you are running--and, therefore, what vulnerabilities it might contain. PHP also adds an additional 'X-Powered-By: PHP/4.x' header. Partial failure means the product removed/replaced the standard server header but left the non-standard PHP header.

IIS ASP chunked encoding buffer overflow: (CAN-2002-0079) The ASP handler on IIS contains a buffer overflow on the handling of chunked post requests, letting us run arbitrary code or render the IIS ASP handler unusable.

IIS IDA handler leakage: (CAN-2000-0071) We made a simple request for "/.ida" in order to view any diagnostic error messages.Feedback form SQL tampering: Execution of additional SQL queries, used to run a xp_cmdshell command on a MS SQL Server via a textarea form element.

IIS Unicode attack: (CVE-2000-0884) The Unicode attack let us run various executables outside the webroot. We ran the attack using the '/scripts/' and '/_vti_bin/' base directories.

Allows OPTIONS request: We made a simple OPTIONS request to see what methods the server reports allowed. This is a mild information leak that can aid an attacker in understanding how the Web server is configured.

IIS .printer buffer overflow: (CVE-2001-0241) A straight buffer overflow in the IIS .printer handler, which let us run arbitrary code.

Open FrontPage web: We used the FrontPage client to modify the HTML of pages found on the server. The test server was incorrectly configured to not require authentication (what is considered to be an "open" FrontPage Web).Various form validity tampering: We used a test form containing various select, checkbox and radio input values to determine if the security proxy would ensure the values we submitted were legal, allowed values; for example, when given a select menu with choices "A," "B" and "C," we attempted to submit nonexistent value "D." We used both static and dynamically generated form values. Partial failure means the product can handle static values via hard-coded rule definitions but cannot handle dynamic values.

CVE IDs were included for attacks that exploit specific vulnerabilities; however, many of the attacks are more general in nature. Below are a few URLs explaining some of the general vulnerabilities we tried to exploit.

• Cross-site scripting

• SQL injection

• Cookie manipulation• Form-field manipulation

• Session hijacking

R E V I E W

Web Security Proxies

Sorry,
your browser
is not Java
enabled

Welcome to

NETWORK COMPUTING's Interactive Report Card, v2. To launch it, click on the Interactive Report Card ® icon

above. The program components take a few moments to load.

Once launched, enter your own product feature weights and click the Recalc button. The Interactive Report Card ® will re-sort (and re-grade!) the products based on the new category weights you entered.Click here for more information about our Interactive Report Card ®.