You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Ronald F. Guilmette" <rf...@monkeys.com> on 2002/05/31 20:05:24 UTC

Re: [OT] Need a new feature: Listing of CGI-enabled directories.

In message <20...@cryptocracy.com>, 
Zac Stevens <zt...@cryptocracy.com> wrote:

>Hi Ron,
>
>Thanks for your detailed response to my post, I'll reply later this
>evening off list.
>
>I do want to jump in on this, though..
>
>On Fri, May 31, 2002 at 12:24:30AM -0700, Ronald F. Guilmette wrote:
>> In the case of FormMail scripts, if the big web hosting companies can
>> just scan all of their CGI directories for them every night and then
>> simply `rm' or `chmod 0000' anything found by the scans of the previous
>> night every morning, then that will be about 99.9% sufficent to eliminate
>> the problem.
>
>To provide you with a bit of context, my comments come after having run a
>Solaris/Apache-based virtual hosting service in Australia for approximately
>5000 sites on around 200GB of disk (on a Network Appliance filer.)  I'm
>security conscious, but I'm also pragmatic - as you yourself seem to be
>aware, commercial realities do put a stop to best practices some of the
>time.
>
>I have tried, and failed, in attempts to correct bad user behaviour in the
>means you have described above.  In addition to removing execute
>permissions and chown'ing files to root, I have attempted to leave messages 
>by way of conspicuously-named files in the relevant directories.
>
>None of this was met with much success.  Typically, the user would
>re-upload the script, or delete and re-upload the entire site, and the
>problem would begin anew...

You have just written a rationale statement for exactly what I am trying
to develop, i.e. a procedure whereby web hosting firms can scan (rescan?)
all of their CGI-enabled directories for new (or re-installed) problems
every single night.

>The problem is that none of these things alerts the user to the problem -
>it just creates a new problem to grab their attention.  In sites where
>valid contact e-mail addresses are available for every customer, this can
>be a more effective form of resolving the issue.

OK, let me clarify that _my_ job at this point _isn't_ to figure out how
to alert the end-users that they have screwed up (by installing bad scripts).
That is the responsibility of the individula web hosting firms to figure
out a procedire/mechanism for doing that.  *My* job is just to give these
web hosting firms a procedire they can use to at least detect 100% of the
bad CGI scripts that their end-lusers have installed, say, over the past
24 hours.  If I can just do that, then I will have at least done my part.

>2) The sendmail binary was replaced with a script which did sanity checking
>   and added identifying details.
>
>This is a simple and extremely effective way to put an end to the problem
>of spam mail originating from virtual-hosted customers...

Please elaborate.  Please describe the ``sanity checking'' you are talking
about and please explain to me how it actually prevented spam from leaving
your web servers.

(I have been down this road already with some web hosting firms, and I
don't know of any kind of ``sanity checking'' that can be applied to
e-mail messages generated by CGI scripts that would still allow end-users
of the web hosting company to, say, have the output of their forms e-mailed
to their @yahoo.com accounts.)