On 10/2/13 8:33 AM, "John McGowan" <j...@lynch2.com> wrote:
>On Wed, Oct 2, 2013 at 5:08 AM, Josh Amishav-Zlatin <jam...@owasp.org> >wrote: >> On Tue, Oct 1, 2013 at 10:56 PM, John McGowan <j...@lynch2.com> wrote: >>> >>> Is it possible for a mod_security rule to drop a cookie or an argument >>> from a request without dropping the entire request? >> >> >> Hi John, >> >> While I would not recommend this approach, you could use mod_headers to >> remove the cookie and the rsub action to remove POST body data from >>requests >> if you know the cookie/parameter name ahead of time. > >But I don't, the problem I'm dealing with is that 3rd parties set >cookies on domains. Cookies that my application doesn't read, or even >know that they exist. And when one of those cookies looks bad to the >CRS, the entire request is dropped. Meaning that the application is >now broken for that user until we add an exxception. > >> There is a good chance >> that this will negatively affect the functionality of the web >>application >> though. > >I'd rather have the application continue to move forward, ignoring the >offending parameters, and log that action. We would still have to >look at the logged "dropped parameters" and decide if it was a false >positive, true positive or a "who cares" positive. A "who cares" >positive would be one where I know my application doesn't use the >offending parameter, so it's safe to just let mod_sec remove it from >the request. > >> If your getting too many false positives for a given >> cookie/parameter value and you know that they are not vulnerable to a >>given >> attack type, have you tried disabling rules by tag name? This may be a >> cleaner approach to solving your problem. > >I'm writing exceptions for ruleid/parameter combination when they come up. > >The problem is, when a NEW third party cookie appears the application >is broken, and I'd rather that things move along and have that new >cookie ignored. > >/John John, What I would recommend is that you utilize the SecRuleUpdateTargetById, SecRuleUpdateTargetByTag, etcŠ directives to customize which local variables are inspected. For your scenario, lets say that you only want to inspect some Cookie values that your site specifically sets (SESISONID, FOO_COOKIE and BAR_COOKIE). You could add the following to a local custom rules file that is processed at the end of Apache/ModSecurity initialization (for example in a file called - modsecurity_crs_99_custom.conf). You could place the following in the file to replace REQUEST_COOKIES with only your defined cookie values for all SQL Injection rules - SecRuleUpdateTargetByTag "SQL_INJECTION" REQUEST_COOKIES REQUEST_COOKIES:SESSIONID,REQUEST_COOKIES:FOO_COOKIE,REQUEST_COOKIES:BAR_CO OKIE Let me know if this works for you. -Ryan ________________________________ 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. _______________________________________________ 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
