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:
