18.2.2.1 Configuration files

Inside the conf directory, the NCSA server has the following files:

Because the information in these files can be used to subvert your server or your entire system, you should protect the scripts so they can only be read and modified by the superuser:

-rw-------  1 root     wheel        954 Aug  6 01:00 access.conf
-rw-------  1 root     wheel       2840 Aug  6 01:05 httpd.conf
-rw-------  1 root     wheel       3290 Aug  6 00:30 mime.types
-rw-------  1 root     wheel       4106 Nov 26 11:00 srm.conf

18.2.2.2 Additional configuration issues

Besides the setting of permissions, you may wish to enable or disable the following configuration options:

Automatic directory listings

Most Web servers will automatically list the contents of a directory if a file called index.html is not present in directory. This feature can cause security problems, however, as it gives outsiders the ability to scan for files and vulnerabilities on your system.

Symbolic-link following

Some servers allow you to follow symbolic links outside of the Web server's document tree. This allows somebody who has access to your Web server's tree to make other documents on your computer available for Web access. You may not want people to be able to do this, so don't enable the following of symbolic links. Alternatively, you may wish to set your Web server's symlinks "If Owner Match" option, so that links are followed only if the owner of the link matches the owner of the file that it points to.

Server-side includes

Server-side includes are directives that can be embedded in an HTML document. The includes are processed by the HTML server before the document is sent to a requesting client. Server-side includes can be used to include other documents or to execute documents, and output the result.

Here are two sample server-side includes that demonstrate why their use is a bad idea:

<!--#include file="/etc/passwd">

<!--#exec cmd="rm -rf /&;cat /etc/passwd">

The first include provides an attacker with the contents of your /etc/passwd file, allowing them to wage a password-cracking attack. The second launches a background process that attempts to delete every writable file on your computer. Then it provides the attacker with a copy of your /etc/passwd file.

Fortunately, server-side includes must be specifically enabled on most Web servers. They are normally turned off.

Some servers, such as the NCSA server, allow you to limit processing of server-side includes to specific directories. The NCSA server uses the Options directive to control includes. Specify the option Includes for all server-side includes; specify the option IncludesNOEXEC to specify textual includes but to disable the execution of commands.

NOTE: Server-side includes should never be enabled for script directories. This is because it is possible that a script will output something that the user has typed, and the Web server will attempt to interpret the output, giving an attacker the ability to include arbitrary files or to execute arbitrary commands.

18.2.3.1 Do not trust the user's browser!

HTML includes the ability to display selection lists, limit the length of fields to a certain number of characters, embed hidden data within forms, and specify variables that should be provided to CGI scripts. Nevertheless, you cannot make your CGI script depend on any of these restrictions. That is because any CGI script can be run by directly requesting the script's URL; attackers do not need to go through your form or use the interface that you provide.

Be especially careful of the following:

• If you create a selection list, the value that is returned for the input field will not necessarily match the allowable values that you have defined.

• If you specify a maximum length for a variable, the length of the variable that is provided to your script may be significantly longer. (What would your script do if provided with a username that is 4000 characters long?)

• Variables that are provided to your script may have names not defined in your script.

• The values for variables that are provided may contain special characters.

• The user may view data that is marked as "hidden."

• If you use cookies or special hidden tags to maintain state on your server, your script may receive cookies or tags that it never created.

Attackers are by definition malicious. They do not follow the rules. Never trust anything that is provided over the network.

18.2.3.2 Testing is not enough!

One of the reasons that it is surprisingly easy to create an unsecure CGI script is that it is very difficult to test your scripts against the wide variety of HTTP clients available. For example, most client programs will "escape," or specially encode, characters such as the backquote (`), which are specially interpreted by the UNIX shell. As a result, many CGI programmers do not expect the unencoded characters to be present in the input stream for their applications, and they do not protect their scripts against the possibility that the characters are present. Nevertheless, it is easy for the characters to be in the input stream, either as the result of a bug in a particular Web browser or, more likely, because a malicious attacker is attempting to subvert your CGI script and gain control of your server.

• Check all values that are provided to your program for special characters and appropriate length.

By all values, we mean all values. This includes the contents of environment variables, host addresses, host names, URLS, user-supplied data, values chosen from selection lists, and even data that your script has inserted onto a WWW form through the use of the hidden data type.

Consider the case of a CGI script that creates a series of log files for each host that contacts your WWW server. The name of the log file might be the following: logfile/{hostname}. What will this program do if it is contacted by the "host" ../../../../etc/passwd.company.com? Such a script, if improperly constructed, could end up appending a line to a system's /etc/passwd file. This could then be used as a way of creating unauthorized accounts on the system.

• Beware of system( ), popen ( ), pipes, backquotes (`), and Perl's eval ( ) function.

Many programming languages, including C, ksh, sh, csh, and Perl, provide the means to spawn subprocesses. You should try to avoid using these features when writing CGI scripts. If you must spawn a subprocess, avoid passing through any strings that are provided by the user. If you must pass strings from the user to the subprocess, be sure that it does not pass shell meta characters including the `$|;>*<&> characters.

It is generally better to specify a list of allowable characters than to specify a list of dangerous characters. If you forget to specify an allowable character, there is no real harm done. But if you forget to specify a dangerous character, such as a backquote, you can compromise the security of your entire system.

18.2.3.3 Sending mail

If you are writing a CGI script that allows a user to send mail, use the /usr/lib/sendmail program to send the mail, rather than /bin/mailx or /usr/ucb/mail. The reason is that /usr/lib/sendmail does not have shell escapes, whereas the other mailers do.

Here is a bit of Perl that you can use to send mail securely. It bypasses the shell by using exec ( ) with a fixed string to run /usr/lib/sendmaildirectly:

 open (WRITE, "|-")
|| exec ("usr/lib/sendmail", "-oi," "-t")
|| die "Can't fork$!\n":

print WRITE "To: $address\n";
print WRITE "Subject: $subject\n";
print WRITE "From: $sender\n";
print WRITE "\n$message\n.\n";
close(WRITE);

There are many commands in Perl that will run the shell, possibly without your knowledge. These include system ( ), eval ( ), pipes, backquotes, and, occasionally, exec ( ) (if shell meta characters are present on the command line).

18.2.3.4 Tainting with Perl

If you are using the Perl programming language, you can use Perl's "tainting" facility to track information that has been provided by the user. Perl marks such information as "tainted." The only way to untaint information is to match it using a Perl regular expression, and then to copy out the matched values using Perl's string match variables.

For example, if you have a name that has been provided by the user, you can untaint the value to be sure that it only contains letters, numbers, commas, spaces, and periods by using the following Perl statements:

$tainted_username =~ m/([a-zA-Z. ]*)/;
$untainted_username = $1;

You can use the following to extract an email address:

$tainted_email =~ /([\w-.%]+\@[\w.-]+)/;
$untainted_email = $1;

There are two ways to enable tainting. If you are using Perl 4, you should invoke the taintperl command instead of the Perl command, by placing the following statement (or something similar) at the beginning of your file:

#!/usr/local/bin/taintperl

If you are using Perl version 5, you accomplish the same result by using the -T flag:

#!/usr/local/bin/perl -T

18.2.3.5 Beware stray CGI scripts

Most Web servers can be configured so that all CGI scripts must be confined to a single directory. We recommend this configuration, because it makes it easier for you to find and examine all of the CGI scripts on your system. We do not recommend the practice of allowing any file on the Web server with the extension ".cgi" to be run as a CGI script.

Instead, we recommend that you:

• Configure your Web server so that all CGI scripts must be placed in a single directory (typically, the directory is called cgi-bin).

• Use a program such as Tripwire (see Chapter 9, Integrity Management) to monitor for unauthorized changes to these scripts.

• Allow limited access to this directory and its contents. Local users should not be allowed to install or remove scripts, or to edit existing scripts without administrative review. You also may want to prevent these scripts from being read, to prevent someone from snooping.

• Remove the backup files that are automatically generated by your editor. Many system administrators use text editors such as Emacs to edit scripts that are in place on the running server. Frequently, this leaves behind backup files, with names such as start~ or create-account~. These backup files can be executed an attacker, usually with unwanted results.

18.2.4.1 Beware mixing HTTP with anonymous FTP

Many sites use the same directory for storing documents that are accessed through anonymous FTP and the World Wide Web. For example, you may have a directory called /NetDocs on your server that is both the home directory of the FTP user and the root directory of your Web server. This would allow files to be referred to by two URLS, such as http://server.com/nosmis/myfile.html or ftp://server.com/nosmis/myfile.html.

The primary advantage of HTTP over FTP is speed and efficiency. HTTP is optimized for anonymous access from a stateless server. FTP, on the other hand, had anonymous access added as an afterthought, and requires that the server maintain a significant amount of state for the client

Mixing HTTP and FTP directories poses a variety of security issues, including:

• Allowing anonymous FTP access to the HTTP directories gives users a means of bypassing any restrictions on document access that the Web server may be providing. Thus, if you have confidential documents stored on your Web server, they may not remain confidential for long with this arrangement.

• If an attacker can download your CGI scripts with FTP, he can search them for avenues for attack.

• You must be very sure that there is no way for an FTP user to upload a script that will be run on your server.

• The /etc/passwd file present for your FTP service might be visible to someone using the WWW service, thus leading to a compromise of its contents. If you have included any real passwords in that file, they will be available to the client for remote password cracking.