Re: [mod-security-users] Whitelisting nightmare...

[Ryan B. <RBa...@tr...>]

You don't want to do this.  This is not the correct approach for whitelisting.  What you showed below turns off ModSecurity as a whole if that data appears.

You want to use the SecRuleRemoveByXX directives or the SecRuleUpdateTargetByXX directives instead.

Ryan Barnett
Lead Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>

From: Jose Pablo Valcárcel Lázaro <pab...@gm...<mailto:pab...@gm...>>
Reply-To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Date: Monday, January 27, 2014 11:59 AM
To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Subject: Re: [mod-security-users] Whitelisting nightmare...

http://www.webhostingtalk.com/showthread.php?t=1024178

A rule like this? SecRule ARGS:variablename “Union” phase:1,nolog,allow,ctl:ruleEngine=off

Kind regards


2014-01-27 Jose Pablo Valcárcel Lázaro <pab...@gm...<mailto:pab...@gm...>>
Hi.

In mod_security directive there is a example where you can whitelist args: whitelists args<https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-ARGS_NAMES>

SecRule ARGS_NAMES "!^(p|a)$" "id:13"

Have you tried  with !^ and args??

Kind regards,



2014-01-27 rewt rewt <re...@li...<mailto:re...@li...>>
Dear All,
I have to urgently secure a web application.
Unfortunately it is not working as expected :(

My problems are:
- ARGS variable names change the only remaining part is "property" so i wanted to write something like .*property.* ...
- When i write a chained rule it works, but it whitelist the full URL instead of the ARGS only

(for information this ARG variable contains an SSL certificate which is considered as SQLi.

I have tried tons of possibilites:

This one fully whitelist the URL and does not consider the ARGS value
(i have tried it in different orders ARGS_NAME before, then REQUEST_URI -> not whitelisting at all)

SecRule REQUEST_URI "^/dir/mycgi.cgi.*" "phase:1,t:none,nolog,id:25,chain,pass,ctl:ruleEngine=off"
SecRule ARGS_NAMES .*property.* "t:none"

This one does the same:
SecRule REQUEST_URI "^/dir/mycgi.cgi" "id:25,phase:1,t:none,pass,nolog,ctl:ruleEngine=off"

# i tried to match BEGIN and END of certificate
SecRule ARGS:property_value_.* !BEGIN.*END.*$ "id:26,phase:2,t:none,redirect:https://site/blocked.html,msg:'MyAPP issue'"
SecRule ARGS:old_property_value_.* !BEGIN.*END.*$ "id:27,phase:2,t:none,redirect:https://site/blocked.html,msg:'MyAPP issue'"

# I also tried:
SecRule REQUEST_URI "^/dir/mycgi.cgi" "id:25,phase:1,t:none,pass,nolog,ctl:ruleEngine=off;ARGS:.*property.*
Syntax error on line 95 of /etc/httpd/conf.d/reverse-mycgi.conf:
Error parsing actions: Invalid setting for ctl name ruleEngine: off;ARGS:.*property.*

(ARGS_NAMES does the same)

Some help would be very much appreciated as i don't know what to do now :(

I don't even find a way to fully whitelist this ARGS (with regular expression) inside my virtualhost.

Kind regards,




------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
mod-security-users mailing list
mod...@li...<mailto: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/




________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.