Re: [Mod-security-developers] Positive filter modelization proposal

[Ivan R. <iv...@we...>]

Vincent Deffontaines wrote:
> Ivan Ristic wrote:

Vincent,

First of all my apologies for the extended delay.


> How do you want us to work for the better?
> We can try to provide comments about all changes we made, and why we did,
> in order to open a discussion.

That would certainly be interested. Personally I would advance by
compiling a definitive requirement list. It is something we could
use later on to test if we did all we set out to do.

Here are my original requirements:

 1. Access to some areas of a web site need not be controlled (allow all).
 2. Access to some areas of a web site must never be allowed (deny all).
 3. Web site is a collection of resources.
 4. Each resource can be used in one or more different ways (resource profiles).
 5. 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.)

 - It sounds like 4 and 5 describe the same thing.

 6. Parameters are identified by their name (choose between case sensitive
    match and case insensitive match). Parameter attributes:

    6.1. Type (query string field, body field, or file)
    6.2. Cardinality
    6.3. Character class (or a fixed range of acceptable values)
         [we will probably need to support regular expressions and
          functions here]
    6.4. Length (minimum and maximum)
    6.5. Character distribution
    6.6. Max file size (for files only)
    6.7. File type (not based on the supplied C-T, of course)

    [One change I would like to make to my own model is to make the
     attributes listed above to be standalone constraints on parameters.]

 7. Additional support for parameter arrays (dynamically created paramters) is needed.
 8. Support for parameters transported in PATH_INFO is needed.
 9. Support for parameters transported in the URI (e.g. URI append) is needed.
10. Support for parameters that come from other places, for example request
    headers and cookies.
11. Metadata. A set of rules must be wrapped somehow, signed by a
    publisher and published. Change control (e.g. serial number) needs
    to be supported.
12. Support for partial models, e.g. continuous learning.
13. Compatibility with WAPL (see http://www.modsecurity.org/projects/ppr/)
    also see the same document for ideas that related to the requirements
    listed here.
14. Integration with negative security. E.g. if a part of the model is
    weak run the request through the negative security tests. If the anomaly
    score is low use the request for learning. If it is high - don't.
16. The format must be simple enough that can be written by hand.

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
Apache Security (O'Reilly): http://www.apachesecurity.net