Portable Web Application Firewall Rule Format News

Posted by ivanr on August 23, 2005.

As some of you may know, I've been working on the portable web application firewall (WAF) rule format for ages. I really believe the concept has potential so I keep coming back to it, making it a little bit better on every visit. At the same time I am closely listening to the WAF market, hoping to jump in with the format just at the right time. Although I can (and will) implement the format in ModSecurity, what I really want is to get as many WAF vendors on board to support the format. That may not be the easiest thing to do so the timing is of real importance.

The idea behind the project is to design a portable WAF rule format capable of "fixing" the known security issues in web applications. While the only proper solution is always to fix the root cause of a security issue, we must acknowledge that the fix can not be implemented straight away (for all sorts of reasons, some legal, some technical, some practical). It is all about minimising the window of opportunity - we want to be able to prevent exploitation of a vulnerability practically as soon as it is discovered.

There are four usage scenarious (I am using the term recipe to refer to a unit of knowledge that contains enough information to prevent vulnerability from being exploited):

Vendor-provided recipes; While vendors may very well provide prompt upgrades and patches, not everyone can upgrade swiftly. Vendors may come to recognise this and decide to release protection recipes at the same time with the upgrades.
Third-party recipes; Providing there is strong demand, third-parties may decide to offer protection recipes, for free or for a fee.
Recipes written by hand; Larger environments may have many different brands of protection devices on their networks. Promoting a single format would enable knowledge to be shared in such environments.
Automated recipe generation; It is sometimes not feasible nor practical to manually assess security in web applications. It is possible to get assessment tools to talk directly to protection devices. A web vulnerability scanner that discovers a problem is likely to know enough about it to be able to create a recipe as a temporary measure. Such recipe could be installed manually, or after it is review by the system administrator or the application developer.

Several big improvements were made to the format in the last iteration:

Specification formalised; Unlike before, when one had to rely on my notes to understand the specifics of the project, this time you will be presented with a formal specification (in draft, of course). The specification explains the motivation behind the effort and the technical aspects.
Metadata included; The format was expanded to include recipe metadata. While the metadata is not very important for those who write recipes by hand, it is very important to allow for automation.
Communication protocols added; A whole new section was added introducing recipe publishing, repositories, and the corresponding communication protocols.

To conclude, the project is now close to its first official release. Allowing some time for feedback from the interested parties, in the next step a "release candidate" specification will be released at the same time as the Java-based reference implementation.

Posted by ivanr at 09:37 AM

Major updates to ModSecurity in 1.9dev3

Posted by ivanr on August 19, 2005.

This version implements the final batch of major improvements to the 1.9.x series. These include a completely new audit logging subsystem intended for real-time audit log aggregation, audit logging based on response status code, support for PUT uploads, stateful denial of service defence through httpd-guardian (an external monitoring process), significantly improved support for rule inheritance (import from parent context, remove from current context, mandatory inheritance, etc.), and many smaller improvements.

The new version is available for immediate download. I'll follow up soon with in-depth explanations of a few of the more exciting features.

Posted by ivanr at 09:54 AM

Improvements to the Servlet specification

Posted by ivanr on August 08, 2005.

A while ago Greg Murray (the Servlet specification lead) asked for ideas for Servlet improvements. I generally like the Servlet specification, but it seems that it is easy to encounter its limitations if you are trying to do things others have not tried before. My ideas for improvements come from my work on the Java version of ModSecurity (still work in progress):

Server-wide filters/plugins. Servlet filters are a pretty capable technology but they are an application-level feature. I think it's ironic that we can add plug-ins to applications but that we still don't have a plug-in standard for Java web servers.
Server-controlled buffering. Right now it is the application that controls buffering. In some cases (for example when you want to screen all output for security reasons) it is necessary to force buffering upon an application. This is possible to do now, with a filter, but it's not very efficient since buffering is done twice - once in the container and once in the filter. A configuration switch to enforce buffering, together with ability to have direct access to the buffer in the container would possibly offer significant performance enhancements.

Posted by ivanr at 11:21 AM