coreruleset: 942310 regular suspected error
Describe the bug
There may be a problem with [\“'`]\s+and\s*?=\W in the 942310 rule. You can view this part in the /util/regexp-assemble/regexp-942310.data file. By analyzing the regularity, There can only be \s
between [\”'`] and and
, and \w
cannot be after and, such as " and =;
, but I check related payloads such as: AND 1=1 AND '%'='
Unable to be hit, more related payloads can refer to:
https://github.com/payloadbox/sql-injection-payload-list ,
https://www.netsparker.com/blog/web-security/sql-injection-cheat-sheet/ .
Maybe I didn’t find the corresponding detection payload, let’s take a look at it together~
Steps to reproduce
Expected behaviour
Actual behaviour
Additional context
Your Environment
CRS version v3.4/dev
- CRS version (e.g., v3.2.0):
- Paranoia level setting:
- ModSecurity version (e.g., 2.9.3):
- Web Server and version (e.g., apache 2.4.41):
- Operating System and version:
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 21 (21 by maintainers)
Commits related to this issue
- Remove nonsensical regular expression from rule 942310 Fixes #2118 Also adds a couple more tests for 942310 — committed to fritexvz/coreruleset by NiceYouKnow 3 years ago
I just spent some time with this too. The longer I look at it the more it seems to me that the expression contains at least one typo. For the expression to match there must be an engine accepting something like
AND =
which doesn’t make sense because there is no left hand side to the=
. Unless there existed a “boolean compound assignment” somewhere (e.g.x := y AND= z
).While the idea of compound operators sounded promising at first, I haven’t been able to find any operator where the
=
is the the first of the two characters. In every dialect the=
is always the last character of the compound operator. Even if there where such an operator, the observation above still holds: there would be no left hand side to the operator.In conclusion, I think the odds of opening us up to an attack are slim (even if there were an exploit, it doesn’t seem to be widely known) and I think we should remove the expression.
Thanks @NiceYouKnow, these kinds of issues are so hard to find and we really need the support of CRS users to help us improve the quality of the rules.
I looked up the relevant information and found nothing to match. https://github.com/payloadbox/sql-injection-payload-list https://www.netsparker.com/blog/web-security/sql-injection-cheat-sheet/
https://twitter.com/AndreaTheMiddle/status/1427618583354413076?s=20
This is a bit of a guess, but maybe it’s helpful…
The oldest comments I could find that are related to this regular expression gave some “Example Payloads Detected” which made use of compound assignment, e.g.
aa" =+ - "0
That made me wonder if the
=\W
part of the regex was designed to catch=+
and=-
. Could it be looking for payloads like' AND =+ 1
?@franbuehler, The modified rule should be 942310, not 942400, ^~^. I’ll submit PR later.
I searched all source files for
and
.The regexes that contain
and
and detectAND 1=1 AND '%'=' are
:regexp-942400.data:\band\b\s+\d{1,10}\s*?[=<>] regexp-942400.data:\band\b\s+‘[^=]{1,10}’\s*?[=<>] regexp-942400.data:\band\b\s+\d{1,10} regexp-942400.data:\band\b\s+‘[^=]{1,10}’ regexp-942400.data:\band\b ?\d{1,10} ?[=<>]+ regexp-942400.data:\band\b ?['"][^=]{1,10}['"] ?[=<>]+
Rule 942400 is at PL2.
We have to discuss if we want to extend the detection at PL1 or PL2 is enough…
Hi again @NiceYouKnow 👋
Thanks again for your very welcome issue! We’ll investigate it shortly.