Re: [mod-security-users] Trouble excluding params with ARGS_NAMES
Brought to you by:
victorhora,
zimmerletw
|
From: Jamie B. <ja...@ib...> - 2020-09-04 22:20:54
|
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/ |