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