Great! Thanks Christian!
I did try and figure out what was going on with the higher debug log
levels, but didn't realise that was what was happening.
I think by "steering commando rules" you mean the rules that check which
paranoia level is set, and then jump to the marker at the end of the file?
e.g. SecRule TX:PARANOIA_LEVEL "@lt 1"
"phase:1,id:942011,nolog,pass,skipAfter:END-REQUEST-942-APPLICATION-ATTACK-SQLI"
In the SQLi include file, these rules are all numbered 942011-18, so I
changed the rules to only alter the rules from 942100-942999.
The following config then works!
Include modsecurity/crs-setup.conf
Include crs/*.conf
# Disable CRS's SQLi rules:
SecRuleUpdateTargetByID 942100-942999 "!REQUEST_COOKIES"
SecRuleUpdateTargetByID 942100-942999 "!REQUEST_COOKIES_NAMES"
SecRuleUpdateTargetByID 942100-942999 "!ARGS_NAMES"
SecRuleUpdateTargetByID 942100-942999 "!ARGS"
SecRuleUpdateTargetByID 942100-942999 "!XML"
# Only test SQLi for the SearchTerm parameter
SecRuleUpdateTargetByID 942100-942999 "ARGS:SearchTerm"
After this, the SQLi rules are disabled for all cookies, arguments and XML,
and then only re-enabled for my one parameter name.
Next, I attempted to do this at runtime, so I could apply the rules to only
my particular page:
SecRule REQUEST_FILENAME "@beginsWith /product/search" \
"id:2011,phase:2,\
pass,nolog,\
t:none,t:lowercase,t:normalisePath,\
ctl:ruleUpdateTargetById=942100-942999;ARGS:SearchTerm"
However, the ctl:ruleUpdateTargetById action doesn't work - I was lead
astray by the Mod Security Handbook, which is a bit out of date (at this
url:
https://www.feistyduck.com/library/modsecurity-handbook-2ed/online/xx1-directives.html#N15992).
It looks like that got removed:
Note : There was a ctl:ruleUpdateTargetById introduced in 2.6.0 and removed
from the code in 2.7.0. JSON was added as part of v2.8.0-rc1
(from https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#ctl)
If you have any ideas on how to further restrict it so I can rule the SQLi
rules for only one page + parameter combo, I'm interested to know!
Thanks,
Kirk
On Tue, Aug 15, 2017 at 7:10 PM, Christian Folini <
christian.fol...@netnea.com> wrote:
> Kirk,
>
> This is a tricky one. Actually your recipe should work. But then it does
> not. I dug a bit deeper and found out an issue.
>
> SecRuleUpdateTargetByID 942000-942999 "ARGS:SearchTerm"
>
> adds the arg SearchTerm to all rules including steering commando rules
> used for Paranoia Levels. And this seems to f**k them up. At least this
> is my first impression.
>
> Could you try and apply the Update only to those rules that really
> apply and report back?
>
> There might be a deeper issue here, so let's try and work together
> to find a good recipe to solve your use case - which is actually a very
> useful one.
>
> Ahoj,
>
> Christian
>
>
> On Mon, Aug 14, 2017 at 10:03:15AM +1200, Kirk Jackson wrote:
> > Hi,
> >
> > I'd like to run the SQLi checks on only the one parameter on my site that
> > is vulnerable to those attacks.
> >
> > I was wondering if there's a pattern to do this, or if I need to copy the
> > rules from REQUEST-942-APPLICATION-ATTACK-SQLI.conf into my own file,
> and
> > change the variables to my ARGS:ParamName?
> >
> > I tried doing this, to disable the rules, and then re-enable for just my
> > param, but that didn't work:
> >
> > SecRuleUpdateTargetByID 942000-942999 "!REQUEST_COOKIES"
> > SecRuleUpdateTargetByID 942000-942999 "!REQUEST_COOKIES_NAMES"
> > SecRuleUpdateTargetByID 942000-942999 "!ARGS_NAMES"
> > SecRuleUpdateTargetByID 942000-942999 "!ARGS"
> > SecRuleUpdateTargetByID 942000-942999 "!XML"
> >
> > SecRuleUpdateTargetByID 942000-942999 "ARGS:SearchTerm"
> >
> > Many thanks!
> >
> > Kirk
>
> > _______________________________________________
> > 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/books/modsecurity-handbook/
> 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
