Correct, that is the dilemma... Maybe we should make two versions in the config (one with a Cookie existence check and one without) and let the user enable the one they want for the issue that is more of a concern: increasing performance or reducing false negatives.
-Ryan On 2/15/12 6:39 PM, "Michael Haas" <michael.haa...@gmail.com> wrote: >If there is a check for a Cookie there would be no chance to exclude >static resources for sites which require authentication? > >Michael > > >2012/2/15 Ryan Barnett <rbarn...@trustwave.com>: >> One potential bypass issue - Cookies. This was an issue in the SQL >>injection challenge. >> >> I guess we could add a check to make sure there are no cookies either. >>If so, we should run the request through normal inspection. >> >> Ryan >> >> On Feb 15, 2012, at 5:25 PM, "Ryan Barnett" >><rbarn...@trustwave.com<mailto:rbarn...@trustwave.com>> wrote: >> >> I would like to update the logic of the this ruleset - >> >>http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/opt >>ional_rules/modsecurity_crs_10_ignore_static.conf >> >> The concept is that rather than audit log all transactions (with >>SecAuditLog On), you want to exclude logging requests for static >>resources. The trick is that we need to try and ensure that the attack >>surface is significantly reduced. In order to do that, I am testing >>this updated ruleset - >> >> SecRule REQUEST_METHOD "@pm GET HEAD" >>"id:'999001',chain,phase:1,t:none,nolog,pass" >> SecRule REQUEST_URI "!@contains ?" "chain" >> SecRule &ARGS "@eq 0" "chain" >> SecRule >>&REQUEST_HEADERS:Content-Length|&REQUEST_HEADERS:Content-Type "@eq 0" >>"ctl:ruleEngine=Off,ctl:auditEngine=Off" >> >> This rule checks the following - >> >> 1. That the request method is either a GET or HEAD. If it is >>anything else, they it should probably be logged as it is a dynamic >>request method looking to alter data. >> 2. Verifies that there is no query string by checking for ? Char in >>the URI. >> 3. Verifies that there are no ARGS being passed >> 4. Verifies that there is no request body by checking for the >>existence of Content-Length and Content-Type request headers. >> >> If all of these rules match, then the ctl actions are used to toggle >>off both the audit and rule engines. >> >> Does anyone have any feedback on this updated ruleset? Any >>improvements? >> >> Thanks. >> >> -- >> Ryan Barnett >> Trustwave SpiderLabs >> ModSecurity Project Leader >> OWASP ModSecurity CRS Project Leader >> >> ________________________________ >> 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 > 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
