mod-security-users

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

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

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

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

[Christian F. <chr...@ne...>]

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/

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/

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

[Christian F. <chr...@ne...>]

Hey Jamie,

On Fri, Sep 04, 2020 at 02:19:07PM +0100, Jamie Burchell wrote:
> Thanks for the prompt and detailed response, as always.

Glad to help. :)

> 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".

If it's an open list, then that's pretty much a necessity, I guess.

> 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.

Let me put it that way:

ARGS is a list of boxes with content (= payloads / values)
ARGS_NAMES is a sheet of paper with names. It bears no meaning beyond the
words / names listed on the sheet.

>From a conceptual level, it could be implemented differently, but that's the
way it works in ModSecurity.

Given my background, I also see paralells in the medieval problem of
universals. If you have time at hand, you may want to check out
https://en.wikipedia.org/wiki/Problem_of_universals; namely the section of
medieval nominalism. :)

Cheers,

Christian

> 
> 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/
> 
> 
> _______________________________________________
> 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/

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

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

Thanks Christian for the explanation.

So, with that in mind would the below match parameter vales also? Would the below rule match a parameter named "foo" if it has the value of "password"?

SecRuleUpdateTargetById 920000-943999 "!ARGS:/password/"

Thanks
Jamie

Sent from my iPhone

> On 4 Sep 2020, at 16:49, Christian Folini <chr...@ne...> wrote:
> 
> Hey Jamie,
> 
>> On Fri, Sep 04, 2020 at 02:19:07PM +0100, Jamie Burchell wrote:
>> Thanks for the prompt and detailed response, as always.
> 
> Glad to help. :)
> 
>> 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".
> 
> If it's an open list, then that's pretty much a necessity, I guess.
> 
>> 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.
> 
> Let me put it that way:
> 
> ARGS is a list of boxes with content (= payloads / values)
> ARGS_NAMES is a sheet of paper with names. It bears no meaning beyond the
> words / names listed on the sheet.
> 
> From a conceptual level, it could be implemented differently, but that's the
> way it works in ModSecurity.
> 
> Given my background, I also see paralells in the medieval problem of
> universals. If you have time at hand, you may want to check out
> https://en.wikipedia.org/wiki/Problem_of_universals; namely the section of
> medieval nominalism. :)
> 
> Cheers,
> 
> Christian
> 
>> 
>> 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/
>> 
>> 
>> _______________________________________________
>> 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/

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

[Christian F. <chr...@ne...>]

On Fri, Sep 04, 2020 at 10:56:37PM +0100, Jamie Burchell wrote:
> Thanks Christian for the explanation.
> 
> So, with that in mind would the below match parameter vales also? Would the
> below rule match a parameter named "foo" if it has the value of "password"?
> 
> SecRuleUpdateTargetById 920000-943999 "!ARGS:/password/"

No, it would not.

Parameter arguments are only accessed via their names in this way. You're safe
from that problem.

Cheers,

Christian

> 
> Thanks Jamie
> 
> Sent from my iPhone
> 
> > On 4 Sep 2020, at 16:49, Christian Folini <chr...@ne...>
> > wrote:
> > 
> > Hey Jamie,
> > 
> >> On Fri, Sep 04, 2020 at 02:19:07PM +0100, Jamie Burchell wrote: Thanks
> >> for the prompt and detailed response, as always.
> > 
> > Glad to help. :)
> > 
> >> 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".
> > 
> > If it's an open list, then that's pretty much a necessity, I guess.
> > 
> >> 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.
> > 
> > Let me put it that way:
> > 
> > ARGS is a list of boxes with content (= payloads / values) ARGS_NAMES is a
> > sheet of paper with names. It bears no meaning beyond the words / names
> > listed on the sheet.
> > 
> > From a conceptual level, it could be implemented differently, but that's
> > the way it works in ModSecurity.
> > 
> > Given my background, I also see paralells in the medieval problem of
> > universals. If you have time at hand, you may want to check out
> > https://en.wikipedia.org/wiki/Problem_of_universals; namely the section of
> > medieval nominalism. :)
> > 
> > Cheers,
> > 
> > Christian
> > 
> >> 
> >> 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/
> >> 
> >> 
> >> _______________________________________________ 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/
> 
> 
> _______________________________________________ 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/

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

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

Thank you Christian and Manuel for your help.

Kind Regards
Jamie

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

On Fri, Sep 04, 2020 at 10:56:37PM +0100, Jamie Burchell wrote:
> Thanks Christian for the explanation.
>
> So, with that in mind would the below match parameter vales also?
> Would the below rule match a parameter named "foo" if it has the value of
> "password"?
>
> SecRuleUpdateTargetById 920000-943999 "!ARGS:/password/"

No, it would not.

Parameter arguments are only accessed via their names in this way. You're
safe from that problem.

Cheers,

Christian

>
> Thanks Jamie
>
> Sent from my iPhone
>
> > On 4 Sep 2020, at 16:49, Christian Folini
> > <chr...@ne...>
> > wrote:
> >
> > Hey Jamie,
> >
> >> On Fri, Sep 04, 2020 at 02:19:07PM +0100, Jamie Burchell wrote:
> >> Thanks for the prompt and detailed response, as always.
> >
> > Glad to help. :)
> >
> >> 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".
> >
> > If it's an open list, then that's pretty much a necessity, I guess.
> >
> >> 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.
> >
> > Let me put it that way:
> >
> > ARGS is a list of boxes with content (= payloads / values)
> > ARGS_NAMES is a sheet of paper with names. It bears no meaning
> > beyond the words / names listed on the sheet.
> >
> > From a conceptual level, it could be implemented differently, but
> > that's the way it works in ModSecurity.
> >
> > Given my background, I also see paralells in the medieval problem of
> > universals. If you have time at hand, you may want to check out
> > https://en.wikipedia.org/wiki/Problem_of_universals; namely the
> > section of medieval nominalism. :)
> >
> > Cheers,
> >
> > Christian
> >
> >>
> >> 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/
> >>
> >>
> >> _______________________________________________ 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/
>
>
> _______________________________________________ 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/