Hi!
This is a juicy one.
Rule in 2.2.9:
SecRule RESPONSE_STATUS "^5\d{2}$"
"phase:4,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,capture,ctl:auditLogParts=+E,block,msg:'The
application is not available',logdata:'Matched Data: %{TX.0} found within
%{MATCHED_VAR_NAME}:
%{MATCHED_VAR}',id:'970901',tag:'WASCTC/WASC-13',tag:'OWASP_TOP_10/A6',tag:'PCI/6.5.6',severity:'3',setvar:'tx.msg=%{rule.msg}',setvar:tx.outbound_anomaly_score=+%{tx.error_anomaly_score},setvar:tx.anomaly_score=+%{tx.error_anomaly_score},setvar:tx.%{rule.id}-AVAILABILITY/APP_NOT_AVAIL-%{matched_var_name}=%{tx.0}"
Rule in 3.0.0rc1:
SecRule RESPONSE_STATUS "^5\d{2}$" \
"phase:response,\
rev:'3',\
ver:'OWASP_CRS/3.0.0',\
maturity:'9',\
accuracy:'9',\
t:none,\
capture,\
ctl:auditLogParts=+E,\
block,\
msg:'The Application Returned a 500-Level Status Code',\
logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}:
%{MATCHED_VAR}',\
id:'950100',\
tag:'application-multi',\
tag:'language-multi',\
tag:'platform-multi',\
tag:'attack-information disclosure',\
tag:'WASCTC/WASC-13',\
tag:'OWASP_TOP_10/A6',\
tag:'PCI/6.5.6',\
severity:'ERROR',\
setvar:'tx.msg=%{rule.msg}',\
setvar:tx.outbound_anomaly_score=+%{tx.error_anomaly_score},\
setvar:tx.anomaly_score=+%{tx.error_anomaly_score},\
setvar:tx.%{rule.id}-AVAILABILITY/APP_NOT_AVAIL-%{matched_var_name}=%{tx.0}"
Obviously we check the HTTP response status code and trigger an alert on
a status 500. It is one of the rare rules with anomaly score error (=4)
as opposed to critical (=5).
Franziska thinks this is too generic and cloaks backend misbehaviour.
(If you have a problem with the error page, then replace it!), but let's
not hide the fact of the error from the client.
Now Walter thinks this rule plays a role when defending against blind
attacks where the difference between 403 (likely blocked by ModSecurity)
and 500 (passed ModSecurity, but crashed on backend) gives an attacker
important information.
Initially, I wanted to push this rule into paranoia mode. But now I am
not so sure anymore for Walter does have a point.
However, the inexperienced administrator could have a hard time
indentifying the 403 status as a backend failure. So maybe it is still
a paranoia candidate despite it's supportive role when defending against
blind injection attacks.
More brain cycles are definitely needed here!
Christian
--
mailto:christian.fol...@netnea.com
http://www.christian-folini.ch
twitter: @ChrFolini
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
