Audit Log Part E (response body) is logged for no obvious reason

Describe the bug

The audit log part E (response body) is often logged where there is no obvious reason it should be logged. For example, on a service where audit log part E is disabled, a request exceeding PCRE limits would log the E part despite no rule being triggered adding this part to the audit log.

Steps to reproduce

1. Configure SecAuditLogParts to not use log part E.
2. Execute request that ends up in audit log without triggering a rule explicitly adding the audit log part E using ctl:auditLogParts=+E
3. The audit log will contain the audit log part E anyway.

Expected behaviour

The audit log should not contain the audit log part E for the request described above.

Actual behaviour

The audit log does contain the audit log part E for the request described above.

Additional context

There are chained rules in CRS where the audit log part E is added because it is relevant to the rule that is triggered: ctl:auditLogParts=+E.

Some of these rules are chained rules. For chained rules the audit log part is added in the base rule, not the chained rule. For example:

SecRule ARGS "@rx ^(?i:file|ftps?|https?)://(?:[^@]+@)?([^/]+)" \
    "id:931130,\
    phase:2,\
    block,\
    capture,\
    t:none,\
    msg:'Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link',\
    logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
    tag:'application-multi',\
    tag:'language-multi',\
    tag:'platform-multi',\
    tag:'attack-rfi',\
    tag:'OWASP_CRS',\
    tag:'capec/1000/152/175/253',\
    tag:'paranoia-level/2',\
    ctl:auditLogParts=+E,\
    ver:'OWASP_CRS/4.0.0-rc1',\
    severity:'CRITICAL',\
    setvar:'tx.rfi_parameter_%{MATCHED_VAR_NAME}=.%{tx.1}',\
    chain"
    SecRule TX:/rfi_parameter_.*/ "!@endsWith .%{request_headers.host}" \
        "setvar:'tx.rfi_score=+%{tx.critical_anomaly_score}',\
        setvar:'tx.inbound_anomaly_score_pl2=+%{tx.critical_anomaly_score}'"

According to the documentation for chaining rules (chain), some non-disruptive actions will be executed on non-disruptive rules (most CRS rules are non-disruptive) even if the chained rules are not satisfied:

Non-disruptive rules can be used in any rule; they will be executed if the rule that contains them matches and not only when the entire chain matches.

Indeded, if ctl:auditLogParts=+E is moved to the chained rule, the problem disappears. For example:

SecRule ARGS "@rx ^(?i:file|ftps?|https?)://(?:[^@]+@)?([^/]+)" \
    "id:931130,\
    phase:2,\
    block,\
    capture,\
    t:none,\
    msg:'Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link',\
    logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
    tag:'application-multi',\
    tag:'language-multi',\
    tag:'platform-multi',\
    tag:'attack-rfi',\
    tag:'OWASP_CRS',\
    tag:'capec/1000/152/175/253',\
    tag:'paranoia-level/2',\
    ver:'OWASP_CRS/4.0.0-rc1',\
    severity:'CRITICAL',\
    setvar:'tx.rfi_parameter_%{MATCHED_VAR_NAME}=.%{tx.1}',\
    chain"
    SecRule TX:/rfi_parameter_.*/ "!@endsWith .%{request_headers.host}" \
        "ctl:auditLogParts=+E,\
        setvar:'tx.rfi_score=+%{tx.critical_anomaly_score}',\
        setvar:'tx.inbound_anomaly_score_pl2=+%{tx.critical_anomaly_score}'"

[fzipi]

Thanks for reminding me. I think we are good! Closing.

[studersi]

@fzipi Do we need anything else here or can we close the this issue?