Hi Ken and Barry, Thank you for reporting Ken. This is an interesting case.
As Barry has already laid down, these rules are somewhat historical and we can not really guarantee everything was really, really considered during the migration steps. At least a considerate documentation of the reasoning behind the design decision was not done. My 2 cents: - These are phase:2 rules. There are subtle implicit parameter transformation happening between phase 1 and 2. The use of REQUEST_URI_RAW (where these transformations are not happening) in 930100 could be a hint in this direction. However, 930110 does not use this. Actually I get a feeling, that REQUEST_URI won't necessarily catch "../" in the request uri on application server. But maybe I am wrong. - Maybe there is a performance advantage in using regexes on REQUEST_BODY over ARGS. With the disadvantage that you won't know where the hit occurred. So maybe this is an artefact. Maybe it is not. - 930100 is one of the optimized regexes, where we no longer have the source pattern list. If somebody could dis-assemble it, that would be neat. So under the line, I do not have a lot to contribute. Sorry. Christian On Sun, Sep 04, 2016 at 04:28:40PM -0700, Ken Brucker wrote: > The false positive I get is on the WordPress backend. If a post happens to > include example path text that includes '../', it will trigger on these rules > as the post is being saved. > > I appreciate the hints on how to modify the rule locally. Much preferred over > changing the rule set source. > > In this case, I think the URI is OK and it's the REQUEST_BODY that I need to > change. I don't recall which I saw in the audit log. > > -- Ken > > > On Sep 4, 2016, at 10:43 AM, Barry Pollard <barry_poll...@hotmail.com> > > wrote: > > > > Been thinking about this and you've got me intrigued as to whether this was > > an intentional decision or not... > > > > As far as I can see, you are right these could have been written using > > REQUEST_FILENAME and ARGS rather than REQUEST_URI and REQUEST_BODY. > > > > ModSecurity is quite flexible and there are a few different ways of doing > > things. So it can depend on whoever writes the rules as to which version > > they use. > > > > This is just a guess, but I wonder if the reason these variables were > > chosen is hinted at in this line in the manual ModSecurity manual > > (https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#REQUEST_BODY > > > > <https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#REQUEST_BODY>): > > > > There are no default transformation functions, as there were in the first > > generation of ModSecurity (1.x). > > > > and also lines like this: > > Note : Please note that anti-evasion transformations are not used on > > REQUEST_URI, which means that you will have to specify them in the rules > > that use this variable. > > I'm not sure what the default transformations were in ModSecurity 1.x, or > > if these were the anti-evasion transformations being discussed but wonder > > that was the reason - as it would prevent these rules from working if the > > ARGS were used and default transformations were applied? > > > > If you need the ability to override these on certain ARGS (though I think > > that could be dangerous - and have personally never seen any false > > positives with these) you could replace them as you see fit - either > > directly in the file (not recommended as will be overwritten if you ever > > upgrade the CRS) or by altering the rules dynamically: > > > > #Replace REQUEST_URI with REQUEST_FILENAME > > SecRuleUpdateTargetById 930100 REQUEST_URI REQUEST_FILENAME > > > > #Also add in ARGS > > SecRuleUpdateTargetById 930100 ARGS > > > > Or use ctl:ruleRemoveById version to only do this for certain URLs. > > > > Thanks, > > Barry > > > > On 4 Sep 2016, at 18:25, Christian Folini <christian.fol...@netnea.com > > <mailto:christian.fol...@netnea.com>> wrote: > > > >> On Sun, Sep 04, 2016 at 08:08:53AM -0700, Ken Brucker wrote: > >>> [ Not sure my first try posting made it through, I see it in the archive, > >>> but have had no response which I find odd. ] > >> > >> I do not think the first inquiry made it through. But this time it did. > >> > >> Thanks for the report. We'll investigate. > >> > >> Cheers, > >> > >> Christian > >> > >>> > >>> I have V3 rules running in a test environment playing with how it > >>> interacts with WordPress. My early investigation is showing a few rules > >>> that need to be addressed to allow code, sql examples etc. to be included > >>> in a post, nothing overly surprising. > >>> > >>> I have a question about the construction of rules 930100 and 930110. > >>> These rules both examine REQUEST_BODY and REQUEST_HEADERS. Other rules, > >>> such as 930120 use ARGS and ARGS_NAMES, etc. > >>> > >>> The result is it's not possible to disable 930100 and 930110 for specific > >>> ARGS where the patterns would be acceptable. > >>> > >>> What is the motivation for the difference in how these rules are defined? > >>> > >>> -- Ken > >> > >>> _______________________________________________ > >>> Owasp-modsecurity-core-rule-set mailing list > >>> Owasp-modsecurity-core-rule-set@lists.owasp.org > >>> <mailto:Owasp-modsecurity-core-rule-set@lists.owasp.org> > >>> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > >>> <https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set> > >> > >> > >> -- > >> https://www.feistyduck.com/training/modsecurity-training-course > >> <https://www.feistyduck.com/training/modsecurity-training-course> > >> mailto:christian.fol...@netnea.com <mailto:christian.fol...@netnea.com> > >> twitter: @ChrFolini > >> _______________________________________________ > >> Owasp-modsecurity-core-rule-set mailing list > >> Owasp-modsecurity-core-rule-set@lists.owasp.org > >> <mailto:Owasp-modsecurity-core-rule-set@lists.owasp.org> > >> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > >> <https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set> > > _______________________________________________ > Owasp-modsecurity-core-rule-set mailing list > Owasp-modsecurity-core-rule-set@lists.owasp.org > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set -- https://www.feistyduck.com/training/modsecurity-training-course mailto:christian.fol...@netnea.com twitter: @ChrFolini _______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
