* WebScurity's webApp.secure and MultiNet's iSecureWeb
If you’re looking for a Port 80 filter, but don’t want to spend a ton of money, the Reviewmeister has two interesting products for you.
First, there’s webScurity’s webApp.secure, which attempts to bring the benefits of positive-model application firewalls within reach of smaller organizations.
Like most positive-model firewalls, webApp.secure bases its security model on a whitelist of permitted requests called Intended Use Guidelines. In webApp.secure’s case, this is a list of legal URLs for the entire site, which is built through the use of what webScurity calls “entry points.” Entry points let administrators adjust the relative “porousness” of a site/application, by forcing users to come into it through certain pages but not others, and also to control URL jumping within the site.
During configuration, entry points that the administrator has designated are treated as starting points for building the map of permitted URLs and navigational paths between them. Essentially, a trusted user (or script) must navigate from each designated entry point to all the pages that are to be treated as legally accessible from that entry point.
From this configuration-time traversal, webApp.secure learns where traffic is allowed to enter the site, and where it is allowed to go, establishing positive-model access control. In theory this should be quite useful in combating exploits that depend on URL jumping and other forceful browsing techniques.
WebApp.secure shines in protecting against form-field manipulation and in blocking the usual run of common attack signatures.
Implemented as a proxy controlled via an XML configuration file, webApp.secure also provides a native Windows GUI for administration.
Next we have MultiNet’s iSecureWeb, which is built with ISAPI technology and intended for deployment on IIS hosts. A proxy site (the “Gateway”) is set up to filter incoming requests headed to an origin site. Policy administration is done via a stand-alone interface (the “Studio”) that can be installed on a separate box. Studio is a two-pane, native Windows affair. Getting used to navigating around its multi-tab, multi-level tree view control – and learning how to make sense of it all – takes a considerable investment of time and patience.
As for the security capabilities of the default rules, common buffer overflow, the default policies handle the illicit character sequence and directory traversal attacks well.
The predominant approach is clearly negative-model, which limits the reach of the default rule set and makes post-installation configuration a must for a secure setup. At that point, considerable power is available to the administrator – especially one willing to wade through the intricacies of the user interface and, in the case of certain rules, deal with the complexities of regular expression syntax. There is probably no Web-based attack that one cannot stop with an iSecureWeb rule, if you’ve got the patience and knowledge to create and apply it properly.
For the full report, go to https://www.nwfusion.com/reviews/2003/0818rev2.html
