Chapter 16. Securing Web Applications

Tip

To protect yourself from programs, scripts, and CGIs in which security faults may be later discovered, you may wish to move all of the programs that are installed by default with your web sever into a directory where they cannot be accessed, and only restore the programs when they are specifically needed.

Unintended Side Effects

To understand the potential problems with server-side programming, consider the CGI script in Example 16-1.^[168]

Example 16-1. A CGI script with a problem

#!/usr/local/bin/perl
#
# bad_finger
#

sub ReadForm {
  my (*in) = @_ if @_;
  my ($i, $key, $val, $input);

  # Read in text if we were called in a query
  @in = split(/[&;]/,$input);

  for($i = 0; $i<scalar(@in); $i++){
    $in[$i] =~ s/\+/ /g;                # plus to space
    ($key, $val) = split(/=/,$in[$i],2);# get key and value

    # Convert %XX from hex numbers to alphanumeric
    $key =~ s/%(..)/pack("c",hex($1))/ge;
    $val =~ s/%(..)/pack("c",hex($1))/ge;

    # Add to array
    $in{$key} .= "\0" if (defined($in{$key})); # \0 is the mult. separator
    $in{$key} .= $val;

  }
  return length($in);
}
###########################################################################
#
# The real action (and the security problems) follow

print "Content-type: text/html\n\n<html>";

if(&ReadForm(*input)){
    print "<pre>\n";
    print `/usr/bin/finger $input{'command'}`;
    print "</pre>\n";
}

print <<XX;
<hr>
<form method="post" action="bad_finger">
Finger command: <input type="text" size="40" name="command">
</form>
XX

The first half of this script defines a Perl function, ReadForm, which will be used throughout this chapter for CGI form handling. There are no problems with this function—all it does is take input from a CGI GET or POST operation and stuff the variables into an associative array provided by the programmer.

The second half of this script defines a finger gateway. If called by the result of a normal HTTP GET command, it simply generates the HTML for a CGI form:

Content-type: text/html

<html><hr>
<form method="post" action="bad_finger">
Finger command: <input type="text" size="40" name="command">
</form>

This produces the expected display in a web browser, as shown in Figure 16-1.

Figure 16-1. The finger gateway

Type a typical user ID such as spaf@cs.purdue.edu, into the field, hit Return, and you’ll get the expected result (see Figure 16-2).

Figure 16-2. The form displayed by the finger script

Despite the fact that this script works as expected, it has a serious problem: an attacker can use this script to seriously compromise the security of your computer.

You might have security problems similar to this one in the CGI scripts on your server. Security problems in scripts can remain dormant for years before they are exploited.

Sometimes, obscure security holes may even be inserted by the programmer who first wrote the scripts—a sort of “back door” that allows the programmer to gain access in the future, should the programmer’s legitimate means of access be lost. These back doors can be much harder to find than a simple undocumented account or password. We discuss this problem in the next section.

The problem with the script

The problem with the script shown previously is the single line that executes the finger command:

print `/usr/bin/finger $input{'command'}`;

This line executes the program /usr/bin/finger with the input provided and displays the result. The problem with this line is the way in which the finger command is invoked—from Perl’s backquote function. The backquote function provides its input to the Unix shell—and the Unix shell may interpret some of that input in an unwanted manner!

Thus, when we sent the value spaf@cs.purdue.edu to this CGI script, it ran the Unix command:

print `/usr/bin/finger spaf@cs.purdue.edu`;

and that evaluated to:

/usr/bin/finger spaf@cs.purdue.edu

and that then produced the expected result.

The Unix shell is known and admired for its power and flexibility by programmers and malicious hackers alike. One of the interesting abilities of the Unix shell is the ability to put multiple commands on a single line. For example, if we wanted to run the finger command in the background and, while we are waiting, do an ls command on the current directory, we might execute this command:

/usr/bin/finger spaf@cs.purdue.edu & /bin/ls -l

And indeed, if we type in the name spaf@cs.purdue.edu & /bin/ls -l as our finger request (see Figure 16-3), the bad_finger script will happily execute it, which produces the output (see Figure 16-4).

Figure 16-3. Attacking the bad_finger script

Figure 16-4. Output from the bad_finger script under attack

What’s the harm in allowing a user to list the files? By looking at the files, an attacker might learn about other confidential information stored on the web server. Also, the /bin/ls command is simply one of many commands that the attacker might run. The attacker could easily run commands to delete files, send an “xterm” back to his own computer, initiate denial-of-service attacks to other computers, or even crash your machine.

Although most operating systems are not fundamentally unsecure, few operational computers are administered in such a way that they can withstand an inside attack from a determined attacker. Thus, you must ensure that attackers never get inside your system: deny the attacker the ability to run arbitrary commands. To prevent an attacker from gaining this foothold, you must be sure that your server’s scripts and programs cannot be turned against you.

Fixing the problem

Fixing the problem with the bad_finger script is remarkably easy. All you need to do is not trust the user’s input. Instead of merely sending $input{'command'} to a shell, you should filter the input, extracting legal characters for the command that you wish to execute.

In the case of finger, there is a very small set of characters that are valid in email addresses or hostnames. The next script selects those characters with a regular expression pattern match:

if(&ReadForm(*input)){
    $input{'command'} =~ m/([\w+@\.\-]*)/i;        # Match alphanumerics, @ and -
    print "<pre>\n";
    print `/usr/bin/finger $1`;
    print "<pre>\n";
}

This command works as before, except that now it won’t pass on characters such as “&”, “;”, or " ' " to the subshell.

Notice that this example matches legal characters, rather than filters out disallowed ones. This is an important distinction! Many publications recommend filtering out special characters—and then they don’t tell you all of the characters that you need to remove. Indeed, it’s sometimes difficult to know, because the list of characters to remove depends on how you employ the user input as well as which shells and programs are invoked. For example, if you write a script that accepts a number or a date, you might wish to allow the characters “.” and “/”. If you are writing a script that accepts a filename, you may wish to filter out these characters to prevent an attacker from specifying a pathname that is in a different directory—for example, .. /.. /.. /.. /.. /etc /passwd. This is why best practice recommends selecting which characters to let through, rather than guessing which characters should be filtered out.^[169]

The script can be made more secure (and somewhat faster) by using Perl’s system function to run the finger command directly. This entirely avoids calling the shell:

if(&ReadForm(*input)){
    $input{'command'} =~ m/([\w+@\-]*)/i;        # Match alphanumerics, @ and -
    print "<pre>\n";
    system '/usr/bin/finger', $1;
    print "<pre>\n";
}

The next section gives many rules of thumb to help you avoid these kinds of problems in your CGI and API programs.

^[167] In a multiuser environment, such as a web server at an ISP or a university, it is common practice to use the cgiwrap script so that CGI programs are run with the subscriber’s permissions, rather than with the web server’s.

^[168]The ReadForm functions are based on Steven E. Brenner’s cgi-lib.pl. It is used here so that the reader can see the entire program. The serious Perl programmer should use the CGI.pm Perl module, which is available from the CPAN archives.

^[169]Another reason that you should select the characters that are matched rather than choose which characters to filter out is that different programs called by your script may treat 8-bit and multibyte characters in different ways. You may not filter out the 8-bit or multibyte versions of a special character, but when they reach the underlying system they may be interpreted as single-byte, 7-bit characters—much to your dismay.