Rule 920450 and modsec 3x about owasp-modsecurity-crs HOT 4 CLOSED

Hi @mirkodziadzka-avi, thanks for the report. Yes, this is an "old" and "know" problem, and guess you saw the PR for modsec 3x :).

I'll review the whole rule set for all occurrence of TX:UPPER_CASE_VARIABLES, and make a PR for this issue - or feel free to make it.

Anyway (just for the sake of completeness), there is an another way to fix (but I'm sure your suggestion is more elegant and clear of course).

diff --git a/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf b/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
index 880c8c4..666f59b 100644
--- a/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
+++ b/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
@@ -1130,7 +1130,7 @@ SecRule REQUEST_HEADERS_NAMES "@rx ^.*$" \
     severity:'CRITICAL',\
     setvar:'tx.header_name_%{tx.0}=/%{tx.0}/',\
     chain"
-    SecRule TX:/^HEADER_NAME_/ "@within %{tx.restricted_headers}" \
+    SecRule TX:/(?i)^HEADER_NAME_/ "@within %{tx.restricted_headers}" \
         "setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
 
 

from owasp-modsecurity-crs.

First, there is a new PR which fixes this bug.

I did some research on how we use the TX variables in SecRule's.

There are 3 rule, where the variable contains a regex:

920450:

921180:

931130:

Only this one (920450) where the variable name is with uppercase.

But there are many other occurrance of TX:VARIABLE, and in most cases the names are typed with uppercase too. Eg: TX:EXECUTING_PARANOIA_LEVEL, TX:PARANOIA_LEVEL, TX:INBOUND_ANOMALY_SCORE... Perhaps that's why the author created it like this.

I think using of this form contradicts the naming convention.

Any opinion?

I'm going to make a PR for this issue soon.

from owasp-modsecurity-crs.

But there are many other occurrance of TX:VARIABLE, and in most cases the names are typed with uppercase too. Eg: TX:EXECUTING_PARANOIA_LEVEL, TX:PARANOIA_LEVEL, TX:INBOUND_ANOMALY_SCORE... Perhaps that's why the author created it like this.

Yes. But for normal access TX:foo and TX:FOO was always be the same (case insensitive). And modsec did not change the behaviour. As far as I know this is true for all collections. And I can see a reason why this is (was?) a good thing to do.

I can also find a reason why regexes should be case sensitive by default. Although I do not know if the change between modsec 2 and 3 is on purpose or by accident.

By the way, thanks for the fix

from owasp-modsecurity-crs.

Yes. But for normal access TX:foo and TX:FOO was always be the same (case insensitive). And modsec did not change the behaviour. As far as I know this is true for all collections. And I can see a reason why this is (was?) a good thing to do.

sure, that's no problem, it works as well.

I can also find a reason why regexes should be case sensitive by default. Although I do not know if the change between modsec 2 and 3 is on purpose or by accident.

I just found a short text about this behavior in documentation:

Variable names are case-insensitive.

So because it doesn't matter the variable is with lower or uppercase, if the rule references that with a regex, there also no matter - I assume this is an accident.

By the way, thanks for the fix

You're welcome.

from owasp-modsecurity-crs.