Don’t let 981172 and 981173 disappear from the Core Rules! 2

This is a blog post about the OWASP ModSecurity Core Rules.

The rule 981173 was recently updated in the 2.9 core rule branch to reduce the uuid induced false positives for the rule.

Uuids are indeed a major source of false positives on this rule, also in installations I know.

The said update pulled in a request which raised the limit of acceptable number of special characters from 3 to 4. This is the rule as it stands now with “{5,}” meaning an alert is triggered when 5 special chars are detected.

https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/263


SecRule ARGS_NAMES|ARGS|XML:/* "([\~\!\@\#\$\%\^\&\*\(\)\-\+\=\{\}\[\]\|\:\;\"\'\´\’\‘\`\<\>].*?){5,}"
"phase:2,t:none,t:urlDecodeUni,block,id:'981173',rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'8',msg:'Restricted SQL Character Anomaly Detection Alert - Total
# of special characters exceeded',capture,logdata:'Matched Data: %{TX.1} found within %{MATCHED_VAR_NAME}:
%{MATCHED_VAR}',tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.sql_injection_score=+1,setvar:'tx.msg=%{rule.m
sg}',setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/RESTRICTED_SQLI_CHARS-%{matched_var_name}=%{tx.0}"


I think coping with the uuid problem is a good idea. But raising the limit seems a poor handling of the false positives, when a whitelisting of the uuid pattern like

[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}
or simpler
^[0-9a-f-]{36}$

would have been enough.

It’s true, that 981173 and it’s ally 981172 are gone with the upcoming 3.0.0 release. So maybe this little update is not very significant. But I think it is.

And I think 981173 and 981172 should stay. Not only because of SQLi, But because they are the guardsmen doing a lot of dirty work for many installations beyond SQLi. In many, many occasions, when there is something amiss with a request, 981172 and 73 will issue an alert. The false positive rate is high, I admit. But in my experience, many attackers managed to evade most other rules, but these two guardsmen still alerted. Remember 981173 used to alert on the occurrence of 4 special characters in a parameter. So I would argue, that the false negative rate of 981172 and 981173 is lower than with other rules.

The two rules come with an anomaly score of “warning”. That’s fair given the high false positive rate and still enough to examine their alarms.

So I propose to include them into 3.0.0 as well. I think there is still some room in REQUEST-42-APPLICATION-ATTACK-SQLI.conf for these two guys. I plan to issue a pull request to accomplish this.

Christian Folini Follow @ChrFolini Tweet