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

CHAPTER 35
Server-Side Security Issues

by Greg Knauss and Melissa Niles

In this chapter

Scripts Versus Programs 938

CGI Security Issues: Recognizing Problems, Finding Solutions 938

Inside Attacks: Precautions with Local Users 954

Using Others’ CGI Scripts 958

Scripts Versus Programs

Shell scripts, Perl programs, and C executables are the most common forms that a CGI script takes, and each has advantages and disadvantages when security is taken into account. No single language is the best; depending on other considerations such as speed and reuse, each has a place.

•  Although shell CGI programs are often the easiest to write, it can be difficult to fully control them because they usually do most of their work by executing other, external programs. This can lead to several possible pitfalls because your CGI script instantly inherits any of the security problems that those called programs have. The common UNIX utility awk has some fairly restrictive limits on the amount of data it can handle, for instance, and your CGI program will be burdened with all those limits, as well.

•  Perl is a step up from shell scripts. It has many advantages for CGI programming and is fairly secure, in itself. But Perl can offer CGI authors just enough flexibility and peace of mind that they might be lulled into a false peace of mind. Perl is interpreted, for example, and this makes it easier for bad user data to be included as part of the code.

•  The third language option is C. Although C is popular for many uses, it is because of this popularity that many of its security problems are well known and can be exploited fairly easily. For instance, C is bad at string handling; it does no automatic allocation or clean up, leaving coders to handle everything on their own. Many C programmers, when dealing with strings, will set up a predefined space and hope that it will be big enough to handle whatever the user enters. Robert T. Morris, the author of the infamous Internet Worm, exploited such a weakness in attacking the C-based sendmail program, overflowing a buffer to alter the stack and gain unauthorized access. The same can happen to your CGI program.

CGI Security Issues: Recognizing Problems, Finding Solutions

Almost all CGI security holes come from interaction with the user. By accepting input from an outside source, a simple, predictable CGI program suddenly takes on any number of new dimensions, each of which might have the smallest crack through which a hacker can slip. It is interaction with the user—through forms or file paths—that gives CGI scripts their power but also make them the most potentially dangerous part of running a Web server.

---

CAUTION:  

Writing secure CGI scripts is largely an exercise in creativity and paranoia. You must be creative to think of all the ways that users, either innocently or otherwise, can send you data that has the potential to cause trouble. And you must be paranoid because, somehow, users will try every one of them.

---

Two Roads to Trouble

When users log on to your Web site and begin to interact with it, they can cause headaches in two ways. One is by not following the rules, by bending or breaking every limit or restriction you’ve tried to build into your pages; the other is by doing just what you’ve asked them to do.

•  Most CGI scripts act as the back end to HTML forms, processing the information entered by users to provide some sort of customized output. Therefore, most CGI scripts are written to expect data in a very specific format. They rely on input from the user matching the information that the form was designed to collect. This, however, isn’t always the case. A user can get around these predefined formats in many ways, sending your script seemingly random data. Your CGI programs must be prepared for it.

•  Secondly, users can send a CGI script exactly the type of data it expects, with each field in the form filled in, in the format you expect. This type of submission can be from an innocent user interacting with your site as you intended, or it can be from a malevolent hacker using his knowledge of your operating system and Web server software to take advantage of common CGI programming errors. These attacks, in which everything seems fine, are the most dangerous and the hardest to detect. The security of your Web site depends on preventing them.

Form Data: The Most Common Security Hole

Users are an unruly lot, and they’re likely to find the handful of ways to send data that you never expect—even ways that you think are impossible. All your scripts must take this into account. For instance, each of the following situations—and many more like them—are possible:

•  The selection from a group of radio buttons or <SELECT> element may not be one of the choices offered in the form. The options in the <SELECT NAME=”opinion”> element may be “yes” and “no”, for example, but the URL returned to the server may be http://www.yourdomain.com/cgi-bin/fileproc.cgi?option=maybe. The user may have edited the URL to include nearly any string.

•  The length of the data returned from a text field may be longer than what is allowed by the MAXLENGTH attribute. As in the previous example, the user may have edited the URL to include a string of nearly any length. If your form has a text field <INPUT NAME=”city” TYPE=”text” MAXLENGTH=”15">, for example, the URL returned to the server may be http://www.yourdomain.com/cgi-bin/yourprog.pl/city=El+Pueblo+de+Nuestra+Senora+la+Reina+de+los+Angeles+de+Porciuncula.

•  The names of the fields themselves may not match what you specified in the form. If your survey form has three named fields: q1, q2, and q3, for example, you may still get a URL returned to the server ending in ?you_are=hacked.

•  Using “hidden” fields in your form provides no assurances that someone cannot read that value within the input tag. Also, anyone viewing a form can view the source, and all form tags are displayed. They can simply edit the HTML and enter their own values.