Re: [mod-security-users] Bypass all rules on Cookies
Brought to you by:
victorhora,
zimmerletw
From: Ryan B. <RBa...@tr...> - 2014-07-22 14:07:39
|
If you are doing conditional exceptions (using the ctl action) then the rules need to come BEFORE the actual rule it is modifying. Explicit exceptions (using the SecRuleRemoveBy… directives) come AFTER the rules you are disabling/modidying. Did you place your rules in conf files that are included before the normal OWASP CRS? Ryan Barnett Senior Lead Security Researcher, SpiderLabs Trustwave | SMART SECURITY ON DEMAND www.trustwave.com<http://www.trustwave.com/> From: Laurens de Vries <ld...@am...<mailto:ld...@am...>> Reply-To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>> Date: Tuesday, July 22, 2014 4:02 AM To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>> Subject: Re: [mod-security-users] Bypass all rules on Cookies I must be doing something wrong, as such a line doesnt seem te have any effect. Created a testcase with a cookie, which get an an 403 error on rule 981172 Clearly SecRuleRemoveById 981172 solves the issue but that is not what I need. Even SecAction \ "id:1234567,phase:1,t:none,nolog,pass,\ ctl:ruleRemoveTargetById=981172;REQUEST_COOKIES” or REQUEST_COOKIE:testcookie doest not work. Anyone has an idea ? Laurens On 19-7-2014 13:09, Walter Hop wrote: On 19 Jul 2014, at 11:12, Laurens De Vries <ld...@am...<mailto:ld...@am...>> wrote: Is there either a setting, or a rule I can add, to clear/bypass any cookie for all rules of the Core Set. Adding a rule like this to your configuration could go a long way. It will bypass checking cookies for rules with any tag (which is almost all of the CRS): SecAction \ "id:1234567,phase:1,t:none,nolog,pass,\ ctl:ruleRemoveTargetByTag=.*;REQUEST_COOKIES” I wouldn’t recommend doing this though. It’s a bit better to whitelist individual cookie names, instead of every cookie. Of course, for this, you must know the cookie name: SecAction \ "id:1234567,phase:1,t:none,nolog,pass,\ ctl:ruleRemoveTargetByTag=.*;REQUEST_COOKIES:yourcookiename” However, cookies can be manipulated by a client just like other parameters! If you run applications that handle cookies insecurely, you might open up yourself to attacks again. So it’s even better to validate the cookie contents before whitelisting. For instance, if you have problems with a PHPSESSID cookie which due to random chance contains some prohibited words, the following snippet will whitelist the PHPSESSID cookie *only* if it matches a valid cookie string from the PHP manual. SecRule REQUEST_COOKIES:PHPSESSID "^[a-zA-z0-9\-,]+$" \ "id:1234567,phase:1,t:none,nolog,pass,\ ctl:ruleRemoveTargetByTag=.*;REQUEST_COOKIES:PHPSESSID" Now if someone would try some form of injection via the PHP session handler, they’d likely need some special characters and the request won’t be whitelisted. - Walter Hop | PGP key: https://lifeforms.nl/pgp ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ 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. |