Query params not included in ARGS_NAMES|ARGS in GET request at phase:2 evaluation

[Sachin-M-Desai]

Not sure if this is a bug or a CRS rule limitation.

With the CRS rule ID 942270, any GET requests with SQL injections params in them arent detected. Assumption here is ARGS|ARGS_NAMES should contains query params as well (is it still true for libmodsecurity 3.x?).

However, for GET requests this rules doesnt get hit unless phase level is changed to "phase:1".

SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@rx (?i)union.?select.?from" \
"id:942270,\
phase:2,\
block,\
capture,\
t:none,t:urlDecodeUni,\
msg:'Looking for basic sql injection. Common attack string for mysql, oracle and others',\
logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
.....

1. This rule works all right if POST has offending ARGS in the request body.
2. Please note that SecRequestBodyAccess is On (not to get involved with SecRequestBodyAccess off skips the phase:2 rules #2465)

Output of:

1. DebugLogs (when undetected)
   undetected.Debuglogs.txt
2. AuditLogs
   [None as nothing was triggered]
3. Error logs
   [None]

Steps to reproduce the behavior:
Using Postman to generate a GET request to URL : http://j*********:8000/rest/products/search?q=apple'))UNION%20SELECT%20username,password,email,4,5,6,7,8,9%20FROM%20USERS--

Expected behavior
Shouldn't the rule evaluation happen in phase 2 as well against GET query ARGS?

**Server **

• libModsecurity 3.0 dynamically linked with our application
• OS: Ubuntu Linux

Rule Set (please complete the following information):
CRS rule set 3.3v

[airween]

Are you sure there isn't any exception? I can't find the rule 942270 all in your attached debug.log - it should be at there. I tried your request (with SecRuleEngine DebugOnly - I assume your config has this setting), and the rule was triggered:

[1616596340] [/rest/...FROM%20USERS--] [4] (Rule: 942270) Executing operator "Rx" with param "(?i)union.*?select.*?from" against REQUEST_COOKIES|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/*.
[1616596340] [/rest/...FROM%20USERS--] [9]  T (0) t:urlDecodeUni: "q"
[1616596340] [/rest/...FROM%20USERS--] [9] Target value: "q" (Variable: ARGS_NAMES:q)
[1616596340] [/rest/...FROM%20USERS--] [9]  T (0) t:urlDecodeUni: "apple'))UNION SELECT username,password,email,4,5,6,7,8,9 FROM USERS--"
[1616596340] [/rest/...FROM%20USERS--] [9] Target value: "apple'))UNION SELECT username,password,email,4,5,6,7,8,9 FROM USERS--" (Variable: ARGS:q)
[1616596340] [/rest/...FROM%20USERS--] [7] Added regex subexpression TX.0: UNION SELECT username,password,email,4,5,6,7,8,9 FROM
[1616596340] [/rest/...FROM%20USERS--] [9] Matched vars updated.
[1616596340] [/rest/...FROM%20USERS--] [4] Running [independent] (non-disruptive) action: setvar
[1616596340] [/rest/...FROM%20USERS--] [8] Saving variable: TX:sql_injection_score with value: 15
[1616596340] [/rest/...FROM%20USERS--] [4] Running [independent] (non-disruptive) action: setvar
[1616596340] [/rest/...FROM%20USERS--] [8] Saving variable: TX:anomaly_score_pl1 with value: 15
[1616596340] [/rest/...FROM%20USERS--] [4] Rule returned 1.

with this request:

curl -vvv "http://localhost:8080/rest/products/search?q=apple'))UNION%20SELECT%20username,password,email,4,5,6,7,8,9%20FROM%20USERS--"

See the last line in log snippet (Rule returned 1).

[Sachin-M-Desai]

Root cause is found. We werent evaluating phase 2 and 4 unconditionally. Will provide an image today for this

[Sachin-M-Desai]

Thanks. Your simple response got me thinking in the right direction. The issue was that we werent running processing for phase 2 unconditionally. Now am able hit it.

Thanks for the help. Will close the ticket.