Thanks Christian, I appreciate your help!
On Wed, Aug 16, 2017 at 12:46 AM, Christian Folini <
christian.fol...@netnea.com> wrote:
> Do you have a paper copy of the book? If not, then please give me your
> address and I will have a copy be sent your way. Ironically, it will
> come with the bug, but I really appreciate people submitting errors the
> encounter in the book.
>
That's not necessary, thanks for the offer. I've already got the electronic
version, and the paper copy is shipping as we speak :)
> > 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!
>
> With ctl:ruleUpdateTargetById being no longer an option, we need a
> different approach. This is turning more and more into a wild hack, but
> let's try out the following:
>
> - Remove all the ARGS at startup time
> - Add ARGS:SearchTerm at startup time
> - Remove SearchTerm from all paths but /product/search at runtime
> -> "!@beginsWith /product/search"
>
> Good luck and please report back!
>
That works well.
Here's my canonical "How you run the Core Rule Set's SQLi rules only on
vulnerable pages and parameters" for historical / archival reference:
These rules disable the SQL injection rules in the Core Rule Set v3, except
for two parameters: "SearchTerm" and "foo". This is done at configuration
time, so the SecRuleUpdateTargetByID statements have to go after the Core
Rule Set is included.
Then at runtime, we narrow down the list of pages that the SQLi rules are
run against, by removing the two parameters "SearchTerm" and "foo"
depending on which URL is being requested. As this is at runtime, these two
rules need to go before the Core Rule Set rules are included, so that the
change to their Target is done before they run.
# Rutime: Only run the SQLi rules against SearchTerm if on the Product
Search page
SecRule REQUEST_FILENAME "!@beginsWith /product/search" \
"id:2011,phase:2,\
pass,nolog,\
t:none,t:lowercase,t:normalisePath,\
ctl:ruleRemoveTargetById=942100-942999;ARGS:SearchTerm"
# Runtime: Only run the SQLi rules against argument foo if on the About page
SecRule REQUEST_FILENAME "!@beginsWith /home/about" \
"id:2012,phase:2,\
pass,nolog,\
t:none,t:lowercase,t:normalisePath,\
ctl:ruleRemoveTargetById=942100-942999;ARGS:foo"
Include modsecurity/crs-setup.conf
Include crs/*.conf
# Configure-Time: 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"
# Configure-Time: Only test SQLi for the SearchTerm & foo parameters
SecRuleUpdateTargetByID 942100-942999 "ARGS:SearchTerm"
SecRuleUpdateTargetByID 942100-942999 "ARGS:foo"
# (Jump back up to ID 2011 and 2012 above the include for CRS, to see the
rest of the rules)
I appreciate your help getting this working.
Cheers,
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
