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

But imagine if, rather than entering only a name, the user types <HR><H1><P ALIGN=”CENTER”>Jane Smith</P></H1><HR>. The result would be Figure 35.4—probably not what you wanted.

Or imagine if a hacker entered

<IMG SRC=”/secret/project/funnyface.jpg”>

FIGURE 35.3  When the user enters what you requested, everything works well.

FIGURE 35.4  Entering HTML when a script expects plain text can change a page in unexpected ways.

when you requested the user’s name. Again, if the code from the preceding snippet were part of a CGI script with this HTML in the $user_Name variable, your Web server would happily show the hacker your secret adorable toddler picture! Figure 35.5 is an example.

FIGURE 35.5  Allowing HTML to be entered can be dangerous. Here a secret file is shown instead of the user’s name.

Or what if The last signee!<FORM><SELECT> was entered as the user’s name in a guest book? The <SELECT> tag would cause the Web browser to ignore everything between it and a nonexistent </SELECT>, including any names that were added to the list later. Even though 10 people signed the guest book shown in Figure 35.6, only the first three appear because the third name contains a <FORM> and a <SELECT> tag.

FIGURE 35.6  Because the third signee used HTML tags in his name, nobody listed after him will show up.

But even more dangerous than entering simple HTML, a malicious hacker might enter a server-side include directive instead. If your Web server is configured to obey server-side includes, a user might type <!-- #include file=”/secret/project/plan.txt” --> instead of his name to see the complete text of your secret plans. Or he can enter <!---- #include file=”/etc/passwd” ----> to get your machine’s password file. And probably worst of all, a hacker might input <!---- #exec cmd=”rm –rf /” ---->, and the innocent code in the snippet shown before would proceed to delete almost everything on your hard disk. This is a primary example of why Web servers should not run as root (the Super User). Running the Web server under a non-privileged user is the best way to reduce problems in case someone does find a hole in your script.

• See “Common SSI Commands,” p. 806.

---

CAUTION:  

Server-side includes are often disabled because of how they can be misused. Although much more information is available in Chapter 32, “Server-Side Includes,” you might want to consider this option to truly secure your site against this type of attack.

---

Two solutions exist to the problem of the user entering HTML rather than flat text:

•  The quick-and-dirty solution is to disallow the less than (<) and greater than (>) symbols. Because all HTML tags must be contained within these two characters, removing them (or returning an error if you encounter them) is an easy way to prevent HTML from being submitted and accidentally returned. The following line of Perl code simply erases the characters:

$user_Input =~ s/<>//g;

•  The more elaborate solution is to translate the two characters into their HTML escape codes. The following code does this by globally substituting &lt; for the less than symbol and &gt; for the greater than symbol:

$user_Input =~ s/</&lt;/g;
$user_Input =~ s/>/&gt;/g;

Handling External Processes

Another area where you must be careful is how your CGI script interfaces user input with any external processes. Because executing a program outside of your CGI script means that you have no control over what it does, you must do everything you can to validate the input you send to it before the execution begins.

For instance, shell scripts often make the mistake of concatenating a command-line program with form input and then executing them together. This works fine if the user has entered what you expected, but additional commands may be sneaked in and unintentionally executed.

The following fragment of shell script commits this error:

FINGER_OUTPUT=‘finger $USER_INPUT‘
echo $FINGER_OUTPUT

If the user politely enters the email address of a person to finger, everything works as it should. But if he enters an email address followed by a semicolon and another command, that command will be executed as well. If the user enters webmaster@www.yourserver.com;rm -rf /, you’re in considerable trouble.

---

CAUTION:  

You also must be careful to screen all the input you receive—not just form data—before using it in the shell. Web server environment variables can be set to anything by a hacker who has written his own Web client and can cause just as much damage as bad form data.

If you execute the following line of shell script, thinking that it will simply add the referrer to your log, you might be in trouble if HTTP_REFERER has been set to ;rm -rf /;echo “Ha ha”.

echo $HTTP_REFERER >> ./referer.log

---

Even if a hidden command isn’t placed into user data, innocent input may give you something you don’t expect. The following line, for instance, will give an unexpected result—a listing of all the files in the directory—if the user input is an asterisk:

echo “Your input: “ $USER_INPUT

When sending user data through the shell, as both of these code snippets do, it’s a good idea to screen it for shell meta-characters. Such characters include the semicolon (which allows multiple commands on one line), the asterisk and the question mark (which perform file globbing), the exclamation point (which, under csh, references running jobs), the back quote (which executes an enclosed command), and so on. Like filtering filenames, maintaining a list of allowable characters is often easier than trying to catch each character that should be disallowed. The following Perl fragment crudely validates an email address:

if ($email_Address ~= /[^a-zA-Z0-9_\-\+\@\.])
{
      # Illegal character!
}
else
{
      system(“finger $email_Address”);
}