Re: Trouble excluding params with ARGS_NAMES

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 <[email protected]> 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 <[email protected]>
>> Sent: 04 September 2020 14:10
>> To: [email protected]
>> 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
>>> [email protected]
>>> 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
>> [email protected]
>> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
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/