Re: Phases & SecDefaultAction

Am 18.04.2007 um 09:54 schrieb Marc Stern:
> Christian Bockermann wrote:
>>>>> Can I regroup several rules, like
"phase:1-2" for ARGS ?
>> Should work. It will check ARGS against the
header-fields
>> (QUERY_STRING-ARGS) in phase:1 and check
>> ARGS against BOTH (header- AND payload-fields) in
phase:2
> Which syntax do I have to use ?
>     "phase:1-2" does only work for phase 1
>     "phase:1,phase:2" does only work for
phase 2
>
> If I don't specify any phase, it should work, but will
it parse ARGS
> also during phase 3 & 4 ?
> It would be a pity to encode lines twice :-(

"Should work" was meant to regard two rules, one
in phase-1 the other
in phase-2. As far as I know you can only specify a rule to
be in ONE
phase.

A rule that is defined in phase-X will be evaluated in that
phase and
not in any other phase. You don't need to specify it twice
(as in your
example). If you need to access HEADER and BODY data, you
just specify
your rule to be in phase-2 - that's it.

Phase-1 is after reading the header, that is, all
header-properties are
available. Phase-2 ist after reading the body. That is, all
header- AND
body-properties are available.

Regards,
     Chris

------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
mod-security-users mailing list
mod-security-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-
security-users

Am 18.04.2007 um 10:38 schrieb Marc Stern:

> To clarify my previous post, I tried several syntaxes
to parse both  
> query/post args:
>    1. SecRule ARGS "..."
>    2. SecRule ARGS "..."
"phase:1-2"
>    3. SecRule ARGS "...""phase:1,
phase:2"
>    4. SecRule ARGS "..." "phase:1"
>        SecRule ARGS "..."
"phase:2"
>
> 1 & 2 only work for query args.
> 3 only works for post args.
> Only 4 works for both.

That is probably, because when the 3rd rule is created, it
will be  
set to be in
phase-2, the same as in the 2nd rule. (I guess, parsing
"1-2" will  
either return
"1", or revert into the default-action).

Anyway I didn't expect modsec to even accept
"phase:1-2".


> If I look to core rules, I see that they use, to block
SQL  
> Injection, "SecDefaultAction
log,pass,phase:2,..."
> So, it seems they only check POST args ???

No, see my answer to your previous mail. In Phase:2 ARGS
contains the  
POST- as well as
the GET-arguments. The only feature, that this lacks, is
that you  
cannot distinguish to
check a GET-arg or a POST-arg in Phase:2 (as it will always
check both).

So, to check for SPAM-Injection for example you could just
use

	SecRule ARGS
"n[[:space:]]*(to|bcc|cc)[[:space:]]*:.*" 

            "phase:2,deny,status: 
500,t:tolowercase,t:urldecode,msg:'Possible
SPAM-Injection'"

If you defined your default-action to be in phase:2
somewhere as follows

	SecDefaultAction
"log,phase:2,t:urldecode,t:tolowercase,deny,status: 
500"

then you don't need to specify all this as your rule will
INHERIT  
these actions and your
rule can be shortened to this:

	SecRule ARGS
"n[[:space:]]*(to|bcc|cc)[[:space:]]*:.*"

Regards,
     Chris

------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
mod-security-users mailing list
mod-security-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-
security-users