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

If you decide that you must allow shell meta-characters in your input, ways exist to make their inclusion safer—and other ways don’t actually accomplish anything. Although you may be tempted to put quotation marks around user input that hasn’t been validated to prevent the shell from acting on special characters, this almost never works. Look at the following:

echo “Finger information:<HR><PRE>”
finger “$USER_INPUT”
echo “</PRE>”

Although the quotation marks around $USER_INPUT will prevent the shell from interpreting, for example, an included semicolon that would enable a hacker to piggyback a command, this script still has several severe security holes. For instance, the input might be ‘rm -rf /‘, with the back quotes causing the hacker’s command to be executed before finger is even considered.

A better way to handle special characters is to escape them so that the shell takes their values without interpreting them. By escaping the user input, all shell meta-characters are ignored and treated instead as just more data to be passed to the program.

The following line of Perl code does this for all nonalphanumeric characters:

$user_Input =~ s/([^w])/\\\1/g;

Now, if this user input were appended to a command, each character—even the special characters—would be passed through the shell to finger.

In general, validating user input—not trusting anything sent to you—will make your code easier to read and safer to execute. Rather than trying to defeat a hacker after you’re already running commands, give data the once-over at the door.

---

Handling Internal Functions

With interpreted languages, such as a shell or Perl, the user can enter data that will actually change your program—data that cause errors that aren’t present if the data is correct. If user data is interpreted as part of the program’s execution, anything he enters must adhere to the rules of the language or cause an error.

For instance, the following Perl fragment may work fine or may generate an error, depending on what the user enters:

if ($search_Text =~ /$user_Pattern/)
{
      # Match!
}

In Perl, the eval() operator exists to prevent this. eval() allows for run-time syntax checking and will determine whether an expression is valid Perl. The following code is an improved version of the preceding code:

if (eval{$search_Text =~ /$user_Pattern/})
{
      if ($search_Text =~ /$user_Pattern/)
      {
            # Match!
      }
}

Unfortunately, most shells (including the most popular, /bin/sh) have no easy way to detect errors such as this one, which is another reason to avoid them.

---

Guarding Against Loopholes when Executing External Programs

When executing external programs, you must also be aware of how the user input you pass to those programs will affect them. You may guard your own CGI script against hacker tricks, but it’s all for naught if you blithely pass anything a hacker may have entered to external programs without understanding how those programs use that data.

Many CGI scripts will send email to a particular person, for instance, containing data collected from the user by executing the mail program.

This can be dangerous because mail has many internal commands, any of which can be invoked by user input. If you send text entered by the user to mail, for example, and that text has a line that starts with a tilde (~), mail will interpret the next character on the line as one of the many commands it can perform. ~r /etc/passwd, for example, will cause your machine’s password file to be read by mail and sent off to whomever the letter is addressed to, perhaps even the hacker.

In an example such as this one, rather than using mail to send email from UNIX machines, you should use sendmail, the lower-level mail program that lacks many of mail’s features. But, of course, you should also be aware of sendmail’s commands so those can’t be exploited.

As a general rule, when executing external programs, you should use the one that fits your needs as closely as possible, without any frills. The less an external program can do, the less it can be tricked into doing.

---

CAUTION:  

Another problem occurs with mail and sendmail: You must be careful that the address you pass to the mail system is a legal email address. Many mail systems will treat an email address starting with a pipe (|) as a command to be executed, opening a huge security hole for any hacker who enters such an address.

Again, always validate your data!

---

Another example that demonstrates you must know your external programs well to use them effectively is grep. Most people will tell you that you can’t get into much trouble with grep. However, grep can be fooled fairly easily, and how it fails is illustrative. The following code is an example: It’s supposed to perform a case-sensitive search for a user-supplied term among many files:

print(“The following lines contain your term:<HR><PRE>”);
$search_Term =~ s/([^\w])/\\$1/g;
system(“grep $search_Term /public/files/*.txt”);
print(“</PRE>”);

This all seems fine, unless you consider what happens if the user enters -i. It’s not searched for, but functions as a switch to grep, as would any input starting with a dash. This will cause grep either to hang while waiting for the search term to be typed into standard input, or to error out when anything after the -i is interpreted as extra switch characters. This, undoubtedly, isn’t what you wanted or planned. In this case, it’s not dangerous, but in other cases it might be.

A harmless command doesn’t exist, and each must be carefully considered from every angle. You should be as familiar as possible with every external program your CGI script executes. The more you know about the programs, the more you can do to protect them from bad data, both by screening that data and by disabling options or disallowing features.