Security should be the sensible webmasters’ first and last concern. This list of questions, all of which you should ask yourself, is from Sysadmin: The Journal for Unix System Administrators, at http://www.samag.com/current/feature.shtml. See also Chapter 11 and Chapter 12.
Is all input parsed to ensure that the input is not going to make the CGI script do something unexpected? Is the CGI script eliminating or escaping shell metacharacters if the data is going to be passed to a subshell? Is all form input being checked to ensure that all values are legal? Is text input being examined for malicious HTML tags?
Is the CGI script starting subshells? If so, why? Is there a way to accomplish the same thing without starting a subshell?
Is the CGI script relying on possibly insecure environment variables such as PATH?
If the CGI script is written in C, or another language that doesn’t support safe string and array handling, is there any case in which input could cause the CGI script to store off the end of a buffer or array?
If the CGI script is written in Perl, is taint checking being used?
Is the CGI script SUID or SGID? If so, does it really need to be? If it is running as the superuser, does it really need that much privilege? Could a less privileged user be set up? Does the CGI script give up its extra privileges when no longer needed?
Are there any programs or files in CGI directories that don’t need to be there or should not be there, such as shells and interpreters?
Perl can help. Put this at the top of your scripts:
#! /usr/local/bin/perl -w -T use strict; ....
The -w flag to Perl prints various warning
messages at runtime. -T switches on
taint checking, which prevents the malicious
program the Bad Guys send you disguised as data doing anything bad.
The line use strict checks that your variables are
properly declared.
On security questions in general, you might like to look at Lincoln Stein’s well regarded “Secure CGI FAQ” at http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html.