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

[joe b. <joe...@ya...>]

ok I have changed the rules to this
   
  # This services the frame home page
SecFilterSelective REQUEST_URI "^/index.htm$"                             allow
SecFilterSelective REQUEST_URI "^/00.00-web_style_sheet.css$"    allow 
SecFilterSelective REQUEST_URI "^/00.00_Header.htm$"                 allow
SecFilterSelective REQUEST_URI "^/mls_home_page.php$"              allow
SecFilterSelective REQUEST_URI "^/mls_products.htm$"                  allow 
SecFilterSelective REQUEST_URI "^/powered_by_FreeBSD.gif$"        allow
SecFilterSelective REQUEST_URI "^/powered_by_apache_bsd.gif$"    allow 
  SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php$"               allow
   
  Appending a $ to the end of the script name means only the file with no arguments is allowed in a GET request. This stops malice inserts correct?
   
  mls_home_page.php script is all html code with only php code for a page hit counter. It open & reads the count record, bumps it by 1 and rewrites it. Then echo's the count value to the screen.
  So appending a $ to it works fine.
   
  The mls_fsbo_signup.php script is a self contained show form and process form. The debug log shows this when it's executed. 
   
  34][/mls_fsbo_logon.php] Parsing arguments...
34][/mls_fsbo_logon.php] Raw cookie header "PHPSESSID=95a21d7930bf5b3955335b8df4
34][/mls_fsbo_logon.php] Adding cookie "PHPSESSID"="95a21d7930bf5b3955335b8df4a7
34][/mls_fsbo_logon.php] Read 51 bytes from POST [r=817c034]
34][/mls_fsbo_logon.php] content-type = "application/x-www-form-urlencoded"
34][/mls_fsbo_logon.php] Parsing variables from POST payload
34][/mls_fsbo_logon.php] Adding parameter: [id][barbish1]
34][/mls_fsbo_logon.php] Adding parameter: [pw][jjb722]
34][/mls_fsbo_logon.php] Adding parameter: [userdigit][sixvn]
34][/mls_fsbo_logon.php] Adding parameter: [submit][Submit]

   
  You well notice that the rule for mls_fsbo_logon.php has $ appended to it.  The parameters id, pw, and userdigit are checked in the php script for lower case Alpha-Numeric characters. So according to previous post on this list I can add a line something like this to insure bogus stuff has not been inserted.
  SecFilterSelective POST_PAYLOAD "!(^m=[0-9a-f]{32}$)"
   
  So question is the following code correct.
   
  SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php$"      allow plus
  SecFilterSelective POST_PAYLOAD "(^id=[0-9a-z]$)"                 allow plus
  SecFilterSelective POST_PAYLOAD "(^pw=[0-9a-z]$)"                allow plus
SecFilterSelective POST_PAYLOAD "(^userdigit=[0-9a-z]$)"        allow
   
   
   
   
  
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=[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 simple 
application.

Terry.

		
---------------------------------
How low will we go? Check out Yahoo! Messenger’s low  PC-to-Phone call rates.