Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

Positive security model in ModSecurity

One of the major improvements in the next release of ModSecurity (v2.0) will be the support for a positive security model. Even now, with its flexible rule language, ModSecurity supports the positive security model. But there are areas that are not covered (e.g. automated policy generation is difficult to achieve) so I have decided to provide a complete solution for this problem.

I have been looking at the possible solutions for a positive security model for some time now. There are three ways to solve the problem:

  1. Strict and comprehensive resource and parameter checking.
  2. Statistics-based anomaly detection (a very interesting paper on this subject).
  3. Anomaly detection based on neural networks.

I have decided to start with the first option, mostly because this approach is easy to understand and allows whitelists to be created and/or updated manually. Furthermore, it may be possible to get the developers to distribute positive security model configuration files with their applications. Automated tools may be used to create these files in the first place. Below is a quick overview of what I have in mind:

  • Access to some areas of a web site need not be controlled (allow all).
  • Access to some areas of a web site must never be allowed (deny all).
  • Web site is a collection of resources (e.g. scripts).
  • Each resource can be used in one or more different ways (resource profiles).
  • Each profile needs to support a different set of parameters. (For example, one set of parameters is used when the resource is invoked with GET, another set of parameters when resource invoked with POST.)
  • Parameters are identified by their name, type (field or file), cardinality, character class (or a fixed range of acceptable values), and length (minimum and maximum).
  • Additional support for parameter arrays (dynamically created paramters) is needed.
  • Support for parameters transported in PATH_INFO is needed.
  • Support for parameters transported in the URI (e.g. URI append) is needed.

A full XML-based configuration file example is available here.