CGI Programming with Perl

CGI Programming with Perl

4.0 4
by Scott Guelich, Shishir Gundavaram, Gunther Birznieks
     
 

View All Available Formats & Editions

A comprehensive explanation of CGI for people who hold on to the dream of providing their own information servers on the Web. This edition has been completely rewritten to use the current techniques available in Version 5 of Perl and two popular Perl modules, CGI.pm and CGI_lite, plus discussions of speed-up techniques such as FastCGI and mod_perl.See more details below

Overview

A comprehensive explanation of CGI for people who hold on to the dream of providing their own information servers on the Web. This edition has been completely rewritten to use the current techniques available in Version 5 of Perl and two popular Perl modules, CGI.pm and CGI_lite, plus discussions of speed-up techniques such as FastCGI and mod_perl.

Editorial Reviews

Booknews
Explains how to use the common gateway interface (CGI) to create and deliver dynamic content on the web. The second edition has been rewritten to demonstrate current techniques available with the CGI.pm module and the latest versions of Perl. Annotation c. Book News, Inc., Portland, OR (booknews.com)

Product Details

ISBN-13:
9781565924192
Publisher:
O'Reilly Media, Incorporated
Publication date:
07/06/2000
Edition description:
Second Edition
Pages:
472
Sales rank:
389,849
Product dimensions:
7.00(w) x 9.19(h) x 1.12(d)

Read an Excerpt

Chapter 8: Security

The Importance of Web Security

Many CGI developers do not take security as seriously as they should. So before we look at how to make CGI scripts more secure, let's look at why we should worry about security in the first place.

  1. On the Internet, your website represents your public image. If your web pages are unavailable or have been vandalized, that affects others'impressions of your organization, even if the focus of your organization has nothing to do with web technology.

  2. You may have valuable information on your web server. You may have sensitive or valuable information available in a restricted area that you may wish to keep unauthorized people from accessing. For example, you may have content or services available to paying members, which you would not want non-paying customers or non-members to access. Even files which are not part of your web server's document tree and are thus not available online to anyone, e.g., credit card numbers, could be compromised.

  3. Someone who has cracked your web server has easier access to the rest of your network. If you have no valuable information on your web server, you probably cannot say that about your entire network. If someone breaks into your web server, it becomes much easier for them to break into another system on your network, especially if your web server is inside your organization's firewall (which, for this reason, is generally a bad idea).

  4. You sacrifice potential income when your system is down. If your organization generates revenue directly from your website, you certainly lose income when your system is unavailable. However, even if you do not fall into this group, you likely offer marketing literature or contact information online. Potential customers who are unable to access this information may look elsewhere when making their decision.

  5. You waste time and resources fixing problems. You must perform many tasks when your systems are compromised. First you must determine the extent of the damage. Then you probably need to restore from backups. You must also determine what went wrong. If a cracker gained access to your web server, then you must determine how the cracker managed this in order to prevent future break ins. If a CGI script damaged files, then you must locate and fix the bug to prevent future problems.

  6. You expose yourself to liability. If you develop CGI scripts for other companies, and one of those CGI scripts is responsible for a large security problem, then you may understandably be liable. However, even if it is your company for whom you're developing CGI scripts, you may be liable to other parties. For example, if someone cracks your web server, they could use it as a base to stage attacks on other companies. Likewise, if your company stores information others consider sensitive (e.g. your customers'credit card numbers), you may be liable to them if that information is leaked.

These are only some of the many reasons why web security is so important. You may be able to come up with other reasons yourself. So now that you recognize the importance of creating secure CGI scripts, you may be wondering what makes a CGI script secure. It can be summed up in one simple maxim: never trust any data coming from the user. This sounds quite simple, but in practice it's not. In the remainder of this chapter, we'll explore how to do this.

Handling User Input

Security problems arise when you make assumptions about your data: you assume that users will do what you expect, and they surprise you. Users are good at this, even when they're not trying. To write secure CGI scripts, you must also think creatively. Let's look at an example.

Calling External Applications

figlet is a fun application that allows us to create large, fancy ASCII art characters in many different sizes and styles. You can find examples of figlet output as part of people's signatures in email messages and news group posts.

You can execute figlet from the command-line in the following manner:

% figlet -f fonts/slant 'I Love CGI!'

And the output would be...

...We can write a CGI gateway to figlet that allows a user to enter some text, executes a command like the one shown above, captures the output, and returns it to the browser.

First, here is the HTML form:

Example 8-1: figlet.html

Now, here's the program:

Example 8-2: figlet_INSECURE.cgi

#!/usr/bin/perl -w
 
use strict;
use CGI;
use CGIBook::Error;
 
# Constant: path to figlet
my $FIGLET = '/usr/local/bin/figlet';
 
my $q      = new CGI;
my $string = $q->param( "string" );
 
unless ( $string ) {
    error( $q, "Please enter some text to display." );
}
 
local *PIPE;
 
## This code is INSECURE...
## Do NOT use this code on a live web server!!
open PIPE, "$FIGLET \"$string\" |" or
    die "Cannot open pipe to figlet: $!";
 
print $q->header( "text/plain" );
print while ;
close PIPE;

We first verify that the user entered a string and simply print an error if not. Then we open a pipe (notice the trailing "|"character) to the figlet command, passing it the string. By opening a pipe to another application, we can read from it as though it is a file. In this case, we can get at the figlet output by simply reading from the PIPE file handle.

We then print our content type, followed by the figlet output. Perl lets us do this on one line: the while loop reads a line from PIPE, stores it in $_, and calls print; when print is called without an argument, it will output the value stored in $_; the loop automatically terminates when all the data has been read from figlet.

Admittedly, our example is somewhat dull. figlet has many options for changing the font, etc., but we want to keep our example short and simple to be able to focus on the security issues. Many people assume that for scripts this simple, it's hard for something to go wrong with them. In fact, this CGI script allows a savvy user to execute any command on your system...

Read More

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >