Re: [mod-security-users] Trouble excluding params with ARGS_NAMES

[Jamie B. <ja...@ib...>]

Hi Christian

Thanks for the prompt and detailed response, as always.

I think in this case I do actually required a non-anchored regex, as the
application(s) I am protecting use, for example: "new_password",
"confirm_password", "old_password".

I'm still not really sure why matching against the parameter name (i.e.
ARGS_NAMES) does not achieve the same thing, since it's the name I'm
interested in and not the value of the parameter. However, it sounds like
I'm doing the "right" thing by checking ARGS instead.

Kind regards,

Jamie

-----Original Message-----
From: Christian Folini <chr...@ne...>
Sent: 04 September 2020 14:10
To: mod...@li...
Subject: Re: [mod-security-users] Trouble excluding params with ARGS_NAMES

Hey Jamie,

This is a new question and it is also a jolly good question as it made my
think about my assumptions and how people think and how ModSec behaves.

There are two problems here.

The interesting one:

ARGS is a collection of all parameters. Simply speaking, a parameter
consists of a parameter name and a parameter value. A parameter is
addressed by its parameter name.

ARGS_NAMES is a collection of parameter names. There are no parameter
values here. Only parameter names.

You could think of a collection ARGS_VALUES to complement the set. But
that does actually not exist in ModSecurity.

So if you want to suppress the execution of one or multiple rules against
one or multiple parameters, you typically use ARGS and not ARGS_NAMES.

The form ARGS_NAMES:/password/ can be used to count occurrences of
parameter names that match the regex, but it can actually be substituted
with ARGS:/password/. ( -> &ARGS:/password/). Otherwise I do not see many
uses of the ARGS_NAMES:xxx form.

The more mundane problem:

You use a regex to match the parameter name when you actually want an
individual parameter. You could fix this by anchoring your regex as in
ARGS:/^password$/, but you do not even need a regex in the first place,
since the following is the simpler and preferred way of doing this:

SecRuleUpdateTargetById 920000-943999 "!ARGS:password"

Nice way of using rule ranges to disable CRS for all incoming requests.
Please note that CRS comes with a new rules in the 944xxx range.

Cheers,

Christian



On Thu, Sep 03, 2020 at 08:53:34PM +0100, Jamie Burchell wrote:
> Hi there
>
> For reasons that are totally escaping me, I can't get the below
exclusion rule to work:
>
> SecRuleUpdateTargetById 920000-943999 "!ARGS_NAMES:/password/"
>
> However, using this rule does work:
>
> SecRuleUpdateTargetById 920000-943999 "!ARGS:/password/"
>
> I had thought that the first version of this rule would exclude any
parameter containing the word "password", but it does not seem to be
working. The second version of the rule does work, but presumably will
also match on any parameter value containing the word "password", which
isn't really what I wanted. What am I doing wrong?
>
> Thanks in advance
> Jamie
>
> mod_security: 2.9.2
> CRS: 3.3.0
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/


_______________________________________________
mod-security-users mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/