ch01_04.htm

用perl编写CGI的好书。本书从解释CGI和底层HTTP协议如何工作开始

<em class="filename">htdocs</em> directory. All files beneath this
directory are browsable. By default, the <em class="filename">cgi-bin</em>
directory is not beneath <em class="filename">htdocs</em>, so if we were
to disable our <tt class="literal">ScriptAlias</tt> directive, for example,
there would be no way to access the CGI scripts. There is a very good
reason for this, and it is not simply to protect yourself from
someone accidentally deleting the <tt class="literal">ScriptAlias</tt>
directive.</p>



<p>Here is an example why you should not place your CGI script directory
within the document root. Say you do decide that you want to have
multiple directories for CGI scripts throughout your web site within
the document root. You might decide that it would be nice to have a
directory for each of your major applications. Say that you have an
online widget store that you put in
<em class="filename">/usr/local/apache/htdocs/widgets</em> and the CGI
script directory at
<em class="filename">/usr/local/apache/htdocs/widgets/cgi</em>. You then
add the following directive:</p>



<blockquote><pre class="code">ScriptAlias     /widgets-cgi   /usr/local/apache/htdocs/widgets/cgi</pre></blockquote>



<p>If you were to do this and test it, it would work fine. However,
suppose that your company later expands to sell woozles in addition
to widgets, so the store needs a more general name. You rename the
<em class="filename">widgets</em> directory to <em class="filename">store</em>,
update the <tt class="literal">ScriptAlias</tt> directive, update all
related HTML links, and create a symbolic link from
<em class="filename">widgets</em> to <em class="filename">store</em> in order
to support those users who bookmarked the old name. Sounds like a
good plan, right?</p>



<p>Unfortunately, that last step, the symbolic link, just
<a name="INDEX-148" />
<a name="INDEX-149" />
<a name="INDEX-150" />created a large security hole. The problem
is that it is now possible to access your CGI scripts via two
different URLs. For example, you may have a CGI script called
<em class="filename">purchase.cgi</em> that can be accessed either of
these two ways:</p>



<blockquote class="simplelist">

<p><em class="emphasis">http://localhost/store-cgi/purchase.cgi</em></p>

<p><em class="emphasis">http://localhost/widgets-cgi/purchase.cgi</em></p>

</blockquote>



<p>The first URL will be handled by the <tt class="literal">ScriptAlias</tt>
directive; the second will not. If users attempt to access the second
URL, instead of being greeted by a web page, they will be greeted
with the source code of your CGI script. If you're lucky,
someone will send you an email notifying you of the problem. If
you're not, a mischievous user may start poking around your
scripts to find security holes to break into your system to get at
more valuable information (like database passwords or credit card
numbers).</p>



<p>Any symbolic link above a directory containing CGI scripts allows
this security hole.<a href="#FOOTNOTE-1">[1]</a> The scenario about renaming a
directory and providing a link to its old name is simply one example
of a situation when this may occur innocently. If you place your CGI
scripts outside of your server's document root, you never have
to worry about someone accidentally exposing your scripts this way.</p><blockquote>


<a name="FOOTNOTE-1" /><p>[1]It is possible to configure
Apache to not follow symbolic links, which provides an alternative
solution. However, symbolic links in general can be quite useful, and
they are enabled by default. The problem in this situation is not
with the symbolic link; it is with having the CGI scripts in a
browsable location.</p>


</blockquote>



<p>You may wonder why revealing your <a name="INDEX-151" />source code is such a problem. CGI
scripts have certain characteristics that make them quite different
than other forms of executables from a security standpoint. They
allow remote, anonymous users to run programs on your system. Thus,
security should always be an important consideration, and your code
must be flawless if you are willing to allow potential attackers to
review your source code. Although security through obscurity is not
good protection in and of itself, it certainly doesn't hurt
when combined with other forms of security. We will discuss security
in much greater detail in <a href="ch08_01.htm">Chapter 8, "Security"</a>.</p>
</div>





<a name="ch01-7-fm2xml" /><div class="sect3">
<h3 class="sect3">1.4.1.2. Configuring by extension</h3>



<p>The alternative to configuring <a name="INDEX-152" />CGI
scripts via a common <a name="INDEX-153" />directory is to distribute them
throughout your document tree and have your web server recognize them
by their <a name="INDEX-154" />filename extension, such as
<em class="filename">.cgi</em>. This is a very bad idea, from the
standpoint of both <a name="INDEX-155" />
<a name="INDEX-156" />architecture and security.</p>



<p>From an architectural standpoint, you should not do this because
having a common directory for all of your CGI scripts helps you
manage them. As web sites grow, it may be difficult to keep track of
all of the CGI scripts that your site uses. Placing them under a
common directory makes them easier to find and promotes creating CGI
scripts that are general solutions to multiple problems instead of
handfuls of single-use scripts. You can then create subdirectories
beneath the main <em class="filename">/cgi</em> directory to organize your
scripts.</p>



<p>There are two reasons why configuring CGI scripts by extension is
insecure. First, it allows anyone who has permissions to update HTML
files to create CGI scripts. As we said, CGI scripts require
particular security considerations, and you should not allow novice
programmers to create scripts on production web servers. Second, it
increases the likelihood that someone can view the source code to
your CGI scripts. Many <a name="INDEX-157" />text
editors create <a name="INDEX-158" />backup files while you are
editing a file; some of them create these files in the same directory
where you are working. For example, if you were editing a file called
<em class="filename">top_secret.cgi</em> with <tt class="command">emacs</tt>, it
typically creates a backup file called
<em class="filename">top_secret.cgi~</em>. If this second file makes it
onto the production web server and someone with a lucky hunch
attempts to request that file, the web server will not recognize the
extension and will simply return the raw source code.</p>



<p>Of course, your text editor ideally should delete these files when
you finish working on them, and you really should not be editing
files directly on a production web server. But files like this do get
left around sometimes, and they might make it to the production web
server. Files also get renamed manually sometimes. A developer may
wish to make changes to a file but save a backup of this file by
making a copy and renaming it with a <em class="filename">.bak</em>
extension. If a backup file were in a directory configured with
<tt class="literal">ScriptAlias</tt>, then it is not displayed; it is
treated like any other CGI script and executed, which is a much safer
alternative.</p>



<p>So, if your web server happens to be configured to allow CGI scripts
anywhere, here is how to fix it. The following line tells the web
server to execute any file ending with a <em class="filename">.cgi</em>
suffix:</p>



<blockquote><pre class="code">AddHandler    cgi-script    .cgi</pre></blockquote>



<p>You can <a name="INDEX-159" />comment it
<a name="INDEX-160" />out by preceding it with
<tt class="literal">#</tt>, just like in Perl. Without this directive,
Apache will treat <em class="filename">.cgi</em> files as unknown files
and return them according to the default media type -- typically
plain text. So be sure that you move all of your CGI scripts outside
the document root before you remove this directive.</p>



<p>You may also turn off the CGI
<a name="INDEX-161" />
<a name="INDEX-162" />
<a name="INDEX-163" />execute permissions for particular
directories by disabling the
<tt class="literal">ExecCGI</tt>
<a name="INDEX-164" /> option. The line to enable it looks
like this:</p>



<blockquote><pre class="code">&lt;Directory "/usr/local/apache/htdocs"&gt;
  .
  .
  Options Indexes FollowSymLinks ExecCGI
  .
  .
&lt;/Directory&gt;</pre></blockquote>



<p>There are probably many other lines above and below the
<tt class="literal">Options</tt> directive, and the
<tt class="literal">Options</tt> directive on your system may differ. If
you remove <tt class="literal">ExecCGI</tt>, then even with the CGI handler
directive enabled above, Apache will not execute CGI scripts in the
location that this <tt class="literal">Options</tt> directive
applies -- in this case, the document root,
<em class="filename">/usr/local/apache/htdocs</em>. Users will instead get
an error page telling them "Permission Denied."</p>



<p>Now that we have our web server set up, and we have gotten a chance
to see what CGI can do, we can investigate CGI in more detail. We
start the next chapter by reviewing HTTP, the language of the Web
<a name="INDEX-165" />
<a name="INDEX-166" />
<a name="INDEX-167" />and the
foundation <a name="INDEX-168" />of CGI.</p>
</div>
</div>


<hr align="left" width="515" />
<div class="navbar"><table border="0" width="515"><tr><td width="172" valign="top" align="left"><a href="ch01_03.htm"><img src="../gifs/txtpreva.gif" alt="Previous" border="0" /></a></td><td width="171" valign="top" align="center"><a href="index.htm"><img src="../gifs/txthome.gif" alt="Home" border="0" /></a></td><td width="172" valign="top" align="right"><a href="ch02_01.htm"><img src="../gifs/txtnexta.gif" alt="Next" border="0" /></a></td></tr><tr><td width="172" valign="top" align="left">1.3. Alternative Technologies</td><td width="171" valign="top" align="center"><a href="index/index.htm"><img src="../gifs/index.gif" alt="Book Index" border="0" /></a></td><td width="172" valign="top" align="right">2. The Hypertext Transport Protocol </td></tr></table></div>
<hr align="left" width="515" />

<img src="../gifs/navbar.gif" alt="Library Navigation Links" usemap="#library-map" border="0" />
<p><font size="-1"><a href="copyrght.htm">Copyright &copy; 2001</a> O'Reilly &amp; Associates. All rights reserved.</font></p>

<map name="library-map"><area href="../index.htm" coords="1,1,83,102" shape="rect" /><area href="../lnut/index.htm" coords="81,0,152,95" shape="rect" /><area href="../run/index.htm" coords="172,2,252,105" shape="rect" /><area href="../apache/index.htm" coords="238,2,334,95" shape="rect" /><area href="../sql/index.htm" coords="336,0,412,104" shape="rect" /><area href="../dbi/index.htm" coords="415,0,507,101" shape="rect" /><area href="../cgi/index.htm" coords="511,0,601,99" shape="rect" /></map>

</body></html>