[491] in WWW Security List Archive

home help back first fref pref prev next nref lref last post

Security risks with CGI

daemon@ATHENA.MIT.EDU (Garrett Burke)
Thu Mar 2 08:27:27 1995

To: www-security@ns2.rutgers.edu
Date: Thu, 02 Mar 1995 09:23:06 +0000
From: Garrett Burke <gburke@dsg.cs.tcd.ie>
Errors-To: owner-www-security@ns2.rutgers.edu

I'm looking for a comprehensive list of security risks with using CGI
scripts.  The overview doc at www-security has gone for a rewrite, so
I don't know if there is anything there.

Specifically we run Cern httpd 3.0 with proxying and caching enabled
with AFS on a Sun Classic with sunos4.1.3_U1.  Currently the root of
the web is in AFS, so files need to have anyuser read access (as the
server doesn't have a token) We currently use the normal AFS ACLs to
prohibit outside access to parts of the web (i.e not all the web has
anyuser read access and must be accessed using a file: url)

We are not hyper security concious (i.e we also run an anonymous ftp
server, we don't have a firewall, multiple machines on the network
have internet access etc) but would like to know the pros and cons of
allowing cgi scripts before we enable them.


I have broswed through the archive of www-security, looked on hoohoo
and Cern and have come up with the following:


0.1 Documentation for CGI is scattered all over the place.

1.  Main problem is that a shell may get started on the server host.
	This shell will run with the server privlages.
	The whole filesystem may be accessable from this shell.


	Cure: 	Don't use 'eval' in perl
		Parse input for any metachars and get rid of them
		Run the server under a special username that has
		very limited access rights, and most importantly
		no default shell.
		'Chroot' to where the server lives before starting it
		
2.  Comments please on the package 'cgiwrap' from Nathan Neulinger
    <nneul@umr.edu> which blocks running of setuid scripts,
    passes a 'username' with the fields from the form which must match
    the owner of the script, executes the script under that user
    and doesn't rely on the current path to find the script.

    This script executes with server permissions and then it calls
    the user script.

Should scripts be executed with normal user privlages, thus allowing
access that the user has (possibly with a AFS token) or should they be
more restricted i.e execute as the special www user.

3. Image maps, which use full urls, will cause a redirect back to the
client, and thus the only part executed on the server side is the
htimage program.  Is this safe or are there problems here as well.

4.  Many sites have disabled 'POST' and only allow 'GET' and then
search the incoming URL to ensure there is nothing nasty (shell
escapes etc) in it before actually processing it (i.e passing it from
the firewall to the server).  Is anyone catching the data from a
'POST' and processing it in a similar way.

5. From robm@ncsa.uiuc.edu

	Beware the eval statement
	Do not trust the client to do anything
	Be careful with popen and system  (escape special chars)
	Turn off server-side includes

6. Would the TIS HTTP proxy help specifically to protect against
attacks via cgi scripts.  It would provide logging information about
accesses and could restrict access to scripts to authenticated sites.

7.  Martin Hargreaves, ch11mh@surrey.ac.uk set up a cut down
    linux box (see http://www.chem.surrey.ac.uk/~ch11mh/secure.html)
    to run the server and all his web is on the local file system.
    The idea is that Break-ins would be limited to this one box.

If you can limit break ins to a single box, then this makes it much
easier to handle the whole issue of web security.  Any confidental
stuff is not on the box with the externally accessible server.  If
there is a break in and the web is trashed, you put it back up from
the backup that you make everynight ;) You could set up only one
login, which would have no network access, but would have access to
the floppy drive to load new web pages.  Basically a firewall machine
just for http.

Thanks for your time and comments,

Regards,
GB.

:--
: Garrett Burke             | Tel: +353 1 6081539
: Distributed Systems Group | Email: gburke@dsg.cs.tcd.ie 
: Dept. of Computer Science | 
: Trinity College Dublin    | A jug of wine, a loaf of 
: Dublin 2, Ireland         | bread and thou. 

home help back first fref pref prev next nref lref last post