Planned usability improvements for ModSecurity 2.6

After leaving Breach Security in February I took a break from ModSecurity. On the one hand, I was tired. On the other, I needed time to figure out what role I will have in the project, or if I wanted to have a role at all. Over time my interest in ModSecurity started to come back. Even more interestingly, I started to look at it with a fresh perspective. What would a newcomer make of it? In doing so I came up with a long list of small problems that need fixing. The beauty of my new position (a contributor) is that I no longer need to think where the project is heading next, but can spend as much (or little) time as I like working on the things that I have interest in.

Here's my list:

1. It is not clear what happens when an operator fails. I think a level 1 error message is emitted, but there is no effect on rule processing. This is a small anomaly that needs fixing. I believe the user should be given an option to be strict (block) or relaxed (not block). [MODSEC-12]
2. The variable REQUEST_URI is used directly from the Apache's structures. As a consequence the value may change between phases. ModSecurity should have one robust variable that refers to a path, to avoid small problems. The MODSEC-98 improvement fixed this issue.
3. At the moment we provide a raw REQUEST_URI and expect the users to use transformation functions to deal with evasion. That is inconveniencing our users; we should have REQUEST_URI pre-normalised. And, because we rely on Apache for normalization at the moment, doing normalization ourself would give use better control over the process and increase consistency. (For example, Apache does not always do the right thing when deployed in proxy mode.)
4. The REQUEST_BODY variable contains request bodies, but the variable is only available when the for urlencoded bodies. This is because in most cases it doesn't make any sense to store the entire request body in memory (think file uploads). There's a hack to force a request body into memory (ctl:forceRequestBody), but we need to provide a consistent way to deal with the inspection of request bodies.
5. Phase information should not be allowed in SecDefaultAction. That is something for rules to be concerned about.
6. Transformation options should not be allowed in SecDefaultAction, because transformations need only be configured on the per-rule basis. In fact, the entire situation with how SecDefaultAction works is murky and needs improvement.
7. SecArgumentSeparator should not be a main-only directive.
8. SecComponentSignature should not be a main-only directive.
9. ModSecurity should refuse to accept the rules that use variables in phases when they are not available. Why wait for the users to discover the problem the hard way?
10. There's no reason that non-existent response types are specified with "(null)". We should change that to "null", keep the old variant, but remove it from the documentation. This had been fixed, but I missed it.
11. The performance-tracking information (Stopwatch) -- which was just copied over from ModSecurity 1.9.x -- does not provide useful performance measurement. Done. Implemented Stopwatch2, which is a great improvement.
12. The users have been complaining about an elusive mod_deflate compatibility issue for ages now. It needs fixing. Done (MODSEC-89).
13. Allow main and virtual host configuration and phase 1 rules to be overridden in <Location> configuration contexts. Done (MODSEC-98).
14. Use international-friendly spelling: change "sanitise" to "sanitize". Done (MODSEC-95).
15. Use international-friendly spelling: change "normalise" to "normalize". Done (MODSEC-103).
16. Remove the obsolete PDF UXSS functionality. Done (MODSEC-96).

Comments

[Matthieu]

Reading the beginning of the post make me think that modsecurity is a drug !!!

But a good one :)

[Christian Folini]

That is a nice list of things. I get the impression, that there is a spelling error (negation missing) error in item 6. I am particularly fond of item 3, 12 and 13. Glad the latter is fixed already.

If there is room for anything else, then I would like to see "ctl:ruleUpdateActionById" and similar updates to message, severity, redirect, status etc. This would be very powerful updates. Especially if you could reference the former message in the update...

Maybe this is blowing up the ctl action syntax: It could become too complicated. I can't think of a better way that confoms to the Apache config style syntax though.

Otherwise, I am really forward to 2.6.0 expecting very nice improvements. It is this polish, that will make ModSecurity shine.

Cheers,
Christian