0

My site turns on Ubuntu 16, Apache 2.4, php 5.6 and I use the CMS Drupal 8

I installed the module mod_security. I activated it then I enabled the modsecurity_crs_41_sql_injection_attacks.conf.

For each form, when I submit, I have an error 403 forbidden

Can You explain to me why all submit forms are forbidden

Edit: Add Apache error log

[Wed Nov 15 16:53:03.324516 2017] [:error] [pid 27760] [client] ModSecurity: Access denied with code 403 (phase 2). 
 Pattern match "([\\\\~\\\\!\\\\@\\\\#\\\\$\\\\%\\\\^\\\\&\\\\*\\\\(\\\\)\\\\-\\\\+\\\\=\\\\{\\\\}\\\\[\\\\]\\\\|\\\\:\\\\;\\"\\\\'\\\\\\xc2\\xb4\\\\\\xe2\\x80\\x99\\\\\\xe2\\x80\\x98\\\\`\\\\<\\\\>].*?){4,}" 
 at ARGS_NAMES:field_cl_address[0][format]. 
 [file "/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] 
 [line "159"] [id "981173"] [rev "2"] 
 [msg "Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded"] 
 [data "Matched Data: ] found within ARGS_NAMES:field_cl_address[0][format]: field_cl_address[0][format]"] 
 [ver "OWASP_CRS/2.2.9"] [maturity "9"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [hostname "www.d8.dev.xxxx"] [uri "/node/add/occlient/19784"] [unique_id "Wgxw738AAQEAAGxw91sAAAAO"]
  • 1
    No we cannot. You need to look at your Apache error logs which will tell you which CRS rule is firing. If you need help understanding that then please include the relevant log entries or do a search for that rule id. SQL injection rules are notorious for creating false positives and need to be turned to not run for certain parameters that look like SQL injection rules. See here for more details: serverfault.com/questions/690460/… – Barry Pollard Nov 15 '17 at 16:34
  • Thanks, I updated my question in order to insert the log – Mohamed Ben HEnda Nov 15 '17 at 16:58
3

OK let's break it down.

Rule 981173 is the rule that's causing the problem. It is flagging because

"Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded"

It even tells you the field that is the problem:

[data "Matched Data: ] found within ARGS_NAMES:field_cl_address[0][format]: field_cl_address[0][format]"]

The way this rule runs is by running a very long regular expression on each field and it checks for 4 or more special characters (including [ and ]). Fields with lots of special characters can indicate that someone is trying to get around basic checks that servers or software might do, by obfuscating a bad pay load or escaping characters.

For you however your field names include 2 [ characters and 2 ] characters, which equals the 4 special character limit and hence every request gets blocked. This rule, as it stands, is of no use to you to protect that form because of this.

The OWASP Common Rule Set (CRS) is a set of rules is a set of suggested rules, that will not suit every site and do need to be tuned before you should switch them on in blocking mode.

In version 3 of the CRS, rule 981173 was renumbered to rule 942430 (the rules were renumbered as part of the move to version 3 for reasons I won't go into here) and they increased the number of special characters which had to match from 4 to 12 to avoid false positives like this. To be honest if you are just installing the CRS for the first time then you should move to version 3 first as they did a LOT of work in making it easier to install and avoid false positives like this.

If you want to stay on version 2.9 for now then your choices are:

  1. Stop using this rule by including the following config:

    SecRuleRemoveById 981173

  2. Stop checking this particular field by including the following config:

    SecRuleUpdateTargetById 959071 !ARG_NAMES:'field_cl_address[0][format]'

  3. Manually edit the rule to change the {4,} it to {12,} so you need many more matches before this rule fires. Usually editing the rules directly is not recommended and instead it's better to have an override conf file, and use that to alter the rules - like in the first two examples. Unfortunately there is no way to alter a rule ids regular expression so manually editing is the only option (or turn that rule on, and copy it to a new rule with the tweaks in your override config).

It may seem odd at first to turn OFF rules, but that is exactly what fine tuning the rule set in ModSecurity means - turning off those rules that are not useful for you, or tweaking them not to fire on certain known fields. Does it reduce the security offered by ModSecurity and the CRS? Yes a bit, but a totally secure site that doesn't work isn't that useful, and some modificiations of the CRS (and in particular the SQL Injection rules) is needed for all but the simplest sites.

Rule 981173 is a rule I usually turn off completely because it's so prone to false positives. I wrote this post a while ago about other common tweaks I make to stop CRS 2.9 overly blocking: https://stackoverflow.com/questions/33989273/modsecurity-excessive-false-positives#answer-34027786

Finally, I really recommend the ModSecurity Handbook (recently updated to second edition) to learn more about how this all works: https://www.feistyduck.com/books/modsecurity-handbook/

0

Thanks @BazzaDP

I follow your suggestions and it is running well.

Also, I removed some other rules ID

<IfModule security2_module>
                        SecRuleRemoveById 973300
                        SecRuleRemoveById 981245
                        SecRuleRemoveById 981248
                        SecRuleRemoveById 981173
                        SecRuleRemoveById 981231
                        SecRuleRemoveById 950901
                        SecRuleRemoveById 981260
                </IfModule>

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.