Re: [mod-security-users] Trouble excluding params with ARGS_NAMES
Brought to you by:
victorhora,
zimmerletw
|
From: Christian F. <chr...@ne...> - 2020-09-07 07:40:16
|
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/ |