Hello Christian, Thanks for this great explanation. I tested further and found a defecting rule (specific, not CRS) which caused the described behavior: no phase:2 rules on requests without body. I corrected the rule, it should resolve some of my issues. Now, it seems that requests which fail and are not served by Apache (e.g. "Invalid URI in Request.") do not go through the phase:2 rules. Investigating.
Regards, Aymeric -----Message d'origine----- De : Christian Folini [mailto:christian.fol...@time-machine.ch] Envoyé : jeudi 4 février 2016 20:57 À : CHAIB Aymeric (MORPHO) Objet : Re: [Owasp-modsecurity-core-rule-set] Phase request Aymeric, On Thu, Feb 04, 2016 at 10:29:44AM +0000, CHAIB Aymeric (MORPHO) wrote: > I noticed that the version 3 of CRS ruleset sometimes transforms the > rule phase: from phase:1 (v2.2.9) to phase:request. But phase:request > just translates to phase:2 (request body) and, if I understand the > phase processing correctly, requests that do not contain a body will > not be checked against phase:2 rules. (Well, this is what I observe in > my debugging logs. Don't know if it is the ModSecurity standard > behavior or if it comes from my implementation.) It's a bit different. Traditionally ModSec has 5 phases: 1 2 3 4 5 5 is the logging phase when the request is already over. 3 and 4 are the response header and response body phases. With 1 and 2 things are more complicated. 1 used to be the phase running after the requests headers where received. But then people constantly complained the rules in containers as directory / location would simply be ignored (container springing into action only when the request body was received). So Ivan Ristić (somebody correct me if it was not him) gave up and pushed phase 1 on the same apache hook as phase 2. This means, that phase 1 runs on the same apache hook as phase 2. But phase 1 runs before phase 2. (which is a neat detail for some of the more adventurous rule contructs). The method (or the fact that a request has a body or not) is irrelevant for the phases. Phase 2 happens no matter if there is a body or not. If you are not happy with the merging of phase 1 and phase 2, then you can compile ModSec with the option --enable-request-early. That is a good practice in my eyes. For it allows you to block a request _before_ you start to receive the request body. This could come to your advantage in special situations like the prevention of file uploads etc. Lately, some of the phases received an alias: 2 - request 4 - response 5 - logging But that's just an alias. Hope this helps. So it was a conscious move, but that does not mean that I think the general shift of rules onto phase 2 was a very good idea. Ahoj, Christian > > A typical example is the rule id 960911 (REQUEST-20-PROTOCOL-ENFORCEMENT) > which validates the HTTP request line: it seems to me that it should be > validated for requests including those without body, but the phase is now > phase:request on CRS v3. > > Besides, there are a lot of other examples in > REQUEST-21-PROTOCOL-ATTACK where it seems to me that the rules should be put > on phase:1. (E.g. smuggling, response splitting.) The same applies to > REQUEST-10-IP-REPUTATION. > > Do I miss something ? Is this a conscious choice ? > Thanks for enlightening me. > > Regards, > Aymeric Chaib > > # > " This e-mail and any attached documents may contain confidential or > proprietary information. If you are not the intended recipient, you are > notified that any dissemination, copying of this e-mail and any attachments > thereto or use of their contents by any means whatsoever is strictly > prohibited. If you have received this e-mail in error, please advise the > sender immediately and delete this e-mail and all attached documents from > your computer system." > # > _______________________________________________ > 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-s > et # " This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." # _______________________________________________ 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