asg03.htm

apache技术手册

<BR>

<P>If a user protects his directory, making it unreadable by the User ID (UID) of the server, then he doesn't have an opportunity to publish a home page. Other security implications are possible too, depending on the permissiveness of your configuration files and features such as automatic indexes. You can create a situation where a user could provide Web access to not only his files but to other directories in your system. This is something you really don't want to do!

<BR>

<P>Apache versions under 1.1 don't provide any configuration alternative, except for installing a third-party module that implements different functionality. If you are using version 1.1 or higher, you'll be glad to know that the version of the module allows you to specify a directory that contains all user's public HTML directories. Users are able to create and maintain their own Web pages while administrators are happy that their HTML directories are not located along with other potentially sensitive files.

<BR>

<P>An additional benefit of the improved module is that it allows you to create home page directories that don't necessarily match your internal usernames. Because this mechanism doesn't rely on a user account, it allows you to provide home pages even on a host that doesn't hold any user accounts, such as a <I>bastion host</I> for a site that has a firewall. Bastion hosts are machines that provide Internet services to the Internet.

<BR>

<P>You will need to provide some sort of mechanism to help users upload their information and publish it to the Web. In terms of security issues, you'll still have to deal with what they publish, but I'll leave that to your internal Web police. Let's assume that your organization doesn't have any disgruntled employees that would publish your most private secrets right off your Web site.

<BR>

<BR>

<A NAME="E68E27"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>CGI Location</B></FONT></CENTER></H3>

<BR>

<P>CGIs are programs that interact with your server via the Common Gateway Interface&#151;a convention used for exchanging data between the server and a program. CGIs are necessary on your Web if you want to implement things such as forms or any type of advanced functionality. On the default configuration you installed in <A HREF="asg02.htm" tppabs="http://docs.rinet.ru:8080/Apachu/asg02.htm">Chapter 2</A>, CGIs were disabled. 

<BR>

<P>The problem with CGIs and other executable processes is that they are programs. Security problems are usually introduced by bugs in programs. While your Web server is fairly secure, programs that you implement may not take into account some of the treachery that some people will go through to break into your site. With that said, realize that someone may be able to exploit a weakness on a CGI program you create. (For detailed information on this subject, see <A HREF="asg16.htm" tppabs="http://docs.rinet.ru:8080/Apachu/asg16.htm">Chapter 16</A>, &quot;Other Security Issues.&quot;)

<BR>

<P>My first suggestion is that until you understand the ramifications of permitting public CGIs, you should restrain from offering this capability to your users. There are a few questions that you'll need to address before you can really provide an evaluation:

<BR>

<UL>

<LI>What does the CGI do?

<BR>

<BR>

<LI>How does CGI do it?

<BR>

<BR>

<LI>Could CGI present a security risk if it was terminated abruptly?

<BR>

<BR>

<LI>What if the CGI receives unexpected input or more input than it can handle?

<BR>

<BR>

<LI>Do you allow nonalphanumeric characters in your input?

<BR>

<BR>

</UL>

<P>Once you understand what you are installing and what you are protecting against, it becomes easier to define a policy regarding the use and location of CGI programs on your site. The easiest approach is to read the source code of each CGI before you install it. However, this obviously doesn't scale well on large installations, especially where a lot of users may be creating programs. It becomes unfeasible to look in close detail at what each CGI does and the security implications of the program.

<BR>

<P>To enable CGI, you will need to uncomment the ScriptAlias directive in your conf/srm.conf file and restart the server. The ScriptAlias directive specifies a directory where the server can execute programs. By default, this is set to /usr/local/etc/httpd/cgi-bin/. This provides a restrictive setup because the server will only execute programs that are found in this directory.

<BR>

<P>Because the server restricts the execution of CGI to designated directories, the organizational structure previously presented would require that all CGIs live in a central location. While this may be fine for a small site, you may have to consider other alternatives and their security implications:

<BR>

<UL>

<LI>House your CGIs in the cgi-bin directory.

<BR>

<BR>

<LI>House CGIs in a special cgi directory in the main tree for each site you host (inside your ws wrapper).

<BR>

<BR>

<LI>Allow CGIs to live wherever they are needed.

<BR>

<BR>

</UL>

<P>These options progressively lax on their security. I feel that the <A NAME="I3"></A>second option is a good compromise for the following reasons:

<BR>

<P>It allows enough freedom for the site designer while at the same time keeps things orderly.

<BR>

<P>This mechanism fits into my belief system that a site should be portable&#151;the .htmld approach. If the entire site tree moves, all the resources are properly referenced locally within the tree itself. 

<BR>

<P>The first option I find too restrictive for any site that supports virtual hosts (multiple domains) such as accessLINK.

<BR>

<P>The third option is actually the one that I implement at accessLINK. I choose it because we have a tight control on our CGI and what they do. If we had users on our system, this laissez-faire approach would not even be considered.

<BR>

<P>To enable CGI in predetermined directories, all you need to do is set an option that enables the execution of CGIs on a properly named directory. Use local-cgi for the name of local cgi directories. You can accomplish this with a &lt;Directory&gt; section in your global access control file, conf/access.conf, like in following example:

<BR>

<PRE>

<FONT COLOR="#000080">&lt;Directory *.ws/local-cgi&gt;

AllowOverride None

Options ExecCGI

&lt;/Directory&gt;</FONT></PRE>

<P>This configuration will allow execution of CGIs only if they are stored in a subdirectory of a Web site wrapper called local-cgi.

<BR>

<BR>

<A NAME="E69E23"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>User CGI directories</B></FONT></CENTER></H4>

<BR>

<P>If your users have more than little technical inclination, it won't be long until you receive requests for setting up user-controlled CGI directories. This is often a source of headaches for you from a standpoint of establishing a security policy. Freedom equals problems. So the question is what do you do? If you need to give many people access and control over the CGIs they run, you've opened Pandora's box. My personal view is that as long as you are giving freedom, might as well give total freedom. Just make sure that freedom doesn't cause you other problems.

<BR>

<P>Another way of dealing with the problem, may be to provide several CGIs that can be accessed publicly within your organization. CGIs provide functionality such as e-mail, generic form support, page counters, search tools, and so on. This way you'll eliminate a great portion of the need for public CGIs.

<BR>

<P>If a user needs to implement a form, have her use your generic form wrapper. This CGI should e-mail the form information. The user could then write a program that will process the e-mail information into something useful to her.

<BR>

<P>Another alternative is to place a machine outside of your firewall that doesn't have anything but user home pages. Then you could set restrictions like the following in your global access configuration file (conf/access.conf):

<BR>

<PRE>

<FONT COLOR="#000080">&lt;Directory /usr/local/etc/httpd/public/*/user-cgi&gt;

AllowOverride None

Options ExecCGI

&lt;/Directory&gt;</FONT></PRE>

<P>Assuming that/public is your UserPath directory (using the UserPath module), users will be able to do what they want in their CGI directories. You can network mount the public directory so that it is easy for users to update and change what they want. However, in terms of access from the outside, no sensitive information would be available.

<BR>

<BR>

<A NAME="E68E28"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Summary</B></FONT></CENTER></H3>

<BR>

<P>Organizing your site will help you become more efficient at managing your Web site(s). As things get handed down from one person to another, a strong and workable framework will help maintain some sort of order, which will allow for efficient maintenance and growth.

<BR>

<P>As the number of users increases, you'll face security issues that are tough to predict in terms of the potential problems they may create. The purpose of the Internet is to disseminate information. Having a overly restrictive or loose policy creates problems. A happy medium is perhaps found on an isolated machine that has been sanitized for the function. Users can then create and maintain their own pages without much concern for security implications that may affect sensitive areas of your network.<A NAME="I4"></A>

<BR>

<P ALIGN=LEFT>

<A HREF="asg02.htm" tppabs="http://docs.rinet.ru:8080/Apachu/asg02.htm" TARGET="_self"><IMG SRC="purprev.gif" tppabs="http://docs.rinet.ru:8080/Apachu/purprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Previous Page"></A>

<A HREF="#I0" TARGET="_self"><IMG SRC="purtop.gif" tppabs="http://docs.rinet.ru:8080/Apachu/purtop.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Page Top"></A>

<A HREF="index.htm" tppabs="http://docs.rinet.ru:8080/Apachu/index.htm" TARGET="_self"><IMG SRC="purtoc.gif" tppabs="http://docs.rinet.ru:8080/Apachu/purtoc.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="TOC"></A>

<A HREF="asgpt2.htm" tppabs="http://docs.rinet.ru:8080/Apachu/asgpt2.htm" TARGET="_self"><IMG SRC="purnext.gif" tppabs="http://docs.rinet.ru:8080/Apachu/purnext.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Next Page"></A>


</BODY></HTML>