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

Although it’s nice to try to catch the users’ mistakes, don’t try to do too much. If your corrections aren’t really what users wanted, they’ll be annoyed.

---

CAUTION:  

You should also be aware that trying to catch every possible user-entry error will make your code huge and nearly impossible to maintain. Don’t over-engineer.

---

•  Finally, you might choose to go the extra mile and have your CGI script handle as many different forms of input as it can. Although you can’t possibly anticipate everything that can be sent to a CGI program, often several common ways exist to do a particular thing, and you can check for each.

Just because the form you wrote uses the POST method to submit data to your CGI script, for example, that doesn’t mean that the data will come in that way. Rather than assuming that the data will be on standard in (stdin) where you’re expecting it, you can check the REQUEST_METHOD environment variable to determine whether the GET or POST method was used and read the data accordingly. A truly well-written CGI script will accept data no matter what method was used to submit it and will be made more secure in the process. Listing 35.1 shows an example in Perl.

	TROUBLESHOOTING
	If your script returns an error, there are five usual causes. The first is that your script is not returning the proper Content-type. The second may be that your server is not properly set up to handle CGI scripts. The third is that the script named in the form’s ACTION attribute is not in your CGI-enabled directory, usually called cgi-bin. The fourth is that the path given in the form’s ACTION attribute is misspelled, or the filename is misspelled. Check the spelling of the filename and path. The fifth cause is that the filename and path are correct, but the filename does not end in the proper extension (such as .cgi or .plx or .pl) for your server configuration.
	Although you will usually get this error when the form is METHOD=”POST”, a user can cause this error to occur in a form with METHOD=”GET” by editing your page in his browser and substituting “POST” for “GET”.

Listing 35.1 Cgi_read.pl—A Robust Reading Form Input

# Takes the maximum length allowed as a parameter
# Returns 1 and the raw form data, or “0” and the error text
sub cgi_Read
{
      local($input_Max) = 1024 unless $input_Max = $_[0];
      local($input_Method) = $ENV{‘REQUEST_METHOD’};

      # Check for each possible REQUEST_METHODs
      if ($input_Method eq “GET”)
      {
            # “GET”
            local($input_Size) = length($ENV{‘QUERY_STRING’});

            # Check the size of the input
            return (0, “Input too big”) if ($input_Size > $input_Max);

            # Read the input from QUERY_STRING
            return (1,$ENV{‘QUERY_STRING’});
      }
      elsif ($input_Method eq “POST”)
      {
            # “POST”
            local($input_Size) = $ENV{‘CONTENT_LENGTH’};
            local($input_Data);

            # Check the size of the input
            return (0,”Input too big”) if ($input_Size > $input_Max);

            # Read the input from stdin
            return (0,”Could not read STDIN”) unless
(read(STDIN,$input_Data,$input_Size));

            return (1,$input_Data);
      }

      # Unrecognized METHOD
      return (0,”METHOD not GET or POST”);
}

Many existing CGI programming libraries already offer good built-in security features. Rather than write your own routines, you may want to rely on some of the well-known, publicly available functions.

Don’t Trust Path Data

Another type of data the user can alter is the PATH_INFO server environment variable. This variable is filled with any path information that follows the script’s filename in a CGI URL. For instance, if sample.sh is a CGI shell script, the URL http://www.yourserver.com/cgi-bin/sample.sh/extra/path/info will cause /extra/path/info to be placed in the PATH_INFO environment variable when sample.sh is run.

If you use this PATH_INFO environment variable, you must be careful to completely validate its contents. Just as form data can be altered in any number of ways, so can PATH_INFO—accidentally or on purpose. A CGI script that blindly acts on the path file specified in PATH_INFO can enable malicious users to wreak havoc on the server.

If a CGI script is designed to print out the file that’s referenced in PATH_INFO, for instance, a user who edits the CGI URL can read almost any file on your computer, as in the following script:

#!/bin/sh

# Send the header
echo “Content-type: text/html”
echo “”

# Wrap the file in some HTML
echo “<html><header><title>File</title></header><body>”
echo “Here is the file you requested:<pre>\n”
cat $PATH_INFO
echo “</pre></body></html>”

Although this script works fine if the user is content to click only predefined links—for example, http://www.yourserver.com/cgi-bin/showfile.sh/public/faq.txt—a more creative (or spiteful) user could use it to receive any file on your server. If she were to jump to
http://www.yourserver.com/cgi-bin/showfile.sh/etc/passwd, the preceding script would happily return your machine’s password file, something you do not want to happen.