Add word boundaries around values in SQL tautologies (942130) · Issue #1710 · coreruleset/coreruleset · GitHub
More Web Proxy on the site http://driver.im/
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue for tracking original pull request created by user allanrbo on date 2020-03-04 08:50:46.
Link to original PR: SpiderLabs/owasp-modsecurity-crs#1710.
HEAD is: 023ce59
BASE is: 3aa260d
The intention of this rule appears to be to find situations such as 1=1, 123=123, 1!=2, 123!=321, 'hello' NOT LIKE 'world'. SQL expressions that will always evaluate to true - aka. tautologies.
However, I believe the rule had a flaw. For example it would match 11=1, 1=11, and fail to match 1!=11. I believe the reason is because the backreference \1 was given too much flexibility on what it could match. So for example given 11=1, when the regex engine arrives at the backreference, it seems to have the freedom to choose just any permutation of the referred capture group, so instead of choosing the whole 11, it can simply just choose 1. I think maybe the possessive quantifier ++ was an attempt to solve this problem, but it doesn't work. I believe a solution is lock down this freedom by explicitly forcing word boundaries around the capture group ([\d\w]+), so it becomes \b([\d\w]+)\b. Likewise around the \1 backreference.
The existing test case "1" sSOUNDS LIKE "SOUNDS LIKE 1 it appears to me just kind of passed by chance, because of the above described bug. It would match so \1 became SOUNDS, and then refer back to sSOUNDS but just choose the permutation of ignoring the first lower case s. Experiment here: https://regex101.com/r/hyI0Iv/1 .
This fix also has the side effect of solving the perf issue Airween brought up on the Slack channel a few days ago.
The text was updated successfully, but these errors were encountered:
Issue for tracking original pull request created by user allanrbo on date 2020-03-04 08:50:46.
Link to original PR: SpiderLabs/owasp-modsecurity-crs#1710.
HEAD is: 023ce59
BASE is: 3aa260d
The intention of this rule appears to be to find situations such as
1=1
,123=123
,1!=2
,123!=321
,'hello' NOT LIKE 'world'
. SQL expressions that will always evaluate to true - aka. tautologies.However, I believe the rule had a flaw. For example it would match
11=1
,1=11
, and fail to match1!=11
. I believe the reason is because the backreference\1
was given too much flexibility on what it could match. So for example given11=1
, when the regex engine arrives at the backreference, it seems to have the freedom to choose just any permutation of the referred capture group, so instead of choosing the whole11
, it can simply just choose1
. I think maybe the possessive quantifier++
was an attempt to solve this problem, but it doesn't work. I believe a solution is lock down this freedom by explicitly forcing word boundaries around the capture group([\d\w]+)
, so it becomes\b([\d\w]+)\b
. Likewise around the\1
backreference.The existing test case
"1" sSOUNDS LIKE "SOUNDS LIKE 1
it appears to me just kind of passed by chance, because of the above described bug. It would match so\1
becameSOUNDS
, and then refer back tosSOUNDS
but just choose the permutation of ignoring the first lower cases
. Experiment here: https://regex101.com/r/hyI0Iv/1 .This fix also has the side effect of solving the perf issue Airween brought up on the Slack channel a few days ago.
The text was updated successfully, but these errors were encountered: