Re: [mod-security-users] mod_security enhancement idea

[Ryan B. <rcb...@gm...>]

On 4/11/06, joe barbish <joe...@ya...> wrote:
>
>
>  So question is the following code correct.
>
> SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php$"      allow plus
> SecFilterSelective POST_PAYLOAD "(^id=3D[0-9a-z]$)"                 allow
> plus
> SecFilterSelective POST_PAYLOAD "(^pw=3D[0-9a-z]$)"                allow
> plus
> SecFilterSelective POST_PAYLOAD "(^userdigit=3D[0-9a-z]$)"        allow
>
>

"plus" is not a valid mod_security action.  I would suggest that you use
this directive -

SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
SecFilterSelective POST_PAYLOAD "!^(id|pw|userdigit)=3D[0-9a-z]$"


This should work.  Test it out and let me know.

-Ryan


>
>
>
> *Terry Dooher <tdo...@na...>* wrote:
>
> joe barbish wrote:
> > Ryan
> > Thanks for the help.
> >
> > But I don't understand some thing you said.
> >
> > You said that SecFilter "." will deny everything then you say "What
> > happens if there is a new PHP exploit for your mls_verifyemail0.php
> > script? The rules above will not protect against this."
> >
> > The whole idea of the rules is to control what is allowed to pass.
> >
> > The SecFilter "." is suppose to deny everything. Everything means
> > anything which is not one of the coded 'accept' rules, including all
> > known and un-known exploits.
> >
> > If SecFilter "." is not the correct rule to deny everything then what
> > rule will?
> >
>
> SecFilter "." _is_ the correct rule to block everything. However, if you
> this
> on its own, your users may experience some (sarcasm) loss of
> functionality...
>
> Let's assume that the sample rule:
>
> SecFilterSelective REQUEST_URI "^/mls_verifyemail0.php" allow
>
> is the only one you have other than the SecFilter "."; this will make
> mod_sec
> block any request for anything other than that file.
>
> Generally, if the PHP is to be any use at all, then it must take some
> input
> from the client. You can whitelist the specifc files (REQUEST_URI)[1] and
> you
> can whitelist the expected variables (ARGS_NAMES), but if you want to
> whitelist the input (ARGS_VALUES) you have to know _every_ valid
> permutation
> of inputs and filter them specifically.
> Here, you can whitelist certain character sets which will again narrow
> down
> the possible attack vectors, but unless you have a very simple input
> pattern[2] then you're facing a huge job. Trying to tell it in such exact
> terms will likely leave you with an unmanageably huge ruleset. It's like
> trying to use iptables as a spam filter.
>
> Possibly clear as mud, but that's how I understand it. I'll leave the
> internals questions to the big boys and perhaps a fresh thread.
>
> [1] Am I right in believing that REQUEST_URI is just the requested file
> with
> POST, but includes the query string with GET requests? (I'm working from =
a
>
> 1.87 manual)
>
> [2] Example simple input whitelist:
> SecFilterSelective POST_PAYLOAD "!(^m=3D[0-9a-f]{32}$)"
>
> The above rule will only allow one variable m and a valid md5 hash. I
> consider
> this a fairly strong inclusive filter, but only because it's such a simpl=
e
>
> application.
>
> Terry.
>
>  ------------------------------
>  How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call
> rates.
> <http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com=
/evt=3D39663/*http://voice.yahoo.com>
>
>


--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache