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.
REPORTS
ANALYTICS
Follow 
