Hi,

We tried this to allow multiple specified methods (get and subscribe in 
this example) on one location with different rules:

<LocationMatch "/some/url">
    SecRuleA
    SecRuleB

    SecRule REQUEST_METHOD "!^GET$" "t:none,skip:3"
    SecRule1
    SecRule2
    SecRule3

    SecRule REQUEST_METHOD !"!^SUBSCRIBE$" "t:none,skip:4"
    SecRule4
    SecRule5
    SecRule6
    SecRule7
    SecAction "allow,t:none,msg:'Request method passed all checks and is thus allowed'"
</LocationMatch>

Which resulted in a deny for every subscribe method for the specified 
location. This is because

SecRule REQUEST_METHOD "!^GET$" "skip:3"

matches "SUBSCRIBE /some/url/".

Anyways, we've tried a bit and found the following solution which worked 
fine for us:

<LocationMatch "/some/url">
	SecRule REQUEST_METHOD "!^(GET|SUBSCRIBE)$"
	SecRule REQUEST_METHOD "^GET$" "t:none,chain"
	SecRule1
	SecRule2
	...
	SecRule REQUEST_METHOD "^SUBSCRIBE$" "t:none,chain"
	SecRule3
	SecRule4
	...
	SecAction "allow,t:none,msg:'Request method passed all checks and it is thus allowed'"
</LocationMatch> 

The fist rule denies every other method than get or subscribe (eg. post 
or search) for the specified location. This rule is followed by two rule 
chains for the allowed methods for this location.
NB. all rules are processed in phase 2.

greetz,

Rick & Helwin.

Ryan Barnett schreef:
>> -----Original Message-----
>> From: mod-security-users-bounces <at> lists.sourceforge.net [mailto:mod-
>> security-users-bounces <at> lists.sourceforge.net] On Behalf Of Christian
>> Bockermann
>> Sent: Friday, March 30, 2007 9:41 AM
>> To: modsecowa <at> gmail.com
>> Cc: Mod Security
>> Subject: Re: [mod-security-users] Two LocationMatch blocks for the
>>     
> same
>   
>> fileor directory with different methods
>>
>>
>> Am 30.03.2007 um 15:33 schrieb modsecowa <at> gmail.com:
>>
>>     
>>> Hi,
>>>
>>> In Outlook Web Access, it is possible for some files or directories
>>> that both the GET and SUBSCRIBE methods are used. However, we can't
>>> create two LocationMatch blocks in the ModSecurity configuration
>>> for the same directory or file. That is because the first
>>> LocationMatch block will always match and if the used method does
>>> not comply with the rule the request is rejected. So this means
>>> that the second LocationMatch block that contains the correct
>>> method will never be looked at. It is possible to create one "big"
>>> rule that accepts both GET and SUBSCRIBE methods, but then you also
>>> have to specify all possible headers and other options which
>>> originally never will be used against the file or directory when
>>> one of the two methods is used. But ModSecurity is then configured
>>> to accept those options, which doesn't seem appropiate when using
>>> whitelisting/positive security model.
>>>
>>> Perhaps there is simple way to work around this, but we did not
>>> find the solution yet. Does someone know how to handle this
>>> scenario using the positive security model in ModSecurity?
>>>
>>> We are using ModSecurity 2.1.0 with Apache 2.2.4 on a Linux
>>> distribution.
>>>
>>>       
> [Ryan Barnett] Keep in mind that you don't have to use the Apache Scope
> directives such as LocationMatch to trigger on URL locations.  You can
> instead use ModSecurity chained rules.  Most people opt to use the
> LocationMatch directives since it is a bit "prettier" on the eyes to
> visually see what context the rules are running in however there are
> some limitations as you have pointed out.  Additionally, Apache scope
> directives can only run in Mod phase:2 so you could use Mod chained
> rules in phase:1 if you wanted to check on the URL and Request Headers.
>
>   
>> You can create rules that depend on the request-method like this:
>>
>>
>> <LocationMatch "/some/url">
>>     SecRuleA
>>     SecRuleB
>>
>>     SecRule REQUEST_METHOD !"GET" "skip:3"
>>     SecRule1
>>     SecRule2
>>     SecRule3
>>
>>     SecRule REQUEST_METHOD !"SUBSCRIBE" "skip:4"
>>     SecRule4
>>     SecRule5
>>     SecRule6
>>     SecRule7
>> </LocationMatch>
>>
>>
>> This way, rules "A" and "B" are checked for all requests that hit "/
>> some/url" regardless
>> by which method. When a GET-request arrives, additionally Rules 1,2,3
>> get checked and
>> as "GET" does not match "SUBSCRIBE" rules 4,5,6,7 will be skipped and
>> vice versa.
>>
>>     
> [Ryan Barnett] I think your description of the rules is reversed.  If
> the Request Method for that location is GET, then rules A, B, 4, 5, 6
> and 7 will be executed in that order.  If the Request Method is
> SUBSCRIBE, then rules A, B, 1, 2 and 3 will execute in that order.  This
> is also assuming that all of those sample rules are running in phase:2
> (since it was not specified).
>
> A few more syntax notes - the "!" character for inverted rules needs to
> go inside the double-quotes otherwise it is assuming that the
> double-quotes are part of the actual RegEx pattern.  Should be like this
> - "!GET" - and even better is like this with anchor tags - "!^GET$".
> Also check to verify if there are any transformation functions (such as
> lowercase) being applied.  If so, the rule should then read - "!^get$"
>
>   

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV