Apache mod-security

Ryan Barnett | 1 Oct 16:07

Re: SeRule ARGS:

> -----Original Message-----
> From: mod-security-users-bounces <at> lists.sourceforge.net [mailto:mod-
> security-users-bounces <at> lists.sourceforge.net] On Behalf Of Achim
Hoffmann
> Sent: Monday, October 01, 2007 9:19 AM
> To: mod-security-users <at> lists.sourceforge.net
> Subject: [mod-security-users] SeRule ARGS:
> 
> how do we destinguish GET from POST variables in
>   SecRule ARGS:dirty getme
>   SecRule ATGS:dirty postme
> 
> (assuming that dirty is in the QUERY_STRING *and* the HTTP body)
> 
[Ryan Barnett] Yeah, this is a bit quirky to try and enforce these ARGS
to be only in either a QUERY_STRING or POST_PAYLOAD.  You essentially
have to check both locations.  This is how REMO rules accomplish this
issue.  If you want to enforce only allowing the "dirty" argument to be
allowed in the POST payload, then you can use a rule similar to this -

<Location /cgi-bin/foo.php>
SecRule QUERY_STRING "^dirty[=&]|^dirty$"
"phase:2,t:none,deny,id:1,status:501,severity:3,msg:'Postparameter dirty
is present in query string. This is illegal.'"
SecRule ARGS:dirty "^postme$"
"phase:2,t:none,deny,id:1,status:501,severity:3,msg:'Postparameter dirty
matched.'"
</Location>

Conversely, if you want to only allow the "dirty" argument to be allowed

(Continue reading)

headers

Brian Rectanus | 1 Oct 18:18

Re: SeRule ARGS:

To make this easier in 2.5.0, you will be able to use ARGS_GET,
ARGS_POST, ARGS_GET_NAMES, ARGS_POST_NAMES.

Looks for these feature (and many others) in the next development
release for 2.5, 2.5.0-dev3 which should be out shortly.

later,
-B

Ryan Barnett wrote:
>> -----Original Message-----
>> From: mod-security-users-bounces <at> lists.sourceforge.net [mailto:mod-
>> security-users-bounces <at> lists.sourceforge.net] On Behalf Of Achim
> Hoffmann
>> Sent: Monday, October 01, 2007 9:19 AM
>> To: mod-security-users <at> lists.sourceforge.net
>> Subject: [mod-security-users] SeRule ARGS:
>>
>> how do we destinguish GET from POST variables in
>>   SecRule ARGS:dirty getme
>>   SecRule ATGS:dirty postme
>>
>> (assuming that dirty is in the QUERY_STRING *and* the HTTP body)
>>
> [Ryan Barnett] Yeah, this is a bit quirky to try and enforce these ARGS
> to be only in either a QUERY_STRING or POST_PAYLOAD.  You essentially
> have to check both locations.  This is how REMO rules accomplish this
> issue.  If you want to enforce only allowing the "dirty" argument to be
> allowed in the POST payload, then you can use a rule similar to this -
>

(Continue reading)

headers

Achim Hoffmann | 2 Oct 21:20

Re: SeRule ARGS:


Hi Brian, Ryan,

thanks for this info, I'll wait 'til 2.5 ..

{-: Achim

On Mon, 1 Oct 2007, Brian Rectanus wrote:

!! To make this easier in 2.5.0, you will be able to use ARGS_GET,
!! ARGS_POST, ARGS_GET_NAMES, ARGS_POST_NAMES.
!!
!! Looks for these feature (and many others) in the next development
!! release for 2.5, 2.5.0-dev3 which should be out shortly.
!!
!! Ryan Barnett wrote:
!! > [Ryan Barnett] Yeah, this is a bit quirky to try and enforce these ARGS
!! > to be only in either a QUERY_STRING or POST_PAYLOAD.  You essentially
!! > have to check both locations.  This is how REMO rules accomplish this
!! > issue.  If you want to enforce only allowing the "dirty" argument to be
!! > allowed in the POST payload, then you can use a rule similar to this -
!! >
!! > <Location /cgi-bin/foo.php>
!! > SecRule QUERY_STRING "^dirty[=&]|^dirty$"
!! > "phase:2,t:none,deny,id:1,status:501,severity:3,msg:'Postparameter dirty
!! > is present in query string. This is illegal.'"
!! > SecRule ARGS:dirty "^postme$"
!! > "phase:2,t:none,deny,id:1,status:501,severity:3,msg:'Postparameter dirty
!! > matched.'"
!! > </Location>

(Continue reading)