CGI services?

[Albert Lunde]

>What are university web services doing (if anything) to support CGI scripting
>by users?
>
>Our current policy is to not allow the mounting of user-written CGI scripts at
>all, and to consider writing scripts ourselves if the need is generic enough.
>
>However, we have had inquiries from a number of faculty members who wish to
>use CGI-scripting to produce course-based instructional tools on the web (such
>as simulations), as well as administrators who wish to do customized
>form-handling applications. Some of the users are web-savvy; some want to be
>web-savvy; and others simply want to have students do the programming and have
>the scripts up on a web server for them.

I would strongly advise against allowing user-written CGIs unless you have
the staff to do a careful security review of every CGI before it is exposed
to the world.

I am the system adminisrator of two web servers at our university; one
contains "official" content from a hundred or so departmental
content-providers, the other contains personal web pages from a few
thousand users.

* The server containing personal pages simplely forbids user CGIs: we'd
like to provide some generic services but so far this server has been a low
enough priority that there has not been staff time to spend on setting this
up. Our goal here has been to provide very basic mass services with a low
administrative overhead per user.

* The more "official" server allows people in departments to create CGIs,
but discourages it; the majority of user CGI's are legacy stuff. We have a
somewhat generic forms processing script which we use for mail-in forms.

For other kinds of development the approach I take is to create a test CGI
directory that can only be accessed from a few IP addresses, and let
someone develop there, and have the CGI reviewed for security before
putting it into production.

* There is also a faculty web server on campus that allows for more complex
CGI development; I think their approach is to pair up a faculty member with
a staff member of our instructional computing group when doing development.

So I guess you have a range of choices, depending on on how much hands-on
involvement you can afford to have with the users in question.

A reason you should be careful about this is that a large fraction of
security bugs can be exploited by an unprivledged user on the system, but
not by anyone on the net. If you accidentally grant the world the ability
to execute arbitrary commands as your web server userid, you may have
doubled or tripled your security risks.

The ability to write a CGI script is not equal to the ability to write a
secure script; many of our "legacy" CGIs had been written by computer
center staff, but a majority of them had some potential security risks.

Don't assume that CGI scripts distributed with your web server or
commercial software are secure either. A number of security alerts have
been about demonstration CGIs shipped with one or another web server.

Likely sorts of risks:
1) the ability to display arbitrary files
2) the ability to send mail or perform other network operations on
arbitrary addresses
3) the ability to execute arbitrary commands

The most basic source of failure is assuming input will only come from the
form you've provided. A CGI script needs to be able to process arbitrary
input crafted by a hostile person.

Forms this can take are:
1) failure to filter unprintable characters, shell escape characters, or
other characters with special significance to the programs used in the
script.

2) putting stuff like filenames or mailing addresses as parameters in the
form or the URL and not placing tight restrictions on their use.

3) buffer overflows


A good place to get started in reading about these issues on Unix is:

Practical Unix & Internet Security, 2nd edition. by Simson Garfinkel & Gene
Spafford (published by O'Reilly)

The second edition has a chapter "WWW Security" with a section "Writing
Secure CGI Scripts and Programs".

---
    Albert Lunde                      Albert-Lunde at nwu.edu