> hey there..;)
> I'm using 1.8.7-1 on Debian Sarge and encountered a problem in context
> with skipping a rule from a 2nd path.
> The rule is already skipped by 1 path:
> SecFilterSelective REQUEST_URI "^/admin/admin\.php" chain,pass
> SecFilterSelective ARG_url "^http:/" skipnext:2
> SecFilter "(http|https|ftp)\:/" chain
> SecFilterSelective ARGS_VALUES "^http:/"
> but now I need to add a 2nd path and simply can't make it work, I
> already tried to add a new skip rule above the old one but neither
> skipnext:2 nor skipnext:4 works.
> the path looks like:
> Can anybody point me into the right direction how to make a 2nd
> exception for /stream/services/services/players/ ?
The straight-forward solution to this would probably be to just extend
the first regular expression to match both of your URIs:
[ + the last three rules from above ]
Please also note the ending "$" of the regexp. By only stating the "^",
your match uses a "starts-with" syntax. Though perhaps not a problem
with your admin.php-skript it might be dangerous with some applications
using "request-path parameters", i.e. that encode their parameters into
By default (without ^- and $-anchors) the pcre checks for the string to
contain the pattern given by the expression (this is different in Java
for example) in any part of the string. To exactly match a string you
need ^ and $.
Another thing to regard might be a paramter-check for wimpyApp that
could be useful for limiting the url that may be specified to a set of
legal values (i.e. your site or legal remote sites).
A last thing: You should check for Apache2 and ModSecurity 2.x ;-) Even
if you cannot switch your application-apache to 2.x you might setup a
second one doing reverse-proxying (in parallel for testing at first) and
deploy ModSecurity 2.x within that. Having both running on the same
system shouldn't add a big latency on the responses from what I
experienced so far ...