Proxies Add a Protective Shield: Page 2 of 22
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:
click to enlarge
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.