The risks are most severe from the Webmaster's perspective. The moment you install a Web server at your site, you've opened a window into your local network that the entire Internet can peer through. Most visitors are content to window shop, but a few will try to to peek at things you don't intend for public consumption. Others, not content with looking without touching, will attempt to force the window open and crawl in. The results can range from the merely embarassing, for instance the discovery one morning that your site's home page has been replaced by an obscene parody, to the damaging, for example the theft of your entire database of customer information.

It's a maxim in system security circles that buggy software opens up security holes. It's a maxim in software development circles that large, complex programs contain bugs. Unfortunately, Web servers are large, complex programs that can (and in some cases have been proven to) contain security holes. Furthermore, the open architecture of Web servers allows arbitrary CGI scripts to be executed on the server's side of the connection in response to remote requests. Any CGI script installed at your site may contain bugs, and every such bug is a potential security hole.

From the point of view of the network administrator, a Web server represents yet another potential hole in your local network's security. The general goal of network security is to keep strangers out. Yet the point of a Web site is to provide the world with controlled access to your network. Drawing the line can be difficult. A poorly configured Web server can punch a hole in the most carefully designed firewall system. A poorly configured firewall can make a Web site impossible to use. Things get particularly complicated in an intranet environment, where the Web server must typically be configured to recognize and authenticate various groups of users, each with distinct access privileges.

To the end-user, Web surfing feels both safe and anonymous. It's not. Active content, such as ActiveX controls and Java applets, introduces the possibility that Web browsing will introduce viruses or other malicious software into the user's system. Active content also has implications for the network administrator, insofar as Web browsers provide a pathway for malicious software to bypass the firewall system and enter the local area network. Even without active content, the very act of browsing leaves an electronic record of the user's surfing history, from which unscrupulous individuals can reconstruct a very accurate profile of the user's tastes and habits.

Finally, both end-users and Web administrators need to worry about the confidentiality of the data transmitted across the Web. The TCP/IP protocol was not designed with security in mind; hence it is vulnerable to network eavesdropping. When confidential documents are transmitted from the Web server to the browser, or when the end-user sends private information back to the server inside a fill-out form, someone may be listening in.

Q2: Exactly what security risks are we talking about?

1. Bugs or misconfiguration problems in the Web server that allow unauthorized remote users to:
   • Steal confidential documents not intended for their eyes.
   • Execute commands on the server host machine, allowing them to modify the system.
   • Gain information about the Web server's host machine that will allow them to break into the system.
   • Launch denial-of-service attacks, rendering the machine temporarily unusable.
2. Browser-side risks, including:
   • Active content that crashes the browser, damages the user's system, breaches the user's privacy, or merely creates an annoyance.
   • The misuse of personal information knowingly or unkowingly provided by the end-user.
3. Interception of network data sent from browser to server or vice versa via network eavesdropping. Eavesdroppers can operate from any point on the pathway between browser and server including:
   • The network on the browser's side of the connection.
   • The network on the server's side of the connection (including intranets).
   • The end-user's Internet service provider (ISP).
   • The server's ISP.
   • Either ISPs' regional access provider.

It's important to realize that "secure" browsers and servers are only designed to protect confidential information against network eavesdropping. Without system security on both browser and server sides, confidential documents are vulnerable to interception.

Protecting against network eavesdropping and system security are the subject of sections 1 to 5 of this document. Client-side security is covered in sections 6 and 7. Section 8 deals with security alerts for specific Web servers.

Q3: Are some operating systems more secure to use as platforms for Web servers than others?

The answer is yes, although the Unix and NT communities may not like to hear it. In general, the more powerful and flexible the operating system, the more open it is for attack through its Web (and other) servers.

Unix systems, with their large number of built-in servers, services, scripting languages, and interpreters, are particularly vulnerable to attack because there are simply so many portals of entry for hackers to exploit. Less capable systems, such as Macintoshes and special-purpose Web server boxes, are less easy to exploit. The safest Web site is a bare-bones Macintosh running a bare-bones Web server. See Servers, Q20 for details.

In the real world, of course, many sites will want to run a Windows NT or Unix server in order to gain the performance advantage of a multitasking operating system and the benefits of database and middleware connectivity . Security holes have been found in both Unix and Windows NT server systems, and new security holes are being found on a regular basis. On the whole Windows NT systems seem to be more vulnerable at the current time, partly the OS is relatively new and the big bugs haven't been shaken out, and partly because the NT file system and user account system are highly complex and difficult to configure correctly.

If you have configured your system correctly and are compulsive about applying your vendor's security patches promptly, a typical Unix system will be more secure than a typical NT system. However, you also have to factor in the experience of the people running the server host and software. A Unix system administered by a novice system administrator will be far less secure than an NT system set up by a seasoned Windows NT system administrator.

Q4: Are some Web server software programs more secure than others?

Version 1.3 of NCSA's Unix server contains a serious known security hole. Discovered in March of 1995, this hole allows outsiders to execute arbitrary commands on the server host. If you have a version 1.3 httpd binary whose creation date is earlier than March 1995 don't use it! Replace it with the patched 1.3 server (available at http://hoohoo.ncsa.uiuc.edu/) or with version 1.4 or higher (available at the same site). The Apache plug-in replacement for NCSA (http://www.hyperreal.com/apache/info.html) is also free of this bug.

Servers also vary in their ability to restrict browser access to individual documents or portions of the document tree. Some servers provide no restriction at all, while others allow you to restrict access to directories based on the IP address of the browser or to users who can provide the correct password. A few servers, primarily commercial ones (e.g. Netsite Commerce Server, Open Market), provide data encryption as well.

The WN server, by John Franks, deserves special mention in this regard because its design is distinctively different from other Web servers. While most servers take a permissive attitude to file distribution, allowing any document in the document root to be transferred unless it is specifically forbidden, WN takes a restrictive stance. The server will not transfer a file unless it has been explicitly placed on a list of allowed documents. On-the-fly directory listings and other "promiscuous" features are also disallowed. Information on WN's security features can be found in its online documentation at:

http://hopf.math.nwu.edu/docs/security.html

A table comparing the features of a large number of commercial, freeware and public domain servers has been put together by the WebCompare site:

http://www.webcompare.com/

Q5: Are CGI scripts insecure?

Q6: Are server-side includes insecure?

Server side includes, snippets of server directives embedded in HTML documents, are another potential hole. A subset of the directives available in server-side includes instruct the server to execute arbitrary system commands and CGI scripts. Unless the author is aware of the potential problems it's easy to introduce unintentional side effects. Unfortunately, HTML files containing dangerous server-side includes are seductively easy to write.

Some servers, including Apache and NCSA, allow the Web master to selectively disable the types of includes that can execute arbitrary commands. See Q10 for more details.

Q7: What general security precautions should I take?

• who is allowed to use the system
• when they are allowed to use it
• what they are allowed to do (different groups may be granted different levels of access)
• procedures for granting access to the system
• procedures for revoking access (e.g. when an employee leaves)
• what constitutes acceptable use of the system
• remote and local login methods
• system monitoring procedures
• protocols for responding to suspected security breaches

1. You yourself will understand what is and is not permitted on the system. If you don't have a clear picture of what is permitted, you can never be sure when a violation has occurred.
2. Others in your organization will understand what the security policy is. The written policy raises the level of security consciousness, and provides a focal point for discussion.
3. The security policy serves as a requirements document against which technical solutions can be judged. This helps guard against the "buy first, ask questions later" syndrome.
4. The policy may help bolster your legal case should you ever need to prosecute for a security violation.

For Web servers running on Unix and NT systems, here are some general security precautions to take:

1. Limit the number of login accounts available on the machine. Delete inactive users.

2. Make sure that people with login privileges choose good passwords. The Crack program will help you detect poorly-chosen passwords:

   http://www.users.dircon.co.uk/~crypto/download/c50-faq.html

3. Turn off unused services. For example, if you don't need to run FTP on the Web server host, get rid of the ftp software. Likewise for tftp, sendmail, gopher, NIS (network information services) clients, NFS (networked file system), finger, systat, and anything else that might be hanging around. Check the file /etc/inetd.conf (Unix) or Service Manager for a list of servers that may be lurking. Deactivate any that you don't use.

4. Remove shells and interpreters that you don't absolutely need. For example, if you don't run any Perl-based CGI scripts, remove the Perl interpreter.

5. Check both the system and Web logs regularly for suspicious activity. The program Tripwire (Unix), and Internet Security Scanner (Unix & NT) are helpful for detecting this type of activity:

   Tripwire

   ftp://ftp.cerias.purdue.edu/pub/tools/unix/ids/tripwire/

   Internet Security Scanner

   http://www.iss.net

   More on scanning Web logs for suspicious activity below.

6. Make sure that permissions are set correctly on system files, to discourage tampering. On Unix systems, the program COPS is useful for this:

   http://www.fish.com/cops/

   On Windows NT, give Midwestern Commerce's Administrator Assistant Toolkit a try:

   http://www.ntsecurity.com

Q8: Where can I learn more about general network security measures?

• Unix System Security: A Guide for Users and System Administrators, by David Curry
• Practical Unix Security, by Simson Garfinkel and Gene Spafford
• Windows NT Security Guide, by Stephan Sutton.
• Network Security: Private Communication in a Public World, Second Edition , by Charlie Kaufman, Radia Perlman, Mike Speciner

  A source of timely information, including the discovery of new security holes, are the CERT Coordination Center advisories, posted to the newsgroup comp.security.announce, and archived at:

  ftp://ftp.cert.org/pub/cert_advisories/

  A mailing list devoted specifically to issues of WWW security is maintained by the IETF Web Transaction Security Working Group. To subscribe, send e-mail to www-security-request@nsmx.rutgers.edu. In the body text of the message write:

  SUBSCRIBE www-security your_email_address

  A series of security FAQs is mainted by Internet Security Systems, Inc. The FAQs can be found at:

  http://www.iss.net/sec_info/addsec.html

  The main WWW FAQ also contains questions and answers relevant to Web security, such as log file management and sources of server software. The most recent version of this FAQ can be found at:

  http://www.boutell.com/faq/