1. Introduction

Normal web pages are static files. You create the file in HTML, put it on disk, and every time a browser fetches the file, it always gets the same file. This is simple and it gets the job done.

However, sometimes static files are not enough. Sometimes you want the returned page to depend on a form that the user submitted. Or perhaps you want to record the information from the form in a disk file. Instead of serving a static file, you want the web server to run a program and feed the result of this program back to the web browser. Such a program is called a CGI program or CGI script.

(CGI is Common Gateway Interface, if you must know. The name is meaningless. And although the difference between "script" and "program" can spark religious wars among geeks, I'll use the terms interchangeably.)

The ACCC now allows general users to run CGI scripts, at least on an experimental basis. This is not risk-free, however, and you must determine if your need outweighs the risks. Also realize that there are limitations on your scripts, so you still might not be able to do everything you desire.

Why worry about CGI scripts?

• It's very easy to write insecure scripts. Trust me on this. And insecure scripts can allow malicious hackers to crack your computer account.
• It's very easy to destroy your own files, even if you aren't attacked by hackers. Since you don't control when your scripts are run, multiple copies of the same script can try to write to the same file.
• It's easy to fill up your home directory disk quota with useless files.
• It's easy to eat up machine resources.

If you choose to run CGI scripts, you are choosing to accept responsibility for the results, good or bad. And like any program, if your cgi script causes trouble for the server, we will have to shut it off.

If you are sufficiently skilled, CGI scripts can be run in reasonable safety. And if you need to process forms, upload files, update or search databases, they are necessary. Of course, you can use scripts, such as FormMail or SearchUIC, provided by the ACCC. But you can also roll your own if you feel the need.

You might even try your hand at CGI scripts just for fun and education. Of course, CGI programming is 98% programming and 2% CGI. But programming is fun, so why not?

Why not? Because they can be dangerous to the unwary. See the warnings above. And due to the limitations, the CGI may still not do all you want.

HTML is fairly simple, and anyone can get useful results from a few tags. CGI programming is not so simple. You really do need to know something about programming. It's within reach of anyone who really wants to learn some programming, but if you are not already proficient at programming, you are not going to become a useful CGI/perl programmer in a couple of hours. You have to decide how much your time is worth.

There exist several alternatives, so you can do CGI-like things without writing your own scripts. And the ACCC supplied scripts are not subject to the UIC-only limitations that your scripts must obey. For example:

• Server-side includes can include one file inside another. This is very useful for including a common piece of html, like a menu bar, inside many other html files. CGI would be overkill for this need. And SSI can do a small number of other things, like print the date a file last changed. Upcoming versions of SSI will even allow conditionals. SSI is not subject to attack like CGI.
• If you want to process an input form, and send the results by email or write them to a file, try out FormMail. You can use a pre-written CGI script, and not have to bother with your own.
• If you want to provide a search of your pages, consider SearchUIC. Again, you can use a pre-written CGI script, and also use a pre-gathered web index. For efficiency and power of searching, this is hard to beat.
• If you just want to keep track of web hits, analyzing the web logs is much better than trying to keep track of your own hits. Try out webalizer. Truly, it couldn't be simpler.

We now have support for different languages. But due to the nature of the interpreters, we have different limitations on their use. We can't make all the dangers of CGI go away, but we try to minimize them. We also try to limit any problems so only your account is affected, and we try to make it hard to create problems by accident.

Note that ACCC provides some existing scripts for general use, and the limitations below don't apply to these scripts.

Advantages

• Can be run from personal accounts or departmental directories (if you have write access).
• No limitation on browser IP or campus authentication, although you certainly can use bluestem if you want to.
• Accounts are automatically enabled for php. You don't have to request anything special from ACCC to start coding.

Limitations

• The script will run as your identity. That means if anything goes wrong, it goes wrong with all of your personal privileges, and can harm anything that your personal account can harm.
• The scripts can run only from certain directories. Any files read or written by the php scripts are limited to the directory trees from which they run.
• PHP has had internal security issues before, and like any program, will again. For example, it probably isn't hard to accidently set up a mail cgi that can be exploited by others to send spam. You must take care to code securely. We may impose additional restrictions if this becomes a problem.

Advantages

• Some people prefer perl.

Limitations

• Only browsers from campus, or those that have authenticated via bluestem, can connect to your CGI scripts. That is, only people at UIC can use your scripts. Please understand this. If you must run perl scripts for the general internet, you must contact ACCC first and make special arrangments.
• Your scripts will run under your identity, not the web server's identity. That means that your scripts have intrinsic permission to write or delete all of your own files. If they go berserk, you suffer.
• Taint Mode is turned on automatically for you. This is not a major limitation, but it does make it a little harder to shoot yourself in the foot accidentally. If you are hell-bent on destroying your feet, however, you still can.

Advantages

• Some people prefer asp.

Limitations

• Can only be run as part of a departmental web page, not from personal accounts.
• Cannot access files outside the asp directory tree.
• ASP only runs from special directories. You must contact ACCC ahead of time, to have such a directory set up for you.
• We cannot provide any support for vbscript itself. You must write and debug on your own.

Do NOT trust the user!!

I can't emphasize this enough. Most CGI scripts respond to forms or to URLs with additional parameters. No matter how you design your forms, no matter how you construct your URLs, they are easily circumvented by a malicious user. The user can send your script anything, any time. So never take the user's word for anything -- check all input for validity before using it to open a file, or send mail, or to use it in some calculation.

Do NOT trust random scripts from the web!!

There are all sorts of free CGI scripts on the web. But just because a script is on the web, that doesn't make it secure or efficient. Or even sensible. Back in the early days, NCSA bundled a famously insecure CGI program along with its web server. Even though they invented lots of web technology, they still had a learning curve.

Do NOT trust yourself!!

OK, so you have to trust yourself to some extent. But if the pros at NCSA can make mistakes, so can you. And so can I. So beware, and don't assume that if your code passes your testing, it's OK.

There are many pages on the web about safe CGI programming. I'd start with Yahoo.