-------------------------------------------------------------------------------

WWW Security FAQ
      http://www.w3.org/Security/Faq/

Specifically:
       Question 5  "Are CGI scripts insecure?"
   and Section 6   "CGI Scripts"


Also for those programming CGI scripts you should be using 'taint'
mode of perl as a minimum security precaution, and for database
security possibly 'Set-UID' Programming (See Unix Programming books)

This is covered in
       Section 7   "Safe Scripting in Perl"
  And you sould also look at
     Gunther Birznieks' CGI/Perl Taint Mode FAQ
        http://gunther.web66.com/FAQS/taintmode.html
  And finally
     Perl Security Manpage at
        http://www.perl.com/CPAN/doc/manual/html/pod/perlsec.html
     Or use the command  "man perlsec" on your unix system.

------
Q5: Are CGI scripts insecure?

CGI scripts are a major source of security holes. Although the CGI
(Common Gateway Interface) protocol is not inherently insecure, CGI
scripts must be written with just as much care as the server itself.
Unfortunately some scripts fall short of this standard and trusting Web
administrators install them at their sites without realizing the
problems.

-----
Q31: What's the problem with CGI scripts?

The problem with CGI scripts is that each one presents yet another
opportunity for exploitable bugs. CGI scripts should be written with the
same care and attention given to Internet servers themselves, because,
in fact, they are miniature servers. Unfortunately, for many Web
authors, CGI scripts are their first encounter with network programming.

CGI scripts can present security holes in a number of ways:

  1. They may intentionally or unintentionally leak information about
     the host system that will help hackers break in.
  2. Scripts that process remote user input, such as the contents of a
     form or a "searchable index" command, may be vulnerable to attacks in
     which the remote user tricks them into executing commands.
ADDITION...
  3. Scripts feed input to make them do things they were not meant to do.

CGI scripts are potential security holes even though you run your server
as "nobody". A subverted CGI script running as "nobody" still has enough
privileges to mail out the system password file, examine the network
information maps, or launch a log-in session on a high numbered port (it
just needs to execute a few commands in Perl to accomplish this). Even
if your server runs in a chroot directory, a buggy CGI script can leak
sufficient system information to compromise the host.

------
You should try to find ways not to open a shell. In the rare cases when
you have no choice, you should always scan the arguments for shell
meta-characters and remove them. The list of shell meta-characters is
extensive:

        &;`'\"|*?~^<>()[]{}$\n\r

It's a better policy to make sure that all user input arguments are
exactly what you expect rather than blindly remove shell meta-characters
and hope there aren't any unexpected side-effects.  Even if you avoid
the shell and pass user variables directly to a program, you can never
be sure that they don't contain constructions that reveal holes in the
programs you're calling.

Check Environment variables:-
    particularly reset the PATH, and or call command explicitly
          EG: Use  "/bin/ls"  instead of  just  "ls"
    Any other environment variables which could be used by a program

------
NOTE: CGI Scripts typically run as the user 'nobody' which is supposed to be
the user with the LEAST amount of privileges on the system, but even commands
run as 'nobody' or even as yourself can compromise your system security.

-------------------------------------------------------------------------------