Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

---

Security Beyond Your Own

sendmail has an almost legendary history of security problems. Almost from the beginning, hackers have found clever ways to exploit sendmail and gain unauthorized access to the computers that run it.

But sendmail is hardly unique. Dozens—if not hundreds—of popular, common tools have security problems, with more being discovered each year.

The point is that it’s not only the security of your own CGI script that you must worry about, but the security of all the programs your CGI script uses. Knowing sendmail’s full range of documented capabilities is important, but perhaps more important is knowing capabilities that are not documented because they probably aren’t intended to exist.

Keeping up with security issues in general is a necessary step to maintain the ongoing integrity of your Web site. One of the easiest ways to do this is on Usenet, in the newsgroups comp.security.announce (where important information about computer security is broadcast) and comp.security.unix (which has a continuing discussion of UNIX security issues). A comprehensive history of security problems, including attack-prevention software, is available through the Computer Emergency Response Team (CERT) at ftp.cert.org.

---

Inside Attacks: Precautions with Local Users

A common mistake in CGI security is to forget local users. Although people browsing your site over the Web usually won’t have access to security considerations, such as file permissions and owners, local users of your Web server do, and you must guard against these threats even more than those from the Web.

---

CAUTION:  

Local system security is a big subject, and almost any reference on it will give you good tips on protecting the integrity of your machine from local users. As a general rule, if your system as a whole is safe, your Web site is safe, too.

---

The CGI Script User

Most Web servers are installed to run CGI scripts as a special user. This is the user that owns the CGI program while it runs, and the permissions granted limit what the script can do.

Under UNIX, the server itself usually runs as root to enable it to use socket port 80, then changes to another non-privileged user. Thus, when the server executes a CGI program, it does so as an innocuous user, such as the commonly used nobody, and the capability to configure this behavior is available on many servers. It is dangerous to run CGI scripts as root! The less powerful the user, the less damage a runaway CGI script can do.

Setuid and ACL Dangers

You should also be aware if the setuid bit is set on your UNIX CGI scripts. If enabled, no matter what user the server runs programs as, it will execute with the permissions of the file’s owner. This, of course, has major security implications—you can lose control over which user your script runs as.

Fortunately, the setuid bit is easy to disable. Executing chmod a-s on all your CGI scripts will guarantee that it’s turned off, and your programs will run with the permissions you intended.

Of course, in some situations you may want the setuid bit set— for example, if your script needs to run as a specific user to access a database. In this case, you should make doubly sure that the other file permissions on the program limit access to it to those users you intend.

A similar situation can occur under Windows NT. Microsoft’s Internet Information Server (IIS) normally runs CGI scripts with the access control list (ACL) of IUSR_computer. However, by editing a Registry entry, IIS can be set to run scripts as SYSTEM. SYSTEM has much wider permissions than IUSR_computer and can cause correspondingly more damage if things go wrong. You should make sure that your server is configured the way you intend.

Community Web Servers

Another potential problem with the single, common user that Web servers execute scripts as is that a single human being is not necessarily always in control of the server. If many people share control of a server, each may install CGI scripts that run as, for example, the nobody user. This enables any of these people to use a CGI program to gain access to parts of the machine that they may be restricted from, but that nobody is allowed to enter.

Probably the most common solution to this potential security problem is to restrict CGI control to a single individual. Although this may seem reasonable in limited circumstances, it’s often impossible for larger sites. Universities, for example, have hundreds of students, each of whom wants to experiment with writing and installing CGI scripts.

Using CGIWrap

A better solution to the problem of deciding which user a script runs as when multiple people have CGI access is CGIWrap. CGIWrap, which is included on the CD-ROM that accompanies this book, is a simple wrapper that executes a CGI script as the user who owns the file instead of the user whom the server specifies. This simple precaution leaves the script owner responsible for the damage it can do.

If the user joanne, for instance, owns a CGI script that’s wrapped in CGIWrap, the server will execute the script with joanne’s permissions. In this way, CGIWrap acts like a setuid bit but has the added advantage of being controlled by the Web server rather than the operating system. Therefore, anybody who sneaks through any security holes in the script will be limited to whatever joanne herself can do—the files she can read and delete, the directories she can view, and so on.

Because CGIWrap puts CGI script authors in charge of the permissions for their own scripts, it can be a powerful tool not only to protect important files owned by others, but also to motivate people to write secure scripts. The realization that only their files would be in danger can be a powerful persuader to script authors.

CGI Script Permissions

You should also be aware of which users own CGI scripts and what file permissions they have. The permissions on the directories that contain the scripts are also very important.

If, for example, the cgi-bin directory on your Web server is world writeable, any local user can delete your CGI script and replace it with another. If the script itself is world writeable, anybody can modify the script to do anything they want.