Headline
CVE-2020-22669: SQLi using set var at PL2 by theMiddleBlue · Pull Request #1793 · coreruleset/coreruleset
Modsecurity owasp-modsecurity-crs 3.2.0 (Paranoia level at PL1) has a SQL injection bypass vulnerability. Attackers can use the comment characters and variable assignments in the SQL syntax to bypass Modsecurity WAF protection and implement SQL injection attacks on Web applications.
We run it a bit further and it actually started to trigger on scans :D Appear to overlap slightly with 942190, but it may be because it was a complex payload.
Sorry, I can’t understand this statement. Can you attach an example?
The actual exemples are redacted, but not too hard to imagine: you just need to following expression somewhere in the password: @[\w\d]+=\S. For exemple, @4=d which could quite likely appear in a randomly generated password. The password you suggested is deliberately malicious, the exemple we’re having here is similar to sh somewhere in a randomly generated string triggering an SHI rule.
I agree that free text is a challenge but we can’t completely ignore it: contextualizing the rules enable fewer edge cases and wider usage. For some rules, it’s highly complex, for this one it doesn’t feel so.
Please, if you can share them it would be really helpful to improve this rule
I’m seeing payloads like this, although not sure where they come from: redacted@blablav=website.com
Based on my tests, this is not true by using set variable = syntax
Thanks a lot for the rationale, that makes a ton of sense! Could you add it in the rule’s header to explain where this design came from? Will likely be useful in the future!