RE: Secure CGI Implementation

[Bill Moseley <moseley@hank.org>]

On Sun, 29 Dec 2002, Michael Olds wrote:

> This is what I would like to set up because I would like to offer server
> space to one user aside from myself that I trust, and who will need to make
> modifications to his scripts via SFTP (using SSH2); but I would like to be
> protected in the event of his user name and password being discovered, and
> in the event of him making a mistake in his setups.

Well, you should set up his account as someone that cannot be trusted.
Set quotas and make sure you have your permissions set correctly.  Don't
depend on the web server to provide security (other than knowing what user
it's running as).

I don't use Debian's packaged Apache, so I can't really answer too much,
but...

Answering in reverse direction because I think this might be what you are
wondering:

> If necessary, this way I can change one user's cgi-bin to "cgi-local", or
> "cgi-1" although this still does not make good sense to me and does not fit
> in with what I see or what is given as examples in the tutorials out there
> (I would like to know how my host for BuddhaDust has been able to give me
> "cgi-local" under my document root with me as owner and user...I will ask
> next chance I get).

Because SuEXEC.  See: http://httpd.apache.org/docs/suexec.html

So the server runs as "nobody" normally so that should limit what it can
do.  With SuEXEC Apache runs *CGI* scripts as the given user.  

This is both more and less secure for the user in a shared environment.  
If blackhats hack through an insecure CGI script then they are running as
the user.  But it also means each user can be more protected from other
uses on the same machine (e.g. data read by cgi scripts can be chmod 600).

How you setup SuEXEC depends on how you want to provide access to the
other web site.  Is http://yoursite/~yourfriend/ ok?  Then you can use the
UserDir method.

If your friend has their own domain name then use name-based virtual
hosting then I believe you can use the User directive.

Another way to go is to run separate copies of Apache, but you will need
two different IP numbers or run on different ports.  Then you can just set
the User and Group for your friend.  You can also use a reverse proxy to
listen on port 80 and then proxy to different servers running with
different User settings.

> httpd.conf
> 
>    Global Server Settings
> 
>    DocumentRoot "/www/users"
> 
>    <Directory "/www/users">
>    Options ExecCGI
>    AllowOverride All
>    Order allow,deny
>    Allow from all
>    </Directory>

I setup my Apache configs with everything in a virtual host -- either
name-based or port based virtual hosts.  I also have not used UserDir more
than a few times so you will need to decide how best to

But in the main server config I alwasy start out like:

<Directory />  
    AllowOverride none
    order deny,allow 
    Deny from all
</Directory>

That changes the default to block everything.  Then from there you enable
things.

> <VirtualHost 000etc>
>    UseCanonicalName off
That's the default, IIRC

>    DocumentRoot "/www/users/usr1/public_html"
>    ScriptAlias /cgi-bin/ "/www/users/usr1/cgi-bin/"

You could also just let public_html/cgi-bin be the cgi-bin directory.

   <directory /www/users/usr1/public_html>
      SetHandler cgi-script
      Options +ExecCGI
   </directory>


People say cgi-bin should not be in documentroot, but I don't see any good
reason for that.  After all it is that way form the web space point of
view.

I typically don't even setup a cgi-bin directory.  I often use .htaccess
files and don't even use .cgi as an extension.

<files foo.html>
   SetHandler cgi-script
   Options +ExecCGI
</files>

Everyone has their own methods, of course.  But I like to only enable
things I want to be run as CGI scripts.

Read the docs on UserDir to see if you want to go that route.  I'd
probably just use name-based virtual hosting and SuEXEC.


-- 
Bill Moseley moseley@hank.org