This is a draft, I'm working to a more stricter version for SQLite and PostgreSQL in order to avoid FPs

@theMiddleBlue We don't seem to match against this example, which appears to be path-based (original example screenshot):

curl -H 'x-crs-version: nightly' -H 'x-crs-paranoia-level: 4' -H 'x-backend: apache' -H 'x-format-output: txt-matched-rules' "https://sandbox.coreruleset.org/blah/\"\}' and data @> '\{\"a\":\"a\"\}' union select ASCII(s.token) from unnset(string_to_array((select cookie from cookie limit 1 ),NULL)) s(token)--/state?sig=1&timeStamp=50"

We don't catch it when the attack is in the path, but we do catch it when it's in ARGS as a query string parameter:

curl -H 'x-crs-version: nightly' -H 'x-crs-paranoia-level: 4' -H 'x-backend: apache' -H 'x-format-output: txt-matched-rules' "https://sandbox.coreruleset.org/blah?param=\"\}' and data @> '\{\"a\":\"a\"\}' union select ASCII(s.token) from unnset(string_to_array((select cookie from cookie limit 1 ),NULL)) s(token)--/state?sig=1&timeStamp=50"
⋮
980170 PL1 Anomaly Scores: (Inbound Scores: blocking=90, detection=90, per_pl=15-56-11-8, threshold=5) - (Outbound Scores: blocking=0, detection=0, per_pl=0-0-0-0, threshold=4) - (SQLI=70, XSS=5, RFI=0, LFI=0, RCE=10, PHPI=0, HTTP=0, SESS=0)

thanks @RedXanadu !

I've changed the SQLite regex in order to avoid FPs. This rule could probably be bypassed by using other SQL engine functions to transform the string parameters. But other CRS rules should catch it.

https://regex101.com/r/uAPMQY/1

HA! the test is failing on 4 and 6 because of / ... apache always returns a 404 if / is in the URL IIRC.
@dune73 @fzipi any idea? the regex matches correctly...

https://regex101.com/r/0J5Zr0/1

I can remove all comment syntaxes on tests, it should fix the test problem...

Probably using the data field in tests is better than using the url?

ok this should cover all test cases, including the payload from @RedXanadu

Yay: tested and confirmed that it now catches the path-based payload from above 😄

Imperva have published some more example payloads. Some of them we catch at PL 1, some of them we don't.

Are these concerning? Do we need to catch all of these variations, or will we be here forever?

Either way, here are the results I got:

1

' or '{"key":"value"}' ? "key" --

curl -v -o/dev/null 'localhost' --data "param=' or '{\"key\":\"value\"}' ? \"key\" --"

Result: per_pl=0-36-11-13

2

' or '{"name":"jack"}' ?| array['a','location']

curl -v -o/dev/null 'localhost' --data "param=' or '{\"name\":\"jack\"}' ?| array['a','location']"

Result: per_pl=0-31-11-13

3

' or '{"name":"jack", "Location":"UK"}' ?& array['name','Location']

curl -v -o/dev/null 'localhost' --data "param=' or '{\"name\":\"jack\", \"Location\":\"UK\"}' ?& array['name','Location']"

Result: per_pl=0-21-19-26

4 ✔️

' or '{"a":"b"}'::JSONB @> '{"a":"b"}'--

curl -v -o/dev/null 'localhost' --data "param=' or '{\"a\":\"b\"}'::JSONB @> '{\"a\":\"b\"}'--"

Result: per_pl=10-36-11-13 (942550 matches)

5

' or '[1,2,3]'::json ->> 2 = '3'

curl -v -o/dev/null 'localhost' --data "param=' or '[1,2,3]'::json ->> 2 = '3'"

Result: per_pl=0-36-16-13

6 ✔️

' or '{"a":{"b":{"c":"foo"}}}'::jsonb#>'{a,b}' @> '{"c":"foo"}'::jsonb --

curl -v -o/dev/null 'localhost' --data "param=' or '{\"a\":{\"b\":{\"c\":\"foo\"}}}'::jsonb#>'{a,b}' @> '{\"c\":\"foo\"}'::jsonb --"

Result: per_pl=10-36-11-13 (942550 matches)

7 ✔️

' or '{"a": {"b":{"c": "foo"}}}'::jsonb#>'{a,b}' ? 'c' --

curl -v -o/dev/null 'localhost' --data "param=' or '{\"a\": {\"b\":{\"c\":        \"foo\"}}}'::jsonb#>'{a,b}' ? 'c' --"

Result: per_pl=10-46-11-13 (942550 matches)

8 ✔️

' or '{"a":{"b":{"c"}}}'::jsonb#>'{a,b}' ? 'c' --

curl -v -o/dev/null 'localhost' --data "param=' or '{\"a\":{\"b\":{\"c\"}}}'::jsonb#>'{a,b}' ? 'c' --"

Result: per_pl=10-41-11-13 (942550 matches)

oh wow, thanks @RedXanadu this is really useful! I'm going to see if I can integrate all variations

added new payloads and I removed useless parts from the ra file, so the regex should be less chaotic.
moreover, it should match all payload you listed @RedXanadu (I've added a modified version of that list on the regression test file)

a possible false positive could be an ARGS value that contains the following string:

are '{' and '}' brackets? yes.

something like:

message=are '{' and '}' brackets? yes.

Thanks a lot!