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

Reply via email to