SpiderLabs / owasp-modsecurity-crs

OWASP ModSecurity Core Rule Set (CRS) Project (Official Repository)

Home Page:https://modsecurity.org/crs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

@rx validation required for 933210

kkasmi opened this issue · comments

SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/utm/|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "@rx (?:(?:(|[)[a-zA-Z0-9.$"'[](){}/*\s]+(?:)|])[0-9.$"'[](){}/\s]([a-zA-Z0-9_.$"'[](){}/\s].)|([\s]string[\s])[\s]*(?:"|'))"
"id:933210,
.....
"

I'd like to get some help on the regular expression in 933210 as a RX checkup program gave me errors such as "/ An unescaped delimiter must be escaped with a backslash ()". NGINX+WAF CRS 3.2 caught it as an ERROR but I wonder how it works with these rx error.

You need to escape the " characters inside of operator argument.

Compare your original and the corrected rule (last one works - well, Nginx allows :)).

SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "@rx (?:(?:(|[)[a-zA-Z0-9.$"'[](){}/*\s]+(?:)|])[0-9.$"'[](){}/\s]([a-zA-Z0-9_.$"'[](){}/\s].)|([\s]string[\s])[\s]*(?:"|'))"
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "@rx (?:(?:(|[)[a-zA-Z0-9_.$\"'[](){}/*\s]+(?:)|])[0-9_.$\"'[](){}/\s]_([a-zA-Z0-9.$\"'[](){}/\s].)|([\s]_string[\s]_)[\s]*(?:\"|'))" \

Hope this helps.

Hi Airween,
Thanks for the reply.

The rx in 933210 of CRS 3.2 already has (backward slash) to escape before "(double quote). When I copied and pasted into this form, some how \ in front of " are disappeared. Sorry for the wrong post by this. I corrected it below:

So the rx that I have some problem in 933210 is
(?:(?:(|[)[a-zA-Z0-9_.$"'[](){}/\s]+(?:)|])[0-9_.$"'[](){}/\s]([a-zA-Z0-9_.$"'[](){}/\s].)|([\s]string[\s])[\s](?:"|'))

Error message from the rx validation: "/ An unescaped delimiter must be escaped with a backslash ()". I assumed that /(forward slash) is actually causing the problem in ...[a-zA-Z0-9_.$"'[](){}/*\s]...... And similarly 2 more times in rx.

So I updated like below
(?:(?:(|[)[a-zA-Z0-9_.$"'[](){}/\s]+(?:)|])[0-9_.$"'[](){}/\s]([a-zA-Z0-9_.$"'[](){}/\s].)|([\s]string[\s])[\s](?:"|'))

and the error messages are gone but I am not so sure if it will catch right expressions that meant to be.

Thanks again. regards,

I think the backward slash are gone again. This is weird. This editor is somehow opt it out.
You can refer the rx in 933210 for the original rx that I have problems

Hi @kkasmi,

so are you using CRS version 3.2 from tarball, but when you copied here the pattern then the editor cut some chars? Please use the markdown format, eg the 3 pieces of sequence of ` character.

Anyway, you didn't wrote any exact info about your engine. When I wrote my answer yesterday, I assumed you're using libmodsecurity3 (as WAF) with Nginx - but now I'm not sure. I checked this rule yesterday, and ModSecurity allows it.

Please share with us more details.

Hi again @airween
I am using NGINX/1.17.6 (nginx-plus-r20) with WAF (ModSecurity CRS v3.2.0) in the test environment.

I copied the part of the rule 933210 again. I think it will show correctly this time. Thanks for keeping checking and please let me know if you need more information from my end.
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "@rx (?:(?:\(|\[)[a-zA-Z0-9_.$\"'\[\](){}/*\s]+(?:\)|\])[0-9_.$\"'\[\](){}/*\s]*\([a-zA-Z0-9_.$\"'\[\](){}/*\s].*\)|\([\s]*string[\s]*\)[\s]*(?:\"|'))" \ "id:933210,\ phase:2,\ block,\ capture,\ .....

I also put the part of ModSecurity error message that logged in error.log:
1 933210 Matched Data: (data) { $("#PaymentForm").append(data); }) found within ARGS:x01: ... (111 characters omitted)

I tried to validate this matched data phrase with the rx, but web rx checker shows as errors in rx itself. Below is the error message (from https://regex101.com)
/ An unescaped delimiter must be escaped with a backslash (\)
(I wonder how CRS catches it if there is errors in the rx. I assume the regex101 is not reliable source to check at this moment and will check with other tools later. )

So as I mentioned in the earlier post, I changed it like below and was NOT SO SURE if this is meant to be. I put backward slash in front of /* three times.
(?:(?:\(|\[)[a-zA-Z0-9_.$\"'\[\](){}\/*\s]+(?:\)|\])[0-9_.$\"'\[\](){}\/*\s]*\([a-zA-Z0-9_.$\"'\[\](){}\/*\s].*\)|\([\s]*string[\s]*\)[\s]*(?:\"|'))

In the test using regex101, the modified rx above catches the matched data phrase.

If you need more information, please let me know.
Regards,

Okay, you wrote that you use nginx-plus-r20 - I checked, looks like this is an nginx extended version, perhaps it contains some WAF implementation. If it's true, then I think you have to ask the Nginx developers about the parsing errors. The rule 933210 works with modsecurity2 + Apache and modsecurity3 + Nginx as well.

But now I'm a bit confused - you included a part of your error log. Now this rule works? Or did you modified something?

Hi @airween again,
Thanks for the follow-up. I got the same confusion as the RuleId 933210 without modification (with parsing errors) caught the error. I wonder how NGINX WAF works with a broken rx to catch.
Possible scenario in my mind though, the rx matches the phrase (data){ $( ) in this order so it doesn't need to parse /*. So in this way, 933210 will catch the error with broken rx. (I am a beginner of NGINX+WAF environment. It is my assumption at this point, might be wrong.)

I think, as you recommended, I will ask to NGINX developers about this. I think PLUS package has a support option.

Your further opinion will be appreciated if you want and thanks again for your support.
(When I get answers from NGINX developer, I will share with you)
Regards,

Hi @kkasmi,

well, your engine notices you that the @rx argument is wrong, but started :O?

I think the regex is good:
https://regex101.com/r/frDwrc/1

On this link I just added the \ char to escape the / (because the regex101 engine uses the / as separator).

I think this isn't the false positive catch. What you can do that make an exception for the affected URI/argument.

If you don't have any question, please close this issue.

Hi @airween,
I agree that this is not the false positive case so that I will close the issue.
I think rx should be validated before it is included in the ruleset, specially, for the user who uses commercial version.
Thanks.