Just to followup on this:
Modsecurity is notorious for triggering false positives. The SQL Injection rules in particular are very prone to this. Modsecurity also takes some work to configure for your server, you can’t just install it and forget it or you will have a much higher chance of running into problems that are not really problems. If you are running Modsecurity on your server, then you will need to periodically monitor the logs and adjust the CRS rules as necessary.
The first thing to do with Modsecurity is switch to anomaly scoring rather than setting the default action to Deny, this will drastically cut down on the number of false positives you get.
Second, you will need to run Modsecurity in DetectionOnly mode and tune the CRS rules before they become useful…and this takes time, sometimes several months of iterations before you can reliably switch it on to blocking mode.
For example, Site Reviews v3.1.6 fixes a potential Modsecurity false positive where the contents of the PHP Session cookie was being flagged by some servers with Modsecurity enabled as a high-risk SQL injection attack. You can read more about this issue here.
Now, a PHP Session cookie is not a regular cookie, it simply references a SESSION on the server using a unique session ID and an expiry timestamp. In Site Review’s case, the content of the session cookie goes something like this:
[RANDOMLY_GENERATED_STRING_FOR_THE_SESSION_ID||[EXPIRY_TIMESTAMP]||[EXPIRY_RESET_TIMESTAMP]
For example:
f1348d75e7764ae938dcf4357e9a19f1||1547417923||1547417563
Now, the problem here was that the 1||1 part was being detected as a SQL command (i.e. 1 OR 1) which was triggering the SQL injection error in Modsecurity. Obviously that is absurd, the || bits were simply acting as string separators. Also since the first part of the string (the session ID) was randomly generated, only some of the time would it end in a “1” which would throw the Modsecurity error.
To fix this, Site Reviews v3.1.6 now separates the three parts of the SESSION cookie content with __ instead of ||.
For example:
f1348d75e7764ae938dcf4357e9a19f1__1547417923__1547417563
@nepalpyramids To answer your question, the way to fix Modsecurity false positives is to add custom rules/exceptions to your modsec config.
For example, in the Site Reviews example above, this was the modsecurity error:
ModSecurity: Warning. detected SQLi using libinjection with fingerprint 'n&1' [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "43"] [id "942100"] [rev "1"] [msg "SQL Injection Attack Detected via libinjection"] [data "Matched Data: n&1 found within REQUEST_COOKIES:_glsr_session: f1348d75e7764ae938dcf4357e9a19f1||1547417923||1547417563"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "8"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] [hostname "rgpvtranscripts.com"] [uri "/"] [unique_id "XDuyP1V58gUkpQnNW14QXQAAAQc"]
To fix this, here is the rule you would add to your modsec config:
SecRuleUpdateTargetById 942100 "!REQUEST_COOKIES:_glsr_session"
You could also skip all ModSecurity warnings with an ID of 942100 like this:
SecRuleUpdateTargetById 942100
I hope this helps someone.
