📄 ch03.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Symantec Visual Page 1.0">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<TITLE>untitled</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF">
<H2 ALIGN="CENTER"><A HREF="ch02.htm" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/ch02.htm"><IMG SRC="blanprev.gif" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/blanprev.gif" WIDTH="37" HEIGHT="37"
ALIGN="BOTTOM" BORDER="2"></A><A HREF="index-1.htm" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/index-1.htm"><IMG SRC="blantoc.gif" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/blantoc.gif" WIDTH="42"
HEIGHT="37" ALIGN="BOTTOM" BORDER="2"></A><A HREF="ch04.htm" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/ch04.htm"><IMG SRC="blannext.gif" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/blannext.gif"
WIDTH="45" HEIGHT="37" ALIGN="BOTTOM" BORDER="2"></A><FONT COLOR="#0000AA"><BR>
<BR>
3</FONT><BR>
<A NAME="Heading1"></A><FONT COLOR="#000077">Security on the Web<BR>
</FONT>
<HR>
</H2>
<UL>
<LI><A HREF="#Heading1">Security on the Web</A>
<UL>
<LI><A HREF="#Heading3">General Server Security</A>
<UL>
<LI><A HREF="#Heading5">Server Configuration Options</A>
<LI><A HREF="#Heading7">File Permissions Setup and Monitoring Changes in the System</A>
</UL>
<LI><A HREF="#Heading8">Data Security</A>
<UL>
<LI><A HREF="#Heading9">General ConsiderationsGlobal versus Local Configuration of
Permissions</A>
<LI><A HREF="#Heading10">Directory Access Configuration</A>
<LI><A HREF="#Heading11">Whos There? Configuring Client IP/Domain Restrictions</A>
<LI><A HREF="#Heading12">Another IP Restriction Mechanism: tcpwrapper</A>
<LI><A HREF="#Heading13">Whos There? User/Group Verification</A>
<LI><A HREF="#Heading14">Changing Passwords from the Web</A>
<LI><A HREF="#Heading15">Monitoring Userids</A>
</UL>
<LI><A HREF="#Heading16">CGI Security</A>
<UL>
<LI><A HREF="#Heading17">General Considerations: Dos and Donts</A><A HREF="#Heading18">:</A>
<LI><A HREF="#Heading19">Tools for Executing CGI Safely</A>
</UL>
<LI><A HREF="#Heading24">Transaction Security</A>
<UL>
<LI><A HREF="#Heading25">Simplified PGP Transactions Using the PGP Module</A>
</UL>
<LI><A HREF="#Heading27">Other Considerations</A>
<UL>
<LI><A HREF="#Heading28">Dont Run Unnecessary Daemons</A>
<LI><A HREF="#Heading29">Sharing Documents Between Serversftpd and httpd</A>
<LI><A HREF="#Heading30">Running httpd in the chroot(2) Environment</A>
<LI><A HREF="#Heading31">Privacy and Server Logs</A>
<LI><A HREF="#Heading32">Problems with Specific Servers</A>
<LI><A HREF="#Heading34">Monitoring Filesystem Changes, Network Security, and Analyzing
Password Security</A>
</UL>
<LI><A HREF="#Heading35">Further Reading</A>
</UL>
</UL>
<P>
<HR>
</P>
<UL>
<LI>General Server Security
<P>
<LI>Data Security
<P>
<LI>CGI Security
<P>
<LI>Transaction Security
<P>
<LI>Other Considerations
<P>
<LI>Further Reading
</UL>
<P>Any type of server you run at your site may introduce the potential for inappropriate
access to your site, and a Web server is no exception. This chapter will attempt
to acquaint you with some of the most common security issues that confront the Webmaster
or Web team and how to design policies and implement procedures to deal with them.</P>
<P>The first thing to consider when choosing server software to run at your site
is its origin. Some Web servers are freely available in source form. Having the source
code that comprises the server available for inspection may lend to your assurance
that it is trustworthy or reliable. At the very least, you're able to inspect the
source code and possibly make modifications to it, to make it conform to your own
policies. On the other hand, access to the source code also gives the unsavory few
the means to study the code for the purpose of cracking your system. Other servers
are proprietary, and their source code is not freely available. Precompiled servers
that run on platforms other than UNIX are the most common, but there are also precompiled
proprietary servers available for various UNIX platforms. Since neither the admin
nor anyone else can study their code, they introduce the notion known as "Security
by Obscurity," both for their inner workings and for their delivery and encryption
mechanisms. The origin of security by obscurity is to be found within the world of
cryptography, and it actually refers to certain cryptographic algorithms that rely
on the secrecy of certain components to be reliable and safe. Cryptographic techniques
used in Web service will be discussed later in this chapter. Within the realm of
programs you might decide to run on your computer, however, the notion of security
by obscurity is not necessarily a good thing for a number of reasons.
<UL>
<LI>Placing your trust in the proprietary inner workings and encryption techniques
that are components of these servers may also lead to unforeseen security holes.
</UL>
<UL>
<LI>Many UNIX sysadmins just will not run any program on their machines unless they've
compiled its code themselves or, in the hardcore case, unless the program came on
the OS distribution tape/CD as an official supported component of the OS.
</UL>
<UL>
<LI>Some servers provide more comprehensive (thus restrictive) mechanisms for enabling
security, and others provide only the standard means for implementing a security
policy. It's often the case that the freely available servers provide the most comprehensive
mechanisms for controlling and/or restricting access. On the other hand, adding complexity
to a server's internal mechanisms may also increase the likelihood for security oversights
in its design.
</UL>
<P>Whichever type of server you choose to run and architecture you choose to run
it under, you'll need to be conscientious and methodical in all of your activities
relating to the management of the server and its archive. Just because a server is
purported to be safe and reliable doesn't mean that a trained monkey can manage it.
The Webmaster should also make an effort to stay up-to-date and well informed regarding
the latest information on security problems related to the server, the archive, and
the OS the server runs under. The day-to-day activities and procedures that comprise
a sound security policy are highly dynamic in nature, due to the constant struggle
between those who would crack your system and those who discover these holes and
dispense the information necessary to close them up.
<DL>
<DT></DT>
</DL>
<H3 ALIGN="CENTER">
<HR WIDTH="82%">
<BR>
<FONT COLOR="#000077">NOTE:</FONT></H3>
<BLOCKQUOTE>
<P>One important thing you can do to prevent unwanted access and/or retrievals of
your archive's contents is to plan your archive's layout well. Chapter 14, "Archive
and Document Management," discusses this further. Good archive planning and
an established policy for the various aspects of server management and archive updating
lend to your ability to configure the server's security mechanisms on a discrete
but not overly restrictive basis. After all, too much rigor may tend to chase away
well-intentioned but perhaps slightly inexperienced browsers and/or customers.<BR>
<HR>
</BLOCKQUOTE>
<H3 ALIGN="CENTER"><A NAME="Heading3"></A><FONT COLOR="#000077">General Server Security</FONT></H3>
<P>The security mechanisms the server itself provides vary from server to server
and from architecture to architecture. Whatever server you choose to run, you should
understand security and spend the time to implement them. Especially if you're running
under a multi-user architecture like UNIX, you can easily overlook an item that may
cause a potential hole.
<DL>
<DT></DT>
</DL>
<H3 ALIGN="CENTER">
<HR WIDTH="82%">
<BR>
<FONT COLOR="#000077">NOTE:</FONT></H3>
<BLOCKQUOTE>
<P>It's the general consensus that of all the platforms on which you can run a WWW
server, the one that is least likely to cause you security problems is the Macintosh.
The fact that the Macintosh doesn't provide the capability to log in from anywhere
but the console reduces the risks involved with providing external access to its
filesystem. This also makes it a bit more difficult to manage the archive's contents
as a team, of course, but this issue can be worked around through the Macintosh's
file-sharing mechanisms. You may wish to investigate this alternative to a UNIX server.<BR>
<HR WIDTH="101%">
</BLOCKQUOTE>
<H4 ALIGN="CENTER"><A NAME="Heading5"></A><FONT COLOR="#000077">Server Configuration
Options</FONT></H4>
<P>Servers running under multi-user machines will ordinarily "run as" some
particular userid. The administrator will often create a faux userid to implement
this.
<DL>
<DT></DT>
</DL>
<H3 ALIGN="CENTER">
<HR WIDTH="82%">
<BR>
<FONT COLOR="#000077">CAUTION:</FONT></H3>
<BLOCKQUOTE>
<P>The server should never run under any administrative userid that has special permissions
on the server or, for that matter, any other user's ID. Period.<BR>
<HR WIDTH="101%">
</BLOCKQUOTE>
<P>Under UNIX, the httpd will ordinarily be started by the superuser and will then
change to the userid specified in the server's httpd.conf for each new connection.
The directive within the access.conf file to configure the server's user permissions
may look like the following if the administrator has decided to run the httpd under
the commonly used <TT>nobody</TT> userid:</P>
<PRE><FONT COLOR="#0066FF"># User/Group: The name (or #number) of the user/group to run httpd as.
User nobody
Group nobody
</FONT></PRE>
<P>It is a simple task to make this entry into the httpd.conf, but what if it ever
changes? You might want to inspect the value for this parameter once in a while to
make sure your httpd is running under the UID you want it to. This will serve as
a nice way to introduce the features of the HTTPD module and some of its capabilities.
The HTTPD::config module is available at any CPAN archive.</P>
<PRE><FONT COLOR="#0066FF">use HTTPD::Config;
$conf = `/usr/local/etc/httpd/conf';
@files = qw(httpd.conf);
$config = new HTTPD::Config (SERVER => NCSA,
SERVER_ROOT => $conf,
FILES => [@files]);
print "The current userid and group for httpd: ",
$config->user, " , ", $config->group,"\n";
</FONT></PRE>
<P>As you can see, the HTTPD module provides a method for each configurable parameter
within the httpd.conf file. Assuming that the user and group for your httpd are <TT>nobody</TT>
and <TT>nogroup</TT>, respectively, the preceding script prints the following:</P>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -