Thanks for the update, and good luck! Christian
On Mon, Feb 08, 2016 at 11:24:40AM +0000, CHAIB Aymeric (MORPHO) wrote: > 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." > # -- mailto:christian.fol...@netnea.com http://www.christian-folini.ch twitter: @ChrFolini _______________________________________________ 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
