ch9.htm

CGI programming is the hottest stuff to look out for in this book

<TR><TD>
<BLOCKQUOTE>
Do not run the Web server with super-user privileges. If a malicious intruder finds a security vulnerability in the Web server software, that intruder will immediately have full control of the server. Avoid CGI wrapper software that gives CGI programs the 
same privileges as the author of the CGI script. Such a wrapper merely lends extra power to the intruder who exploits any CGI security vulnerabilities. If a CGI gateway cannot access information as an untrusted user, this should prompt the implementor to 
reassess the availability of the information, not the privileges of the CGI gateway.</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<H4>Run CGI on a &quot;Sacrificial&quot; Machine, Outside any
Firewall</H4>
<P>
Choose a machine to be the CGI server that does not hold any secure
information and that is not generally trusted by other network
hosts. This need not even be your main Web server; setting aside
a machine exclusively as a CGI server simplifies the security
problem. If your organization uses a firewall gateway or router,
position your CGI server outside this firewall to limit the advantages
of an intruder who succeeds in exploiting a CGI security hole.
Do not host the CGI scripts on the firewall gateway itself, because
a security infiltration could compromise the whole organization.
<H4>Run CGI with Low Scheduling Priority</H4>
<P>
If possible, set the priority of CGI programs lower than other
processes in a multiprocessing environment. This will limit the
damage caused by malicious or accidental floods of CGI requests
that might otherwise have disabled the CGI server.
<H4>Regularly Read Security Mailing Lists and Usenet Newsgroups
</H4>
<P>
Security vulnerabilities and improved versions of server software
are often announced and discussed in the Internet discussion groups.
Information from software suppliers and other users can be invaluable.
<H3><A NAME="WhatCanaCGIProgrammerDotoImprove">What Can a CGI
Programmer Do to Improve Security?</A></H3>
<P>
The author of a CGI gateway program can also do much to defend
against security breaches, as outlined in the following sections.
<H4>Work with the Server Administrators</H4>
<P>
The programmer should discuss with Web server system administrators
all CGI-based implementations and security risks. Together they
can establish codes of practice that reduce the risk from attacks.
They could also implement a process of peer review through which
programmers review each other's code for possible security vulnerabilities.
<H4>Use Well-Respected Library Software</H4>
<P>
When choosing CGI toolkits and library software, examine and test
them for possible security vulnerabilities. Read the release notes
for the software and regularly check the Web &quot;home page&quot;
for the library software for information about security problems
and new versions. Where possible, use the most recent stable version
of the software. Don't be tempted to implement &quot;beta-release&quot;
software by the promise of new features. Security vulnerabilities
are often found in &quot;beta&quot; software-vulnerabilities that
are fixed in the production release. Subscribe to any Web-related
related mailing lists and security bulletin boards where CGI security
problems are discussed.
<H4>Restrict Access by Client Hostname</H4>
<P>
If the intended audience for your application uses a specific
set of machines, perhaps within one organization, it may be possible
to restrict access to your CGI gateway to allow connections from
only those machines. This can be achieved either through the scoping
features of certain Web servers, or by checking the <TT><FONT FACE="Courier">REMOTE_HOST</FONT></TT>
environment variable.
<H4>Restrict Access by Using HTTP Passwords</H4>
<P>
If you have a small number of known users for your application
and the Web server you are working with has support for HTTP password
authentication, you might choose to implement a username and password
scheme to restrict access to the CGI gateway to the trusted set
of users. This is not a substitute for careful coding, but it
allows the programmer to put less emphasis on defending against
malicious attacks or unauthorized use.
<H4>Be Paranoid</H4>
<P>
If you are writing software for any public network service, it
is safest to believe that they <I>are</I> out to get you. Even
if you consider the data you are handling to be public and your
organization to be unattractive to crackers, remember that there
are groups of people on the Internet who derive all their self-actualization
from finding the security holes in your software, gaining unauthorized
access to your computers and disrupting your network service,
wasting the time and effort of you and your colleagues. Program
defensively.
<H4>Make No Assumptions</H4>
<P>
It is dangerous to make assumptions about the data that will be
presented to a CGI program by the Web server.
<P>
Beware of assuming that the data is a submission from your form.
Anyone can point a Web form at your CGI gateway, or generate an
HTTP request that looks like a form submission but contains unsafe
data.
<P>
The example of an attempt to use Listing 9.1 (formmail.cgi) to
crack system security would probably be made from a raw, interactive
HTTP connection opened by the cracker. It supplies an unexpected
value to a form field that the form designer probably intended
to be hidden from the Web user.
<P>
Beware of assuming that the data submitted is small enough to
fit where you want it to fit. Whatever limitations you include
in a Web form, a faulty Web browser or a wily cracker will easily
get around them and attempt to crash or abuse your system by sending
more data than you expected.
<P>
Beware of assuming that special characters in the data have been
encapsulated by the browser using the <TT><FONT FACE="Courier">%hh</FONT></TT>
hexadecimal escape sequence. Browsers may not implement this convention,
and crackers may easily circumvent it.
<H4>Choose What Input to Accept, Not What to Reject</H4>
<P>
Many discussions of CGI security attempt to address the problem
of characters in the query or submission that have special meanings.
<P>
Command interpreters and other simple interpreted languages are
the most common victims. Characters like backquote (&quot;`&quot;),
backslash (&quot;\&quot;), and dollar (&quot;$&quot;) are interpreted
as part of the interpreted language and can be exploited to trick
the CGI gateway into running commands for a cracker on the Web
server.
<P>
Other tools and even the operating system itself can be abused.
Some useful applications will execute arbitrary commands if given
the wrong input. ASCII control characters (those with decimal
codes less than 32) can be used to disrupt text files where user
supplied form or query data is logged.
<P>
Unfortunately, the most common defense is to try to compile a
list of special characters and to guard against or exclude only
those characters. This piecemeal approach is risky at best. The
lists, like politician's speeches, are more interesting for what
they omit than for what they include and are typically stripped
from queries or form submissions as they have special meanings
to command interpreters. Recently, several Web servers had to
be rewritten to also defend against the inclusion of the &quot;end-of-line&quot;
characters in search queries as these are considered special by
many operating system operations.
<P>
A more satisfactory defense is to reduce the submitted input to
a small set of acceptable characters. This set of characters will
vary from application to application. For instance, a person's
name could be restricted to upper- and lowercase letters (including
the accented letters in the upper-half of the ISO-Latin-1 character
set), spaces, hyphens, and apostrophes. With this analysis, the
programmer will immediately discover that it is not possible to
pass a person's name to a command interpreter wrapped in single
quote characters because the single quote character (or apostrophe)
can reasonably form part of someone's name.
<P>
The key technique is to choose a set of characters to accept,
not to choose a set of characters to reject. The choice of acceptable
input characters will be influenced by the intended use. If the
input is to be passed as part of a command to the operating system
command interpreter (as in Listing 9.1), programmers must find
out whether any of the characters they would like their CGI program
to accept have a special meaning to the operating system or to
the other command.
<H4>Program Defensively</H4>
<P>
Choose criteria by which you can validate the query or form submission.
For instance, if the user has been asked to supply an Internet
e-mail address, reject a submission that does not conform to the
relevant Internet standards. You may even choose to validate the
supplied e-mail address by sending a secret password to the address
and insisting on the password for future submissions. Be prepared
to have your program handle garbage input, empty input, random
input, prank submissions, and malicious attacks.
<P>
Choose limitations on the size and structure of acceptable input.
It is easy to assume that a prompt for a name will yield a response
small enough to fit into the available memory of the Web server,
but there is no reason why it should. A malicious attacker could
send several megabytes of binary data where you expected a personal
name. Careless handling of a &quot;denial of service&quot; attack
like this could lead to Web server downtime or even software damage.
If you requested a single line of text, reject submissions containing
end-of-line characters. If a Web form includes selection lists
or checkboxes, reject any data submitted that is not formed from
the options presented to the user.
<H4>Never Allow User Data to Be Reinterpreted</H4>
<P>
The data supplied by a user in a form submission or query should
be treated as &quot;contaminated&quot; until it has been cleaned
of potentially dangerous special characters.
<P>
The example program in Listing 9.1 passed data submitted from
a form unchecked to the operating system command interpreter and
to an e-mail application. A cracker suspecting this could have
easily included quote characters in the form submission that could
direct the command interpreter to run any command the cracker
chose. The cracker might equally have chosen to exploit the e-mail
application that might be similarly persuaded to run commands
with the use of an escape character or exclamation mark.
<P>
The program might have been more safely written in the manner
shown in Listing 9.2.
<HR>
<BLOCKQUOTE>
<B>Listing 9.2. A more secure HTML form handler.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">#!/usr/local/bin/perl<BR>
# formfile.cgi<BR>
# Accepts form submission and logs to a file for later use<BR>
<BR>
# Call library routine to translate and split form submission
<BR>
# into perl variables $input{&quot;field&quot;}<BR>
# the library routine limits the size and content of the input
<BR>
# to a length and to characters considered safe<BR>
require &quot;safecgi.pl&quot;;<BR>
<BR>
# Open the log file for &quot;append&quot;. Do not pass the form
contents to any operating &Acirc;system routine<BR>
open (FILE, &quot;&gt;&gt;/home/webweaver/form.log&quot;);<BR>
<BR>
# Write some key headers for this message<BR>
<BR>
print FILE &quot;Script:&quot;.$ENV{&quot;SCRIPT_NAME&quot;}.&quot;\n&quot;;
<BR>
print FILE &quot;Host: &quot;.$ENV{&quot;REMOTE_HOST&quot;}.&quot;(&quot;.$ENV{&quot;REMOTE_ADDR&quot;}.&quot;)\n&quot;;
<BR>
print FILE &quot;Date: &quot;.`/bin/date`;<BR>
<BR>
# And write the form data into the file<BR>
print FILE $input{&quot;formcontents&quot;}.&quot;\n&quot;;<BR>
<BR>
close(FILE);<BR>
exit(0);</FONT></TT>
</BLOCKQUOTE>
<HR>
<P>
In the program in Listing 9.2, no user data is passed to be reinterpreted
by an operating system command or any other program. It is simply
written to a file for examination by a &quot;safe&quot; file browser
later. The user data never contaminates any operating system command
or operation.
<P>
CGI programming languages that permit the reinterpretation of
variables as program code, such as scripting languages and command
interpreters with an <TT><FONT FACE="Courier">eval</FONT></TT>
function, pose the extra problem of user data potentially contaminating
the CGI program itself. Care should be taken to avoid passing
unchecked user data to any interpreter, explicitly or implicitly.
<P>
Some programming languages include features to make the tracking
of unchecked or &quot;contaminated&quot; data easier. For instance,
the Perl scripting language supports &quot;taint&quot; checking,
which helps to identify unchecked data before the program is used.
Nevertheless, for most applications, the programmer should attempt
to design a clear demarcation between unchecked and validated
user data. This might be a variable naming scheme, perhaps where
the unchecked data is kept in variables whose names begin with
the word &quot;raw&quot; and are transferred upon validation and
safety checking to variables beginning with the word &quot;cooked.&quot;
Alternatively, it might be a logical demarcation in the program's
structure where the raw data is available only in the routines
that accept the user input and is passed to the rest of the program
after rigorous checking.
<H4>Check Array Bounds Aggressively</H4>
<P>
Many interpreted programming languages have inherent limitations
in the size of some variable data types. It is also difficult
to handle data of an arbitrary size in many compiled languages.
For some tools and applications, the programmer will accept the
risk of choosing a maximum reasonable size for user-supplied data
and might not even check that the user-supplied data is small
enough to fit in the storage space set aside for it.
<P>
When the application is being made available to anyone and everyone
on the Internet, array bounds checking cannot be ignored. It is
important that the CGI programmer chooses reasonable limits for