Cross-Compatible JSON Body Exclusion Ruleset for Different ModSecurity Versions

Hello everyone,

Description:
I've come across an issue while working with different versions of ModSecurity (v2 and v3) and their respective variable names when parsing JSON bodies using the JSON body processor.

Problem:
The crux of the problem lies in the fact that v2 and v3 of ModSecurity employ distinct variable names during JSON body parsing. This discrepancy becomes particularly challenging when attempting to create an exclusion ruleset that works seamlessly across all ModSecurity versions. Currently, the only two viable options are duplicating ctl:remove* actions or duplicating rules. However, both of these alternatives demand more CPU consumption than necessary (other than possible -still unknown- security implications/bypass).

Example:
To illustrate this issue further, consider the following JSON body:

{"foo": [{"bar":"payload"}]}

In v2, the corresponding variable name would be: ARGS:foo.foo.bar
While in v3, it becomes: ARGS:json.foo.array_0.bar

If I'm not wrong, this means that I need a rule exclusion like:

SecRule REQUEST_URI "@beginsWith /mypath" "id:1234,\
  ctl:ruleRemoveTargetByTag=OWASP_CRS;ARGS:foo.foo.bar,\
  ctl:ruleRemoveTargetByTag=OWASP_CRS;ARGS:json.foo.array_0.bar,\
  ..."

If the array within the "foo" object in my example comprises 100 entries, it's quite clear that this would necessitate either 200 ctl actions or two distinct rules.

Are there other ways to do this?

If not: Proposed Solution

• add an ARGS:json variable like v3 on v2
• abstract the ARGS names on rule definition in order to have only 1 syntax
• use JSON path syntax like: $.foo[0].bar or ARGS:json.foo[0].bar and would be awesome an ARGS:json.foo[].bar to select all entries of the "foo" array

Start by comparing how ModSecurity v2 and v3 name variables produced by the JSON body processor, then review the current ctl:removeTarget and rule-target syntax described in the issue. Done would require a maintainer-approved, cross-version exclusion approach or a clear decision that the proposed abstractions are not feasible.