owasp-modsecurity
Recommended rule 200005 misses MSC_PCRE_LIMITS_EXCEEDED in phase 2
Describe the bug
The recommended rule 200005 runs too early to catch most MSC_PCRE_LIMITS_EXCEEDED flags that happen in phase 2.
Logs and dumps
To Reproduce
Expected behavior
The rule 200005 should block all MSC_PCRE_LIMITS_EXCEEDED that occur during request processing, even in phase 2.
Server (please complete the following information):
- ModSecurity version (and connector): all affected
- WebServer: all affected
- OS (and distro): all affected
Rule Set (please complete the following information):
- Running any public or commercial rule set? OWASP CRS
- What is the version number? all affected
Additional context
Since the ModSecurity Recommended Rules provide rules to activate body parsers etc., they need to be included before other rule sets like the Core Rule Set.
Error flags like MSC_PCRE_LIMITS_EXCEEDED are set by rule sets like the CRS.
However, since the the rule 200005 has already run at the start of phase 2, any rule from rule that also runs in phase 2 but is included after the recommended rules (which is typically the case for other rule sets because they rely on body parsing rules) can never trigger rule 200005.
Therefore, rule 200005 misses almost all MSC_PCRE_LIMITS_EXCEEDED that happen in phase 2.
Proposed solution It's not entirely clear, what a solution would look like. Moving rule 200005 to a later phase would probably not be a good idea, since it would allow the request to be processed before blocking.
A better approach would probably be to move the rule 200005 to be included after rule sets like the CRS. However, this would also mean, it would have to be removed from the Recommended Rules to be moved somewhere else or the Recommended Rules would have to be split up into multiple files that are included before and after other rule sets.
Hi @studersi,
thanks for bringing up this topic.
Proposed solution It's not entirely clear, what a solution would look like. Moving rule 200005 to a later phase would probably not be a good idea, since it would allow the request to be processed before blocking.
Agreed.
A better approach would probably be to move the rule 200005 to be included after rule sets like the CRS. However, this would also mean, it would have to be removed from the Recommended Rules to be moved somewhere else or the Recommended Rules would have to be split up into multiple files that are included before and after other rule sets.
Yes, that would be a possible solution, but honestly, I'm fairly sure that this is almost impossible to implement (I don't believe that users change their modsecurity.conf).
We definitely must discuss about this topic.
Note, that in CRS we already talked about this, see coreruleset/#2390. But finally we transferred the issue to ModSecurity because we didn't have enough capability to take care of that. But the plan was this:
- 200005: Leave it intact and add new, second internal error (PCRE match limit error) detection rule in the 949xxx range/file as a scoring rule (Probably 949040; it is not really a detection rule and we want to make sure it really happens right before 949110).
(see the initial comment).
May be we can add a new, optional config file and draw users' attention to use that if they want to tune their WAF.
I see, thank you for the additional context.
Was there ever a discussion about simply merging the recommended rules into CRS completely and deprecating them here (without actually removing them)?
I assume, this would allow much more flexibility with respects to changing the behavior of the Recommended Rules and weaving them into the rest of the rule set.
Given that the rules of the Recommended Rules would likely receive new IDs to be in line with the rest of CRS, they could live alongside each other without issues.
For people that do not use CRS, nothing would change as current version of the Recommended Rules could still be shipped (though perhaps with a deprecation warning). For people that do use CRS, they could profit from the improved behavior of the CRS version of the Recommended Rules. And since the CRS version of the recommended rules would be a full replacement of the current version of the Recommended Rules, they could ignore/remove them entirely.