Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

  1. Home
  2. Careers-and-certifications
  3. Proxies-add-protective-shield
  4. Page
  5. Proxies Add a Protective Shield: Page 7 of 22
Careers and Certifications

Proxies Add a Protective Shield: Page 7 of 22

Web security proxies--aka, Web application firewalls--can detect and mitigate common attacks, but configuration is crucial. Kavado InterDo and Sanctum AppShield ran neck-and-neck, but AppShield captured the top spot--for now.
March 10, 2003

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.

Tags:

News
Careers and Certifications