Sanctum’s AppShield

PUBLISHER’S NOTE: Please note that, as of 9/29/03, all of your valued Network World Fusion newsletters will be delivered to you from nwfnews.com. If you use filters to manage your newsletters based on domain name, please adjust accordingly.

There’s a new class of products called Web application firewalls that attempt to thwart Port 80 focused attacks by using blacklist and whitelist filtering. And you know if there’s a new class of products, the Reviewmeister will be there to test them.

Sanctum’s AppShield boasts a fully distributed architecture designed for server farm deployments. Components include a crisp Java-based management console, a configuration server (mysql is used for database support) and one or more firewall nodes.

AppShield uses a positive model built around what Sanctum calls its Dynamic Policy Recognition Engine. Outgoing pages are scanned and the appropriate whitelist of allowable inputs is constructed accordingly. Such dynamic policy generation is a considerable help in getting the product up and running quickly, and maintaining security policies as the site/application changes. The general policy defaults put in place when one chooses the desired security level are easily loosened by browsing or crawling the site using a trusted IP address, if you find that the default level is too strict for a site or application.

AppShield has a “passive mode” that logs but does not block requests that would violate policy. This mode lets policies be tested, which the administrator can modify selectively in real time by right-clicking the request that is in violation. If there are multiple AppShield nodes deployed in a server farm, the passive mode role could be permanently given to a single node. That node could then serve as a monitor or honeypot for the entire farm. In general, AppShield gets high marks for ease of configurability.

AppShield’s dynamic policy generation worked well to prevent forceful browsing by automatically restricting traffic patterns to legitimate navigation paths and limiting form-field tampering. AppShield’s default policies, however, were more restrictive than other products tested when it came to preventing simple SQL injection. The default policies also block standard attacks such as buffer overruns, directory traversals and suspicious URLs. For preventing repeated attacks that violate security policies, AppShield can notify a Check Point firewall using the Open Platform for Security (OPSEC) standard that a particular IP should be blocked at the network level. 

Customizable error pages are provided, but there are some shortcomings. Although the error page is passed with an HTTP reason code to display, the page itself is retrieved using a redirect, meaning that the underlying HTTP response code is always a 302 (a redirect) followed by a 200 (OK) – not the code that reflects the actual state of the response. Like many of the firewalls, AppShield runs fast and loose with HTTP response codes, which is troubling from standards compliance and raises the possibility that potential hackers might fingerprint the security software in place from non-standard responses.

On a side note, AppShield takes advantage of being a proxy to provide some interesting security-oriented features that go beyond the usual menu of application firewall options: URL mapping (including regular express matching) and the ability to globally prohibit direct downloading of image and multimedia files, often dubbed “leeching.” This interesting feature suggests the possibility of application firewalls eventually merging with authorization and access-control functionality to provide a complete application security framework.

For the full report, go to https://www.nwfusion.com/reviews/2003/0818rev2.html