Section 8.4. Runtime: Securing CGI Scripts

We've secured what we can at build time. Now we enter a maze of twisty little passages, seeking security at runtime.

8.4.1 HTTP, URLs, and CGI

Just as a little SMTP knowledge aids understanding of email-security issues, a little background on HTTP and URLs improves knowledge of web security.

Every exchange between a web client and server is defined by the Hypertext Transfer Protocol (HTTP). HTTP 1.0 was the first widely used version, but it had some shortcomings. Most of these were addressed with HTTP 1.1, the current version that is almost universal. HTTP 1.1 is defined in RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616.html). The web client makes HTTP requests, and the web server responds. Web browsers hide much of the data exchange, such as MIME types, cache settings, content negotiation, timestamps, and other details. Other clients (such as a web spider, wget, or curl) offer much more control over the exchange.

An HTTP request contains an initial request line:

Method URI HTTP-Version \r\n

Methods include OPTIONS, GET, HEAD, POST, PUT, TRACE, DELETE, and CONNECT. Some methods have a corresponding URL format.

This line may be followed by request header lines containing information about the client, the host, authorization, and other things. These lines may be followed by a message body. The web server returns a header and an optional body, depending on the request.

There are security implications with the type of URLs you use. Since the protocol is text, it's easy to forge headers and bodies (although attackers have successfully forged binary data for years). You can't trust what you're being told, whether you're a web server or a client. See section 15 of RFC 2616 for other warnings.

The following are the most common methods and some security implications.

8.4.1.1 HEAD method

Do you want to know what web server someone is running? It's easy. Let's look at the HEAD data for the home page at http://www.apache.org:

$ telnet www.apache.org 80

Trying 63.251.56.142...

Connected to daedalus.apache.org (63.251.56.142).

Escape character is '^]'.

HEAD / HTTP/1.1

Host: www.apache.org

 

HTTP/1.1 200 OK

Date: Sat, 13 Apr 2002 03:48:58 GMT

Server: Apache/2.0.35 (Unix)

Cache-Control: max-age=86400

Expires: Sun, 14 Apr 2002 03:48:58 GMT

Accept-Ranges: bytes

Content-Length: 7790

Content-Type: text/html



Connection closed by foreign host.

$

(A handy alternative to this manual approach is the curl client, available from http://www.haxx.se.) The actual responses vary by web server and site. Some don't return a Server: response header, or say they're something else, to protect against attacks aided by port 80 fingerprinting. The default value returned by Apache includes the identity of many modules. To return only a Server: Apache response, specify:

ServerTokens ProductOnly

8.4.1.2 OPTIONS method

If OPTIONS is supported, it tells us more about the web server:

$ telnet www.apache.org 80

Trying 63.251.56.142...

Connected to daedalus.apache.org (63.251.56.142).

Escape character is '^]'.

OPTIONS * HTTP/1.1

Host: www.apache.org

 

HTTP/1.1 200 OK

Date: Sat, 13 Apr 2002 03:57:10 GMT

Server: Apache/2.0.35 (Unix)

Cache-Control: max-age=86400

Expires: Sun, 14 Apr 2002 03:57:10 GMT

Allow: GET,HEAD,POST,OPTIONS,TRACE

Content-Length: 0

Content-Type: text/plain

Connection closed by foreign host.

$

The OPTIONS method is not a security concern, but you might like to try it on your own servers to see what it returns.

8.4.1.3 GET method

GET is the standard method for retrieving data from a web server. A URL for the GET method may be simple, like this call for a home page:

http://www.hackenbush.com/

A GET URL may be extended with a ? and name=value arguments. Each instance of name and value is URL encoded, and pairs are separated by an &:

http://www.hackenbush.com/cgi-bin/groucho.pl?day=jan%2006&user=zeppo

An HTTP GET request contains a header but no body. Apache handles the request directly, assigning everything after the ? to the QUERY_STRING environment variable. Since all the information is in the URL itself, a GET URL can be bookmarked, or repeated from the browser, without resubmitting a form. It can also be generated easily by client-side or server-side scripting languages.

Although you may see some very long and complex GET URLs, web servers may have size limits that would snip your URL unceremoniously (ouch). Apache guards against GET buffer overflow attacks, but some other web servers and web cache servers have not.

Since all the parameters are in the URL, they also appear in the web-server logs. If there is any sensitive data in the form, a POST URL should be used.

The question mark and /cgi-bin advertise that this URL calls a CGI script called groucho.pl. You may want the benefits of a GET URL without letting everyone know that this is a CGI script. If an attacker knows you're using Perl scripts on Apache, for instance, he can target his attack more effectively. Another reason involves making the URL more search-engine friendly. Many web search engines skip URLs that look like CGI scripts. One technique uses the PATH_INFO environment variable and Apache rewriting rules. You can define a CGI directory with a name that looks like a regular directory:

ScriptAlias /fakedir/ "/usr/local/apache/real_cgi_bin/"

Within this directory you could have a CGI script called whyaduck. When this URL is received:

http://www.hackenbush.com/fakedir/whyaduck/day/jan%2006/user/zeppo

Apache will execute the CGI script /var/www/real-cgi-bin/whyaduck and pass it the environment variable PATH_INFO with the value /day/jan 06/user/zeppo. Your script can parse the components with any method you like (use split in Perl or explode in PHP to split on the slashes).

Since GET requests are part of the URL, they may be immortalized in server logs, bookmarks, and referrals. This may expose confidential information. If this is an issue, use POST rather than GET. If you don't specify the method attribute for a <form> tag in HTML, it uses GET.

8.4.1.4 POST method

POST is used to send data to a CGI program on the web server. A URL for the POST method appears bare, with no ? or encoded arguments. URL-encoded data is sent in the HTTP body to Apache, then from Apache to the standard input of the CGI program.

A user must resubmit her original form and data to refresh the output page, since the recipient has no way of knowing if the data may have changed. (With a GET URL, everything's in the URL.) The data size is not as limited as with GET. Normally POST data is not logged, although you can configure Apache to do so. A POST URL cannot be bookmarked, and it cannot be automatically submitted from a browser without using client-side JavaScript (other clients like wget and curl can submit POST requests directly). You need to have a button or other link with a JavaScript URL that submits a form that is somewhere on your page.

8.4.1.5 PUT method

This was the original HTTP upload mechanism. Specify a CGI script to handle a PUT request, as you would for a POST request. PUT seems to have been superceded by WebDAV and other methods, which are described in Section 8.5.5.

8.4.2 CGI Languages

Any language can be a CGI language just by following the CGI specification. An HTTP response requires at least an initial MIME type line, a blank, and then content. Here's a minimal CGI script written in the shell:

#!/bin/sh

echo "Content-type: text/html"

echo

echo "Hello, world"

Technically, we should terminate the first two echo lines with a carriage return-line feed pair ('\r\n\r\n'), but browsers know what to do with bare Unix-style line feeds.

Although a C program might run faster than a shell or Perl equivalent, CGI startup time tends to outweigh that advantage. I feel that the best balance of flexibility, performance, and programmer productivity lies with interpreted languages running as Apache modules. The top languages in that niche are PHP and Perl.

I'll discuss the security trouble spots to watch, with examples from Perl and PHP:

• Form-data validation

• External file inclusion

• External program execution

• Form-based file uploads

But first, a few words about Perl and PHP.

8.4.2.1 PHP

PHP is a popular web-scripting language for Unix and Windows. It's roughly similar to, and competes with, Visual BASIC and ASP on Windows. On Unix and Linux, it competes with Perl and Java. Its syntax is simpler than Perl's, and its interpreter is small and fast.

Versions of PHP before 4.1.2 had serious vulnerabilities in the file-uploading code. These could allow an attacker to execute arbitrary code on the web server if any PHP script could be run, even if it did not perform file uploads. If your version is older, get a patch from http://www.php.net.

PHP code is embedded in HTML and distinguished by any of these start and end tags:

<?php ... ?>

<? ... ?>

<% ... %>

PHP files can contain any mixture of normal HTML and PHP, like this:

<? echo "<b>string<b> = <I>$string</I>\n"; ?>

or more compactly:

<b>string</b> = <i><?=$string?></i>

PHP configuration options can be specified in three ways:

• The php.ini file, normally in the /usr/local/lib directory:

  display_errors = off

• The Apache configuration files, in the styles shown in Table 8-5.

  The following is an example that disables PHP's HTML error display:

  php_admin_flag display_errors off

  These can be placed within container directives to customize PHP settings for different directories or virtual hosts. php_value and php_flag may also be used in .htaccess files.

php_value name value

php_flag name on|off

php_admin_value name value

php_admin_flag name on|off

• Some directives (see http://www.php.net/manual/en/function.ini-set) can be set in the PHP script at runtime:

  ini_set("display_errors", "0");

8.4.2.2 Perl

Perl is the mother of all web-scripting languages. The most popular module for CGI processing, CGI.pm, is part of the standard Perl release.

Here's a quick Perl script to get the value of a form variable (or handcrafted GET URL) called string:

#!/usr/bin/perl -w

use strict;

use CGI qw(:standard);

my $string = param("string");

echo header;

echo "<b>string</b> = <I>$string</I>\n";

A Perl CGI script normally contains a mixture of HTML print statements and Perl processing statements.

8.4.3 Processing Form Data

In the previous examples, I showed how to get and echo the value of the form value string. I'll now show how to circumvent this simple code, and how to protect against the circumvention.

Client-side form checking with JavaScript is a convenience for the user, and it avoids a round-trip to the server to load a new page with error messages. However, it does not protect you from a handcrafted form submission with bad data. Here's a simple form that lets the web user enter a text string:

<form name="user_form" method="post" action="/cgi-bin/echo">

<input type="text" name="string">

<input type="submit" value="submit">

</form>

When submitted, we want to echo the string. Let's look again at a naïve stab at echo in PHP:

<? echo "string = $string\n"; ?>

And the same in Perl:

#!/usr/bin/perl -w

use strict;

use CGI qw(:standard);

print header;

print "string = ", param("string"), "\n";

This looks just ducky. In fact, if you type quack into the string field, you see the output:

string = quack

But someone with an evil mind might enter this text into the string field:

<script language=javascript>history.go(-1);</script>

Submit this, and watch it bounce right back to your input form. If this form did something more serious than echo its input (such as entering the contents of string into a database), the results could be more serious.

Never trust user input. Validate everything on the server. Check for commands within data.

This is an example of someone uploading code to your server without your knowledge and then getting it to download and execute on any browser. This cross-site scripting bug was fixed within JavaScript itself some time ago, but that doesn't help in this case, since JavaScript is being injected into the data of a server-side script. HTML tags that invoke active content are shown in Table 8-6.

<script>

<embed>

<object>

<applet>

Each scripting language has the ability to escape input data, removing any magic characters, quotes, callouts, or anything else that would treat the input as something other than plain text.

An even better approach is to specify what you want, rather than escaping what you don't want. Match the data against a regular expression of the legal input patterns. The complexity of the regular expression would depend on the type of data and the desired level of validity checking. For example, you might want to ensure that a U.S. phone number field has exactly 13 digits or that an email address follows RFC 822.

8.4.3.1 PHP

To avoid interpreting a text-form variable as JavaScript or HTML, escape the special characters with the PHP functions htmlspecialcharacters or htmlentities. As mentioned previously, it's even better to extract the desired characters from the input first via a regular-expression match. In the following section, there's an example of how Perl can be used to untaint input data.

PHP has had another security issue with global data. When the PHP configuration variable register_globals is enabled, PHP creates an automatic global variable to match each variable in a submitted form. In the earlier example, a PHP variable named $string winks into existence to match the form variable string. This makes form processing incredibly easy. The problem is that anyone can craft a URL with such variables, forging a corresponding PHP variable. So any uninitialized variable in your PHP script could be assigned from the outside.

The danger is not worth the convenience. Specify register_globals off in your php.ini file. Starting with PHP 4.1.2, this is the default setting. PHP Versions 4.1.1 and up also provide safer new autoglobal arrays. These are automatically global within PHP functions (in PHP, you need to say global var within a PHP function to access the normal global variable named var; this quirk always bites Perl developers). These arrays should be used instead of the older arrays $HTTP_GET_VARS and $HTTP_POST_VARS and are listed in Table 8-7.

$HTTP_ENV_VARS

$_ENV

$HTTP_GET_VARS

$_GET

$HTTP_POST_VARS

$_POST

$HTTP_POST_FILES

$_FILES

$HTTP_COOKIE_VARS

$_COOKIE

$HTTP_SERVER_VARS

$_SERVER

Another new autoglobal array, $_REQUEST, is the union of $_GET, $_POST, and $_COOKIE. This is handy when you don't care how the variable got to the server.

8.4.3.2 Perl

Perl runs in taint mode :

• Automatically when the real and effective user ID and group ID differ

• Explicitly when invoked with the -T flag

This mode marks data originating outside the script as potentially unsafe and forces you to do something about it. To untaint a variable, run it through a regular expression, and grab it from one of the positional match variables ($1, $2, ...). Here's an example that gets a sequence of "word" characters (\w matches letters, digits, and _):

#!/usr/bin/perl -wT

use strict;

use CGI qw(:standard);



my $user = param("user");

if ($user =~ /^(\w+)$/) { $user = $1; }

We'll see that taint mode applies to file I/O, program execution, and other areas where Perl is reaching out into the world.

8.4.4 Including Files

CGI scripts can include files inside or outside of the document hierarchy. Try to move sensitive information from your scripts to files located outside the document hierarchy. This is one layer of protection if your CGI script somehow loses its protective cloak and can be viewed as a simple file.

Use a special suffix for sensitive include files (a common choice is .inc), and tell Apache not to serve files with that suffix. This will protect you when you accidentally put an include file somewhere in the document root. Add this to an Apache configuration file:

<FilesMatch ~ /\.inc$/>

order allow, deny

deny from all

</Files>

Also, watch out for text editors that may leave copies of edited scripts with suffixes like ~ or .bak. The crafty snoop could just ask your web server for files like program~ or program.bak. Your access and error logs will show if anyone has tried. To forbid serving them anywhere, add this to your Apache configuration file:

<FilesMatch ~ /(~,\.bak)$/>

order allow, deny

deny from all

</Files>

When users are allowed to view or download files based on a submitted form variable, guard against attempts to access sensitive data, such as a password file. One exploit is to use relative paths (..):

../../../etc/passwd

Cures for this depend on the language and are described in the following sections.

8.4.4.1 PHP

External files can be included with the PHP include or include_once commands. These may contain functions for database access or other sensitive information. A mistake in your Apache configuration could expose PHP files within normal document directories as normal text files, and everyone could see your code. For this reason, I recommend the following:

• Include sensitive PHP scripts from a location outside of your document root. Edit php.ini to specify:

  include_path       .:/usr/local/lib/php:/usr/local/my_php_lib

• Use the protected suffix for your included files:

  <? include_once "db_login.inc"; ?>

Use the basename function to isolate the filename from the directory and open_basedir to restrict access to a certain directory. These will catch attempts to use ../ relative filenames.

If you process forms where people request a file and get its contents, you need to watch the PHP file-opening command fopen and the file-reading commands fpassthru and readfile. fopen and readfile accept URLs as well as filenames; disable this with allow_url_fopen=false in php.ini. You may also limit PHP file operations to a specific directory with the open_basedir directive. This can be set within Apache container directives to limit virtual hosts to their backyards:

<VirtualHost 192.168.102.103>

ServerName a.test.com

DocumentRoot /usr/local/apache/hosts/a.test.com

php_admin_value open_basedir /usr/local/apache/hosts/a.test.com

</VirtualHost>

If safe_mode is enabled in php.ini or an Apache configuration file, a file must be owned by the owner of the PHP script to be processed. This is also useful for virtual hosts.

Table 8-8 lists recommended safe settings for PHP.

register_globals

off

off

safe_mode

off

on

safe_mode_exec_dir

/usr/local/apache/host/cgi

open_basedir

/usr/local/apache/host/files

display_errors

on

off

log_errors

off

on

allow_url_fopen

on

off

session.save_path

/tmp

/usr/local/apache/sessions

In Table 8-8, I'm assuming you might set up a directory for each virtual host under /usr/local/apache/host. You can specify multiple directories with a colon (:) separator.

8.4.4.2 Perl

In taint mode, Perl blocks use of the functions eval, require, open (except read-only mode), chdir, chroot, chmod, unlink, mkdir, rmdir, link, and symlink. You must untaint filenames before using any of these. As in the PHP example, watch for relative (../) names and other attempts to access files outside the intended area.

8.4.5 Executing Programs

Most scripting languages let you run external programs. This is a golden opportunity for nasty tricks. Check the pathname and remove any metacharacters that would allow multiple commands. Avoid passing commands through a shell interpreter.

8.4.5.1 PHP

Escape any possible attempts to slip in extra commands with this PHP function:

$safer_input = escapeshellarg($input);

system("some_command $safer_input");

or:

escapeshellcmd("some_command $input");

These PHP functions invoke the shell and are vulnerable to misuse of shell metacharacters: system, passthru, exec, popen, preg_replace (with the /e option), and the backtick (`command`) operator.

If safe_mode is set, only programs within safe_mode_exec_dir can be executed, and only files owned by the owner of the PHP script can be accessed.

The PHP function eval($arg) executes its argument $arg as PHP code. There's no equivalent to safe_mode for this, although the disable_functions option lets you turn off selected functions. Don't execute user data.

8.4.5.2 Perl

Taint mode will not let you pass unaltered user input to the functions system, exec, eval, or the backtick (`command`) operator. Untaint them before executing, as described earlier.

8.4.6 Uploading Files from Forms

RFC 1867 documents form-based file uploads ? a way of uploading files through HTML, HTTP, and a web server. It uses an HTML form, a special form-encoding method, and an INPUT tag of type FILE:

<form

method="post"

enctype="multipart/form-data"

action="/cgi-bin/process_form.php">

<input type="text" name="photo_name">

<input type="file" name="upload">

<input type="submit" value="submit">

</form>

This is another golden opportunity for those with too much time and too little conscience. A file upload is handled by a CGI file-upload script. There is no standard script, since so many things can be done with an uploaded file.

8.4.6.1 PHP

Uploaded files are saved as temporary files in the directory specified by the PHP directive upload_tmp_dir. The default value (/tmp) leaves them visible to anyone, so you may want to define upload_tmp_dir to some directory in a virtual host's file hierarchy. To access uploaded files, use the new autoglobal array $_FILES, which is itself an array. For the photo-uploading example, let's say you want to move an uploaded image to the photos directory of virtual host host:

<?

// $name is the original file name from the client

$name = $_FILES['photo_file']['name'];



// $type is PHP's guess of the MIME type

$type = $_FILES['photo_file']['type'];



// $size is the size of the uploaded file (in bytes)

$size = $_FILES['photo_file']['size'];



// $tmpn is the name of the temporary uploaded file on the server

$tmpn = $_FILES['photo_file']['tmp_name'];



// If everything looks right, move the temporary file

// to its desired place.

if (is_uploaded_file($tmpn))

    move_uploaded_file($tmpn, "/usr/local/apache/host/photos");

You may check the file's type, name, and size before deciding what to do with it. The PHP option max_upload_filesize caps the size; if a larger file is uploaded, the value of $tmpn is none. When the PHP script finishes, any temporary uploaded files are deleted.

8.4.6.2 Perl

The CGI.pm module provides a file handle for each temporary file.

#!/usr/bin/perl -wT

use strict;

use CGI qw(:standard);

my $handle = param("photo_file");

my $tmp_file_name = tmpFileName($handle);

# Copy the file somewhere, or rename it

# ...

The temporary file goes away when the CGI script completes.

8.4.7 Accessing Databases

Although relational databases have standardized on SQL as a query language, many of their APIs and interfaces, whether graphic or text based, have traditionally been proprietary. When the Web came along, it provided a standard GUI and API for static text and dynamic applications. The simplicity and broad applicability of the web model led to the quick spread of the Web as a database frontend. Although HTML does not offer the richness and performance of other graphic user interfaces, it's good enough for many applications.

Databases often contain sensitive information, such as people's names, addresses, and financial data. How can a porous medium like the Web be made safer for database access?

• Don't have your database on the same machine as the web server. It's best if your database is behind a firewall that only passes queries from your web server. For example, MySQL normally uses port 3306, so you might only permit access from ports on the web server to port 3306 on the database server.

• Check that all default database passwords have been changed. For MySQL, ensure that the default user (called root, but not related to the Unix root user) has a password. You have a problem if you can get into the database without a password by typing:

  mysql -u root

• Use the SQL GRANT and REVOKE statements to control access to tables and other resources only for the desired MySQL IDs on the desired servers. An example might follow this pattern:

  GRANT SELECT ON sample_table
  
  TO "sample_user@sample_machine"
  
  IDENTIFIED BY "sample password"

• Do not allow access to the MySQL users table by anyone other than the MySQL root user, since it contains the permissions and encrypted passwords.

• Don't use form variable values or names in SQL statements. If the form variable user maps directly to a user column or table, then someone will deduce the pattern and experiment.

• Check user input before using it in SQL statements. This is similar to checking user input before executing a shell command. Exploits have been called SQL injection. See SQL Injection ? Are Your Web Applications Vulnerable? (http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf).

Any time information is exchanged, someone will be tempted to change it, block it, or steal it. We'll quickly review these issues in PHP and Perl database CGI scripts:

• Which database APIs to use

• Protecting database account names and passwords

• Defending against SQL injection

8.4.7.1 PHP

PHP has many specific and generic database APIs. There is not yet a clear leader to match Perl's DBI.

A PHP fragment to access a MySQL database might begin like this:

<?

$link = mysql_connect("db.test.com", "dbuser", "dbpassword");

if (!$link)

    echo "Error: could not connect to database\n";

?>

If this fragment is within every script that accesses the database, every instance will need to be changed if the database server, user, or password changes. More importantly, a small error in Apache's configuration could allow anyone to see the raw PHP file, which includes seeing these connection parameters. It's easier to write a tiny PHP library function to make the connection, put it in a file outside the document root, and include it where needed.

Here's the include file:

// my_connect.inc

// PHP database connection function.

// Put this file outside the document root!



// Makes connection to database.

// Returns link id if successful, false if not.

function   my_connect( )

{

$database  = "db.test.com";

$user      = "db_user";

$password  = "db_password";

$link = mysql_connect($database, $user, $password);

return $link;

}

And this is a sample client:

// client.php

// PHP client example.

// Include path is specified in include_path in php.ini.

// You can also specify a full pathname.

include_once "my_connect.inc";



$link = my_connect( );

// Do error checking in client or library function

if (!$link)

    echo "Error: could not connect to database\n";

// ...

Now that the account name and password are better protected, you need to guard against malicious SQL code. This is similar to protecting against user input passing directly to a system command, for much the same reasons. Even if the input string is harmless, you still need to escape special characters.

The PHP addslashes function puts a backslash (\) before these special SQL characters: single quote ('), double quote ("), backslash (\), and NUL (ASCII 0). This will be called automatically by PHP if the option magic_quotes_gpc is on. Depending on your database, this may not quote all the characters correctly.

SQL injection is an attempt to use your database server to get access to otherwise protected data (read, update, or delete) or to get to the operating system. For an example of the first case, say you have a login form with user and password fields. A PHP script would get these form values (from $_GET, $_POST, or $_REQUEST, if it's being good), and then build a SQL string and make its query like this:

$sql =     "SELECT COUNT(*) FROM users WHERE\n" .

           "user = '$user' AND\n".

           "password = '$password'";

$result = mysql_query($sql);

if ($result && $row = mysql_fetch_array($result) && $row[0] == 1)

    return true;

else

    return false;

An exploiter could enter these into the input fields (see Table 8-9).

'  OR  '' = ''

'  OR  '' = ''

The SQL string would become:

SELECT COUNT(*) FROM users WHERE

user = '' OR '' = '' AND

password = '' OR '' = ''

The door is now open. To guard against this, use the techniques I've described for accessing other external resources, such as files or programs: escape metacharacters and perform regular-expression searches for valid matches. In this example, a valid user and password might be a sequence of letters and numbers. Extract user and password from the original strings and see if they're legal.

In this example, if the PHP option magic_quotes_gpc were enabled, this exploit would not work, since all quote characters would be preceded by a backslash. But other SQL tricks can be done without quotes.

A poorly written script may run very slowly or even loop forever, tying up an Apache instance and a database connection. PHP's set_time_limit function limits the number of seconds that a PHP script may execute. It does not count time outside the script, such as a database query, command execution, or file I/O. It also does not give you more time than Apache's Timeout variable.

8.4.7.2 Perl

Perl has the trusty database-independent module DBI and its faithful sidekicks, the database-dependent (DBD) family. There's a DBD for many popular databases, both open source (MySQL, PostgreSQL) and commercial (Oracle, Informix, Sybase, and others).

A MySQL connection function might resemble this:

# my_connect.pl

sub my_connect

{

my $server        = "db.test.com";

my $db            = "db_name";

my $user          = "db_user";

my $password      = "db_password";

my $dbh           = DBI->connect(

        "DBI:mysql:$db:$server",

        $user

        $password,

        { PrintError => 1, RaiseError => 1 })

        or die "Could not connect to database $db.\n";

return $dbh;

}

1;

As in the PHP examples, you'd rather not have this function everywhere. Perl has, characteristically, more than one way to do it. Here is a simple way:

require "/usr/local/myperllib/my_connect.pl";

If your connection logic is more complex, it could be written as a Perl package or a module.

Taint mode won't protect you from entering tainted data into database queries. You'll need to check the data yourself. Perl's outstanding regular-expression support lets you specify patterns that input data must match before going into a SQL statement.

8.4.8 Checking Other Scripts

Once you've secured Apache and your own scripts, don't forget to check any other old scripts that may be lying around. Some demo scripts and even commercial software have significant holes. I suggest disabling or removing any CGI scripts if you aren't certain about them.

whisker (http://www.wiretrip.net/rfp/p/doc.asp/i2/d21.htm) is a Perl script that checks for buggy CGI scripts against a vulnerability database.

8.4.9 Continuing Care

Check your error_log regularly for bad links, attacks, or other signs of trouble. You are sure to see many IIS-specific exploit attempts such as Code Red and Nimda, but someone might actually be targeting a LAMP component.