Re: Trouble excluding params with ARGS_NAMES

Jamie Burchell <[email protected]>
Newsgroups gmane.comp.apache.mod-security.user
Message-ID <[email protected]> 
Thank you Christian and Manuel for your help.

Kind Regards
Jamie

-----Original Message-----
From: Christian Folini <[email protected]>
Sent: 07 September 2020 08:40
To: [email protected]
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
> > <[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/


_______________________________________________
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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.