The World Wide Web Security FAQ

DISCLAIMER

This information is provided by Lincoln Stein (lstein@cshl.org) and John Stewart (jns@digitalisland.net). The World Wide Web Consortium (W3C) hosts this document as a service to the Web Community; however, it does not endorse its contents. For further information, please contact Lincoln Stein or John Stewart directly.

	Up to Table of Contents
Backward to CGI Scripts		Forward to Denial of Service Attacks

5. Protecting Confidential Documents at Your Site

Q1: What types of access restrictions are available?

There are three types of access restriction available:

Restriction by IP address, subnet, or domain

Restriction by user name and password

Encryption using public key cryptography

Q2: How safe is restriction by IP address or domain name?

Restriction by IP address is secure against casual nosiness but not against a determined hacker. There are several ways around IP address restrictions. With the proper equipment and software, a hacker can "spoof" his IP address, making it seem as if he's connecting from a location different from his real one. Nor is there any guarantee that the person contacting your server from an authorized host is in fact the person you think he is. The remote host may have been broken into and is being used as a front. To be safe, IP address restriction must be combined with something that checks the identity of the user, such as a check for user name and password.

IP address restriction can be made much safer by running your server behind a firewall machine that is capable of detecting and rejecting attempts at spoofing IP addresses. Such detection works best for intercepting packets from the outside world that claim to be from trusted machines on your internal network.

One thing to be aware of is that if a browser is set to use a proxy server to fetch documents, then your server will only know about the IP address of the proxy, not the real user's. This means that if the proxy is in a trusted domain, anyone can use that proxy to access your site. Unless you know that you can trust a particular proxy to do its own restriction, don't add the IP address of a proxy (or a domain containing a proxy server) to the list of authorized addresses.

Restriction by host or domain name has the same risks as restriction by IP address, but also suffers from the risk of "DNS spoofing", an attack in which your server is temporarily fooled into thinking that a trusted host name belongs to an alien IP address. To lessen that risk, some servers can be configured to do an extra DNS lookup for each client. After translating the IP address of the incoming request to a host name, the server uses the DNS to translate from the host name back to the IP address. If the two addresses don't match, the access is forbidden. See below for instructions on enabling this feature in NCSA's httpd

Q3: How safe is restriction by user name and password?

Restriction by user name and password also has its problems. A password is only good if it's chosen carefully. Too often users choose obvious passwords like middle names, their birthday, their office phone number, or the name of a favorite pet goldfish. These passwords can be guessed at, and WWW servers, unlike Unix login programs, don't complain after repeated unsuccessful guesses. A determined hacker can employ a password guessing program to break in by brute force. You also should be alert to the possibility of remote users sharing their user names and passwords. It is more secure to use a combination of IP address restriction and password than to use either of them alone.

Another problem is that the password is vulnerable to interception as it is transmitted from browser to server. It is not encrypted in any meaningful way, so a hacker with the right hardware and software can pull it off the Internet as it passes through. Furthermore, unlike a login session, in which the password is passed over the Internet just once, a browser sends the password each and every time it fetches a protected document. This makes it easier for a hacker to intercept the transmitted data as it flows across the Internet. To avoid this, you have to encrypt the data. See below.

If you need to protect documents against _local_ users on the server's host system, you'll need to run the server as something other than "nobody" and to set the permissions of both the restricted documents and server scripts so that they're not world readable. See Q9.

Q4: What is user authentication?

User verification is any system that for determining, and verifying, the identity of a remote user. User name and password is a simple form of user authentication. Public key cryptographic systems, described below, provide a more sophisticated form authentication that uses an unforgeable electronic signature.

Q5: How do I restrict access to documents by the IP address or domain name of the remote browser?

The details are different for each server. See your server's documentation for details. For servers based on NCSA httpd, you'll need to add a directory control section to access.conf that looks something like this:

   <Directory /full/path/to/directory>


     <Limit GET POST>
       order mutual-failure
       deny from all
       allow from 192.198.2 .zoo.org
       allow from 18.157.0.5 stoat.outback.au
     </Limit>

   </Directory>

This will deny access to everybody but the indicated hosts (18.157.0.5 and stoat.outback.au), subnets (182.198.2) and domains (.zoo.org). Although you can use either numeric IP addresses or host names, it's safer to use the numeric form because this form of identification is less easily subverted (Q1).

One way to increase the security of restriction by domain name is to make sure that your server double-checks the results of its DNS lookups. You can enable this feature in NCSA's httpd (and the related Apache server) by making sure that the -DMAXIMUM_DNS flag is set in the Makefile.

For the CERN server, you'll need to declare a protection scheme with the Protection directive, and associate it with a local URL using the Protect directive. An entry in httpd.conf that limits access to certain domains might look like this:

   Protection LOCAL-USERS {

     GetMask @(*.capricorn.com, *.zoo.org, 18.157.0.5)
   }

   Protect /relative/path/to/directory/* LOCAL-USERS

Q6: How do I add new users and passwords?

Unix-based servers use password and group files similar to the like-named Unix files. Although the format of these files are similar enough to allow you to use the Unix versions for the Web server, this isn't a good idea. You don't want to give a hacker who's guessed a Web password carte blanche to log into the Unix host.

Check your server documentation for the precise details of how to add new users. For NCSA httpd, you can add a new user to the password file using the htpasswd program that comes with the server software:

   htpasswd /path/to/password/file username

htpasswd will then prompt you for the password to use. The first time you invoke htpasswd you must provide a -c flag to create the password file from scratch.

The CERN server comes with a slightly different program called htadm:

   htadm -adduser /path/to/password/file username

htadm will then prompt you for the new password.

After you add all the authorized users, you can attach password protection to the directories of your choice. In NCSA httpd and its derivatives, add something like this to access.conf:

   <Directory /full/path/to/protected/directory>

     AuthName          name.of.your.server
     AuthType          Basic
     AuthUserFile      /usr/local/etc/httpd/conf/passwd
     <Limit GET POST>
       require valid-user
     </Limit>

</Directory>

You'll need to replace AuthUserFile with the full path to the password file. This type of protection can be combined with IP address restriction as described in the previous section. See NCSA's online documentation (http://hoohoo.ncsa.uiuc.edu/) or the author's book (How to Set Up and Maintain a Web Site) for more details.

For the CERN server, the corresponding entry in httpd.conf looks like this:

   Protection AUTHORIZED-USERS {
     AuthType     Basic
     ServerID     name.of.your.server
     PasswordFile /usr/local/etc/httpd/conf/passwd
     GetMask      All
}
Protect /relative/path/to/directory/* AUTHORIZED-USERS

Again, see the documentation or the author's book for details.

Q7: Is there a CGI script to allow users to change their passwords online?

There are several floating around. The one I use is a Perl script that I wrote myself, user_manage. It works with the password and group files used by the Apache, NCSA httpd, CERN and Netscape Unix servers, and probably other Unix-based servers. Users can use it to safely change their own passwords, and Web administrators can use it to add new users, manipulate groups, and edit the privileges of existing users. You can find this script at

http://stein.cshl.org/~lstein/user_manage/

Bill Jones has written a multi-purpose script called WebPass. In addition to allowing users to change their Web passwords, they can also change their POP, log-in and news passwords, if they have them. It uses a combination of Perl and Expect to do its magic. You can find it at:

http://webmaster.fccj.cc.fl.us/Webmaster/WebPass.html

Several vendors of commercial Web servers also offer remote user administration scripts. See your server documentation for details.

Q8: Using per-directory access control files to control access to directories is so convenient, why should I use access.conf?

Instead of placing directory access restrictions directives in centralized configuration files, most servers give you the ability to control access by putting a "hidden" file in the directory you want to restrict access to (this file is called ".htaccess" in NCSA-derived servers and ".www_acl" in the CERN server). It is very convenient to use these files since you can adjust the restrictions on a directory without having to edit the central access control file. There are several problems with relying on .htaccess files too heavily. One is that with access control files scattered all over the document hierarchy, there is no central place where the access policy for the site is clearly set out. Another problem is that it is easy for these files to get modified or overwritten inadvertently, opening up a section of the document tree to the public. Finally, there is a bug in many servers (including the NCSA server) that allows the access control files to be fetched just like any other file using a URL such as:

   http://your.site.com/protected/directory/.htaccess

This is clearly an undesirable feature since it gives out important information about your system, including the location of the server password file.

Another problem with the the per-directory access files is that if you ever need to change the server software, it's a lot easier to update a single central access control file than to search and fix a hundred small files.

Q9: How does encryption work?

Encryption works by encoding the text of a message with a key. In traditional encryption systems, the same key was used for both encoding and decoding. In the new public key or asymmetric encryption systems, keys come in pairs: one key is used for encoding and another for decoding. In this system everyone owns a unique pair of keys. One of the keys, called the public key, is widely distributed and used for encoding messages. The other key, called the private key, is a closely held secret used to decrypt incoming message. Under this system, a person who needs to send a message to a second person can encrypt the message with that person's public key. The message can only be decrypted by the owner of the secret private key, making it safe from interception. This system can also be used to create unforgeable digital signatures.

Most practical implementations of secure Internet encryption actually combine the traditional symmetric and the new asymmetric schemes. Public key encryption is used to negotiate a secret symmetric key that is then used to encrypt the actual data.

Since commercial ventures have a critical need for secure transmission on the Web, there is very active interest in developing schemes for encrypting the data that passes between browser and server.

More information on public key cryptography can be found in the book "Applied Cryptography", by Bruce Schneier.

Q10: What are: SSL, SHTTP, Shen?

These are all proposed encryption and user authentication standards for the Web. Each requires the right combination of compatible browser and server to operate, so none is yet the universal solution to the secure data transmission problem.

SSL (Secure Socket Layer) is the scheme proposed by Netscape Communications Corporation. It is a low level encryption scheme used to encrypt transactions in higher-level protocols such as HTTP, NNTP and FTP. The SSL protocol includes provisions for server authentication (verifying the server's identity to the client), encryption of data in transit, and optional client authentication (verifying the client's identity to the server). SSL is currently implemented commercially on several different browsers, including Netscape Navigator, Secure Mosaic, and Microsoft Internet Explorer, and many different servers, including ones from Netscape, Microsoft, IBM, Quarterdeck, OpenMarket and O'Reilly and Associates. Details on SSL can be found at:

http://home.netscape.com/products/security/ssl/index.html

SHTTP (Secure HTTP) is the scheme proposed by CommerceNet, a coalition of businesses interested in developing the Internet for commercial uses. It is a higher level protocol that only works with the HTTP protocol, but is potentially more extensible than SSL. Currently SHTTP is implemented for the Open Marketplace Server marketed by Open Market, Inc on the server side, and Secure HTTP Mosaic by Enterprise Integration Technologies on the client side. See here for details:

http://www.eit.com/creations/s-http/

Shen is scheme proposed by Phillip Hallam-Baker of CERN. Like SHTTP it is a high level replacement for the existing HTTP protocol. Although it has existed as a proposal for nearly two years, no browser or server vendor has implemented it. Further, the URL that described it is no longer available, so for all intents and purposes it can be considered moribund.

Q11: Are there any "freeware" secure servers?

There is a freeware implementation of SSL, known as SSLeay. This implementation comes as C source code that can be linked into such applications as Telnet and FTP. Among the supported applications are the freely redistributable Unix Web servers Apache and NCSA httpd, and several Unix-based Web browsers, including Mosaic. Outside United States borders this package can be used free of charge in both commercial and non-commercial applications. Within the United States, however, you will need to pay a licensing fee to RSA Data Security in order to use SSL for commercial applications (it might be easier to obtain one of the commercial versions of Apache-SSL, which provide the license as part of the purchase price).

There are several components to this software. You will need to obtain and install them all in order to have a working SSL-based Web server:

The SSLeay FAQ: http://www.psy.uq.oz.au/~ftp/Crypto/. You'll need to read this carefully.
SSLeay: This is the SSL library itself. It can be obtained via FTP at ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/
Patches to various internet applications: These are source code patches to telnet, ftp, Mosaic, and the like to take advantage of SSL. They can be found via FTP at ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps/.
Patches for the Apache server: Currently there are patches for the Apache 0.8.14h and 1.0.1a servers. The patches may work with other versions as well, but are not guaranteed. ftp://ftp.ox.ac.uk/pub/crypto/SSL/
The Apache server source code: http://www.apache.org

You can obtain precompiled versions of Apache-SSL from two sources. Within the United States you can obtain Stronghold from C2Net Software, Inc.. Outside the United States boundaries, you can obtain Stronghold fromhttp://stronghold.ukweb.com/. This version of Apache is available at a discount for non-profit organizations and educational institutions.

After installing an SSL-enabled server you will need to obtain a server certificate from a certifying authority. Server certificates are available from a number of different companies, each with a slightly different application procedure and fee schedule. In the United States, the VeriSign Corporation was the first and still most widely used certifying authority. Because of a recent fee increase ($495 for a commercial server certificate), however, VeriSign is currently one of the more expensive agencies. A good alternative to VeriSign is Thawte Consulting; its fees are significantly lower and its application procedure for non-American organization is far less of a hassle. Other certifying authorities include:

Entrust: http://www.entrust.com/
GTE CyberTrust: http://www.cybertrust.gte.com/
EuroSign: http://eurosign.com
COST: http://www.cost.se
BiNARY SuRGEONS: http://www.surgeons.co.za/certificate.html
Keywitness: http://www.keywitness.ca
SoftForum: http://www.softforum.co.kr/
CompuSource: http://www.compusource.co.za/

Before obtaining a server certificate from one of these CA's, be sure to confirm that the certificate will be recognized by the browsers you wish to support. VeriSign and Thawte and recognized by recent versions of both the Netscape and Microsoft browsers. Others are less likely to be recognized. To see a list of certificates honored by the browser, choose Options-<Security Preferences->Site Certificates in Netscape Navigator, or View->Options->Security->Sites in Internet Explorer. The information is available in Netscape Communicator by pressing the Security button in the toolbar.

The process of obtaining a server certificate is slightly different from CA to CA, but follows the same basic outline. After choosing a certifying authority, connect to its Web site and find the server certificate application section. From here locate the appropriate application form for your server software, and fill it out. You'll be asked to provide your Web site's domain name, company name, and contact information. You'll also be asked to provide documentation, such as a Dun and Bradstreet number, articles of incorporation, or a notarized letter from the bursar of your college to prove the identity of your organization. You'll also be asked to provide payment information, such as a credit card number.

The application form is only half of the process. You'll also need to generate an electronic certificate request. After submitting the application form to the CA, you'll use a program provided with your server software to generate a public/private key pair. In the Apache-SSL distributions, the program is calledgenkey.

After generating the key pair, the key generation software will create a file containing the key request. In some cases it will automatically mail the file to the CA. In other cases, it will ask you to manually mail the file to the CA. In either case there will now be a wait of days to weeks while the CA confirms the validity of your request. Eventually you will receive a signed certificate by return e-mail. You then complete the process by installing the signed certificate on your server. The details again vary from server to server. For Apache-SSL you'll use a program called getca.

At this point users will be able to retrieve documents from your server and to submit forms without fear of interception. Your server's certificate provides remote users with proof of your server's identity.

Q12: Can I use Personal Certificates to Control Server Access?

SSL can also be used to verify the users' identity to the server, providing more reliable authentication than the common password-based authentication schemes. To take advantage of this system each user will have to obtain a "personal certificate" from a CA.

Users can obtain inexpensive personal certificates from VeriSign. VeriSign offers two classes of certificate. Class 1 certificates cost a mere $9.95 yearly, but provide no assurance that the user is who he or she claims to be because VeriSign performs no validation of the information submitted by the user on the application form. At most, class 1 certificates certify that the user can receive e-mail at the address provided in the application. Class 2 certificates, available for $19.95 yearly, provide a greater level of assurance. In order to obtain such a certificate, the user must provide personal identifying information that is validated by a credit bureau.

If you are running an intranet, you may wish to issue personal certificates yourself, in order to provide fine-grained access control to employees of your organization. To do this, you will need to obtain and install a certificate server. Such systems are available from Microsoft, Netscape, XCert, Entrust and GTE.

To use personal certificates for access control, your server will need to be specially configured. The mechanics of setting this up are beyond the scope of this document, but detailed directions can be found in the author's book, Web Security: A Step-by-Step Reference Guide.

Q13: How do I accept credit card orders over the Web?

You can always instruct users to call your 800 number :-). Seriously, though, you _shouldn't_ ask remote users to submit their credit card number in a fill-out form field unless you are using an encrypting server/browser combination. Your alternate is to use one of the credit card proxy systems described in the next section.

Even with an encrypting server, you should be careful about what happens to the credit card number after it's received by the server. For example, if the number is received by a server script, make sure not to write it out to a world-readable log file or send it via e-mail to a remote site.

Q14: What are: CyberCash, SET, OpenMarket?

These are all schemes that have been developed to process commercial transactions over the Web without compromising credit card numbers or other confidential information.

CyberCash

CyberCash, a product of the CyberCash Corporation, uses specialized software on the merchant and customer's sides of the connections to provide for secure payments across the Internet. CyberCash supports both credit cards and electronic checks. The credit card service enables online stores and Internet billers to accept credit card payments for goods or services and the "PayNow" service enables Internet billers to accept electronic check payments for bills presented on the Internet. For a consumer or business to make CyberCash payments, they submit credit card or checking account information via an SSL-enabled form provided by the merchant. Alternatively, the consumer may use an InstaBuy Wallet to simplify the purchasing process. InstaBuy saves user credit card information (electronic checks are not yet supported), in 128-bit encrypted form, on the InstaBuy servers.

When a user goes to purchase an item from a CyberCash enrolled merchant, the user fills out a traditional payment form to be submitted via SSL, or, if the merchant also supports InstaBuy, clicks on the InstaBuy icon to to set up or use a Wallet. CyberCash merchants may choose whether or not to implement InstaBuy, which is a new service owned by CyberCash. Payment information is then sent to the merchant's web server which packages the transaction for forwarding to the CyberCash Gateway servers, which are linked to financial institutions. CyberCash, in contrast to the associations created by its name, is really a back-end payment system, transparent to the user, which merchants use for payment processing.

An advantage of CyberCash is its use of triple-DES encryption when transmitting payment information. Also, because payments are processed entirely by CyberCash, there is really no need for merchants to record credit card or checking account information in a database or other static memory location. This lessens the merchant's risk that financial information can be stolen by individuals who have broken into the merchant's computer system. The onus is on CyberCash to handle all security concerns.

For merchants to accept CyberCash payments they must first establish a credit card merchant account with an acquiring financial institution. More than 95 percent of the acquiring financial institutions in the United States are CyberCash-enabled. Fees to open merchant accounts vary, as they are set by the regional banks themselves. A typical scenario would include: a one-time fee of approximately $100 to create the account, a monthly fee of approximately $15 to keep the account open, and a transaction fee of 2-3% of the purchase price of each transaction. In addition to fees charged by the acquiring financial institution, CyberCash says that merchants should expect to pay (to CyberCash) a one-time service setup fee ($500 to $1,000), and monthly service fees typically comprised of a service access fee (usually $40 - $80) and transaction charges based on volume (usually $0.20 to $0.60 per transaction).

After setting up a merchant bank account, the merchant must install software called the "Merchant Connection Kit" (MCK) on their Web server. This software is launched when the user presses the "pay" button in a shopping cart script (or equivalent), and forwards the transaction to the "CashRegister" service running on the CyberCash servers. The MCK is downloadable free of charge and available for many platforms, including Windows NT and Unix. It requires only 100k of hard disk space, and consists of encryption and communication libraries, HTML templates, and CGI scripts for handling payments at your online store.

The MCK's job is to transmit all payment information to the CyberCash Gateway servers, which are responsible for executing the transaction. These are payment servers which communicate with financial institutions in such a way that, to the financial institution, the transactions look like standard point of sale events, not internet transactions.

CyberCash also offers an "Administrative Interface", which is a web site that enables you to perform administrative tasks such as querying for transactions, getting daily transaction totals, or refunding money for returned items.

The main advantage of CyberCash is that it provides the merchant with a fully functional, externally managed payment processing system. The merchant need only set up a merchant account and configure the MCK to get started. Disadvantages include the risk of centralizing so much financial information on one server system (CyberCash), and the accompanying dependence on the CyberCash servers' performance and throughput characteristics. In addition, the fees charged to merchants for processing credit card transactions make CyberCash impractical for small purchases, such as "pay per play" on-line video games.

More information on CyberCash is available at: http://www.cybercash.com

SET

SET, or Secure Electronic Transaction protocol, is an open standard for processing of credit card transactions over the Internet created jointly by Netscape, Microsoft, Visa and Mastercard. The main justification for SET is interoperability. By adhering to the standard, one vendor's software will be interoperable with any other vendor's software.

To address the high potential for fraud on the Internet, the SET standard uses a complex system of certifying authorities to vouch for the identify of every party in the transaction: customer, merchant, card-issuer and merchant's bank are all identified by signed, unforgeable certificates. To address privacy concerns, the transaction is separated in such a way that the merchant has access to information about what is being purchased, how much it costs, and whether the payment is approved, but no information on what payment method the customer is using. Similarly, the card-issuer has access to the purchase price, but no information on the type of merchandise involved. Despite these precautions, however, SET does not provide complete anonymity to the consumer.

SET requires specialized software on both the customer's and merchant's side of the connection. Cardholders shopping on SET-compliant sites who want to take advantage of secure SET processing must have a SET compliant wallet, available from SET merchants or financial institutions. Some merchants may also require that the cardholder have a SET Certificate. The main advantages of SET to the consumer are security guaranteed by digital certificates, and the ability to utilize the same wallet, theoretically, on any SET-compliant site.

Merchant's who wish to become a SET online merchant site need to build or purchase a SET-compliant merchant server product. The SET website provides a Vendor Status Matrix with information about purchasing and installing merchant server applications. Merchants then need to contact their financial institution to obtain a digital certificate.

Microsoft offers Site Server Commerce Edition, a superset of the Microsoft Site Server server product, which is itself a superset of Internet Information Server. Site Server Commerce Edition supports real-time credit authorization with SET. It also includes all of Site Server's features for dynamically publishing content, searching content and the delivery of content in multiple formats. For more information on Site Server Commerce, go to http://www.microsoft.com/siteserver/commerce/default.htm.

For its part, the iPlanet.com collaboration of Netscape Corporation and Sun Microsystems, offers MerchantXPert which provides catalog management, order management, membership services, and payment services. While Netscape's earlier e-commerce merchant server product, LivePayment, was moving in the direction of full SET compliance, the new offering from the Alliance is not SET-compliant and does not appear to be headed in that direction.

For more information on SET, see the Secure Electronic Transaction LLC website. They are responsible for the ongoing management of the SET specification.

Open Market Web Commerce System

Open Market, Inc., also offers an online commerce system. In the Open Market scheme, a back-end transaction system and a front-end catalog interface to create an end to end e-commerce solution. The back-end system, known as Transact, provides core business functions such as order fulfillment, billing and connections to payment services. LiveCommerce, the front-end system, provides the storage, manipulation and presentation of the product catalog. Open Market's prices reflect the fact that the products are geared mainly to large corporations, banks, and service providers who wish to present large catalogs or set up multiple independent e-commerce storefronts. More information is available from Open Market at http://www.openmarket.com.

	Up to Table of Contents
Backward to CGI Scripts		Forward to Denial of Service Attacks

Lincoln D. Stein (lstein@cshl.org) and John N. Stewart (jns@digitalisland.net)

$Id: wwwsf5.html,v 1.6 2001/07/28 17:54:26 lstein Exp $