Web Security in a Nutshell

In the book Practical UNIX & Internet Security, we gave a simple definition of computer security: A computer is secure if you can depend on it and its software to behave as you expect.

Using this definition, web security is a set of procedures, practices, and technologies for protecting web servers, web users, and their surrounding organizations. Security protects you against unexpected behavior.

Why should web security require special attention apart from the general subject of computer and Internet security? Because the Web is changing many of the assumptions that people have historically made about computer security and publishing:

• The Internet is a two-way network. As the Internet makes it possible for web servers to publish information to millions of users, it also makes it possible for computer hackers, crackers, criminals, vandals, and other "bad guys" to break into the very computers on which the web servers are running. Those risks don't exist in most other publishing environments, such as newspapers, magazines, or even "electronic" publishing systems involving teletext, voice-response, and fax-back.
• The World Wide Web is increasingly being used by corporations and governments to distribute important information and conduct business transactions. Reputations can be damaged and money can be lost if web servers are subverted.
• Although the Web is easy to use, web servers and browsers are exceedingly complicated pieces of software, with many potential security flaws. Many times in the past, new features have been added without proper attention being paid to their security impact. Thus, properly installed software may still pose security threats.
• Once subverted, web browsers and servers can be used by attackers as a launching point for conducting further attacks against users and organizations.
• Unsophisticated users will be (and are) common users of WWW-based services. The current generation of software calls upon users to make security-relevant decisions on a daily basis, yet users are not given enough information to make informed choices.
• It is considerably more expensive and more time-consuming to recover from a security incident than to take preventative measures ahead of time.

Why Worry about Web Security?

The World Wide Web is the fastest growing part of the Internet. Increasingly, it is also the part of the Internet that is most vulnerable to attack.

Web servers make an attractive target for attackers for many reasons:

The Web Security Problem

The web security problem consists of three major parts:

• Securing the web server and the data that is on it. You need to be sure that the server can continue its operation, the information on the server is not modified without authorization, and the information is only distributed to those individuals to whom you want it to be distributed.
• Securing information that travels between the web server and the user. You would like to assure that information the user supplies to the web server (usernames, passwords, financial information, etc.) cannot be read, modified, or destroyed by others. Many network technologies are especially susceptible to eavesdropping, because information is broadcast to every computer that is on the local area network.
• Securing the user's own computer. You would like to have a way of assuring users that information, data, or programs downloaded to their systems will not cause damage--otherwise, they will be reluctant to use the service. You would also like to have a way of assuring that information downloaded is controlled thereafter, in accordance with the user's license agreement and/or copyright.

Along with all of these considerations, we may also have other requirements. For instance, in some cases, we have the challenges of:

• Verifying the identity of the user to the server
• Verifying the identity of the server to the user
• Ensuring that messages get passed between client and server in a timely fashion, reliably, and without replay
• Logging and auditing information about the transaction for purposes of billing, conflict resolution, "nonrepudiation," and investigation of misuse
• Balancing the load among multiple servers

To properly address these concerns requires the interaction of several of our three main components, along with the underlying network and OS fabric.

Securing the Web Server

Securing the web server is a two-part proposition. First, the computer itself must be secured using traditional computer security techniques. These techniques assure that authorized users of the system have the capabilities to do their own work and only those capabilities. Thus, we may want to authorize anonymous users to read the contents of our main web page, but we do not want them to have the ability to shut down the computer or alter the system accounting files. These traditional techniques also assure that people on the Internet who are not authorized users of the system cannot break into it and gain control. Chapter 13, Host and Site Security, presents an overview of several generic techniques; the references in Appendix E, References, contain many more.

Server security is complicated when a computer is used both as a traditional time-sharing computer and as a web server. This is because the web server can be used to exploit bugs in the host security, and failings in host security can be used to probe for problems with the web server. For example, a poorly written CGI script may make it possible to change a web server's configuration file, which can then be modified so that the web server runs with excess privileges. By using a host security flaw, an attacker could then create a privileged CGI script that would lead to granting the attacker full access to the entire computer system. Thus, one of the best strategies for improving a web server's security is to minimize the number of services provided by the host on which the web server is running. If you need to provide both a mail server and a web server, your best bet is to put them on different computers.

Another good strategy for securing the information on the web server is to restrict access to the web server. The server should be located in a secure facility, so that unauthorized people do not have physical access to the equipment. You should limit the number of users who have the ability to log into the computer. The server should be used only for your single application: otherwise, people who have access to the server might obtain access to your information. And you should make sure that people who access the server for administrative purposes do so using secure means such as Kerberized Telnet, SecureID, S/Key, or ssh.

Securing Information in Transit

Much of the attention that has been paid to web security has involved the problem of protecting information from unauthorized interception as it travels over the Internet.

There are many ways to protect information from eavesdropping as it travels through a network:

• Physically secure the network, so that eavesdropping is impossible.
• Hide the information that you wish to secure within information that appears innocuous.
• Encrypt the information so that it cannot be decoded by any party who is not in possession of the proper key.

Of these techniques, encryption is the only one that is practical. Physically securing the Internet is impossible. Information hiding only works if the people you are hiding it from do not know how it is hidden.

One of Netscape Communication's early innovations was its Secure Socket Layer (SSL), a system for automatically encrypting information as it is sent over the Internet and decrypting it before it is used.

SSL is an important part of web security, but it is only one component. Ironically, even though SSL was originally developed to allow the transmission of information such as credit card numbers over the Internet, new protocols may allow those kinds of financially oriented transmissions to be conducted more simply and more securely. Meanwhile, technologies such as digital certificates are eliminating the need to use SSL's cryptographic channel for sending usernames and passwords. The real promise of SSL, then, may be for providing secure administrative access to web servers and for allowing businesses to transmit proprietary information over public networks.

Current implementations of SSL in the U.S. provide two levels of security: export-grade and domestic. These two levels are a direct result of U.S. government restrictions on the export of cryptographic technology. Export-grade security protects data against casual eavesdropping, but cannot resist a determined attack. For instance, a relative novice with a single Pentium computer can forcibly decrypt an export-grade SSL message in less than one year2 using a brute force search (trying every possible encryption key). Domestic-grade security is much stronger: for practical purposes, messages encrypted with SSL's typical domestic-grade encryption should resist brute force attempts at decryption for at least 10 years, and should possibly be secure for 30 years or longer.3 Unfortunately, most versions of Netscape Navigator in circulation provide only for export-grade security, not domestic.

Another risk to information in transit is a denial-of-service attack resulting from a disruption in the network. A denial of service can result from a physical event, such as a fiber cut, or a logical event, such as a bug in the Internet routing tables. Or it can result from a sustained attack against your servers from attackers on the Internet: the attacker might try bombarding your web server with thousands of requests every second, preventing legitimate requests from getting through.

Today there is no practical way to defend against denial-of-service attacks (described further in Chapter 3, Java and JavaScript), although redundancy and backup systems can help to minimize their impact. Ultimately, it will take effective use of the legal system to pursue and prosecute attackers to make these attacks less frequent.

Securing the User's Computer

Security flaws in web browsers have been front-page news. Magazines print horror stories of people who downloaded computer viruses and other rogue programs from the Internet. As a result of these accounts in the media, users are increasingly cautious of the Web.

Caution should increase in coming years as web-based computers are increasingly used for financial transactions. Attacks are already starting to appear. As this book went to press, the Chaos Computer Club demonstrated an ActiveX component written in Visual Basic that could initiate electronic funds transfers using Quicken. In another story, a U.S. court served a restraining order against a web site that gave users access to "free" pornography, provided that the user download and run a special "viewer." Unknown to the user, the viewer program disconnected the user's computer from the user's local Internet service provider and placed a long-distance phone call to Eastern Europe. It is not difficult to imagine a computer virus that remains dormant until a user types in the password to unlock an electronic wallet, then silently copies the user's credit card numbers and payment information over the Internet to an undisclosed location.

Although simple HTML and image files by themselves pose no direct threat to users (beyond the legal problems that might arise from the content of the files), they also limit the possibilities for interaction in the web-based experience. That's why companies developing web technology are promoting technologies such as JavaScript, Java, ActiveX, and plug-in technology. These programming languages and environments give developers a way to bring web pages "alive" and create new kinds of applications that aren't possible with simple HTML forms.

The added power of these active systems has also created added dangers. Following their introduction, there were repeated security problems publicized with JavaScript, Java, and ActiveX. We expect that these technologies will increasingly be looked at with suspicion as time goes on. The same is true of plug-ins for Netscape Navigator.

Web developers also wish to be protected from users. Companies putting pay-per-view information on a web site would like to prevent users from downloading this information and sharing it with others who have not paid for the service. Many web sites that provide information freely to the public would prefer that users pick up the data directly, so that the sites can track downloads, gain additional information about their readers, and possibly charge their advertisers more money.

It is impossible to impose technical solutions that limit the spread of information once it has been provided to the user. If the data is viewed on the user's screen, that information can simply be copied off the screen and either printed or saved in a file. Although a number of "copy protection" systems for web data have been proposed (and marketed), they can all be subverted. About the best method available for some forms of binary data is " digital watermarking." This involves making very small, hidden alterations to the data to store a form of identification of the material. The alterations can't be noticed by the user, and are done in a special fashion to defeat attempts to remove them. Images, sound files, and other watermarked data can be examined with programs that find and display the identifying information, showing the true owner and possibly the name of the person for whom the copy was first produced.

Credit Cards, Encryption, and the Web

Protecting credit card numbers used in online transactions is the most often-cited example of the need for web security. So let's look at the typical credit card transactions, observe what the risks are, and see how web security makes a difference.

A Typical Transaction

Consider a typical transaction on the Web: buying a CD from an online music store with your credit card (Figure 1-1).

Buying a CD with your credit card over the Internet

In this example, a teenager--call her Sonia--sits down at her dad's computer, finds a music store on the World Wide Web, and browses the company's catalog. Sonia finds a rare compact disc that she has been looking for desperately--say, a collection of Led Zeppelin songs as performed by Tiny Tim. She creates an order with the store's electronic shopping cart, types in her name and shipping address, types in her dad's credit card number, and clicks an onscreen button in her web browser display labeled BUY-IT. Sonia's CD arrives in the mail soon thereafter. A month later, her dad gets the credit card bill in the mail. He and Sonia then have a little discussion about her allowance and the fact that she isn't doing enough chores around the house.

Both the credit card holder (Sonia's dad) and the merchant face risks in this transaction. For the credit card holder, two risks are obvious and well-publicized:

• The credit card number might be "sniffed" by some electronic villain as it travels across the Internet. That person could then use the credit card number to commit fraud. To make things worse, the credit card holder might not realize the card's number has been stolen until the statement is received. By that point, the card's credit limit has probably been maxed out with many thousands of dollars in fraudulent charges. Let's hope this doesn't happen while Dad is on a business trip.
• The credit card might get billed, but the CD might never show up. When Sonia tries to investigate, she finds that there is no electronic CD store: the whole thing was a scam, and Sonia has lost her dad's money. The company that billed the credit card doesn't even exist anymore.

It's these two risks that Netscape's SSL was designed to combat. SSL uses encryption, a mathematical technique for scrambling information, so that data sent between Sonia's web browser and the online music store can't be surreptitiously monitored while it is in transit (see How SSL protects an online transaction ). SSL also supports a sophisticated system for digital identification, so that Sonia has some assurance that the people operating the online music store are really who they claim to be. (Encryption is described in Chapter 10, Cryptography Basics, and digital IDs are described in Chapter 6, Digital Identification Techniques.)

 

How SSL protects an online transaction

True Names Cybercash's Carl Ellison notes that it is becoming less and less useful to know the "true name" of a particular business or web site operator. "In very old days (from stone age communities up through Walton's Mountain), people and things had only one name for a lifetime, your world would contain few enough people and things that you could remember and recall all their names, your correspondents would be from your world, and you two would share the same name space. In a world like that, names meant something. With the `global village,' especially thanks to the Internet, the number of objects and people I correspond with are less and less from my personal world. . . . What Sonia cares about (quality of service, honesty, skill, size, lifetime...) is something she might have learned in ancient days by other channels and have tied to the true name--but today she doesn't have those other channels of information and because of the size of the name space, she's not likely to be able to tie anything to such a name and hold that information in her head. Today, entities change names rapidly (a good hotel I've stayed at has changed names twice in the last two years), and entities have multiple names. The assumptions upon which we humans built a reliance on names are breaking down, and we haven't replaced the use of names yet." In fact, Ellison continues, Sonia doesn't really care who these people claim to be. "She cares if they're honest and if they're likely to be around long enough to ship her order. The name of someone remote probably doesn't mean anything to her...What she needs is certification of a keyholder's honesty, competence, etc. We're just now designing certificates to carry that information."

SSL does a good job of protecting information while the data is in transit and giving web users good assurances that they are communicating with the sites they think they are. Programs that implement the SSL protocol come in two versions: a reduced-strength version that is sold by U.S. corporations overseas, and a full-strength version sold by foreign companies overseas as well as by U.S. companies for use within the United States. But even though a lot of fuss has been made because the reduced-strength version of the SSL program isn't all that secure, it is still probably good enough for encrypting most credit card transactions.4

Nevertheless, it's ironic that SSL was first proposed as a safe way for sending credit card numbers over the Internet, because it wasn't needed for this purpose. Here's why:

• According to the laws that govern the use of credit cards in the United States, consumers are only liable for the first $50 of fraudulent credit card transactions. In most cases, credit card companies don't even enforce the $50 limit--consumers who report fraudulent charges can simply alert their banks and not pay. So there really isn't any risk to consumers in having their credit card numbers "sniffed" over the Internet.5
• If Sonia were billed for a CD and it never showed up, all her dad would have to do is write his credit card company to contest the charge.6
• There is no need for consumers to verify the identity of merchants that accept credit cards, because the banks that issue merchants their credit card accounts have already done this for the consumer. Merchants can't charge your credit card unless they first obtain a credit card merchant account, which involves an extensive application procedure, a background check, and usually an onsite visit. Indeed, credit card firms do a far better job of this verification than Sonia could ever hope to do by herself.

The idea that SSL could secure credit card transactions was an important part of selling Internet commerce--and specifically Netscape's products--to consumers. The message was simple and effective: "Don't do business with companies that don't have secure (i.e., Netscape) web servers." But the message was too effective: many Internet users, including some journalists, were so intimidated by the idea of having their credit card information stolen on the Internet that they refused to do business with merchants that had cryptographic web servers as well.

Ironically, the people who were really protected by Netscape's technology weren't the consumers, but banks and merchants. That's because they are the ones who are ultimately responsible for credit card fraud. If a credit card merchant gets a credit card approved and ships out a CD, the bank is obligated to pay the merchant for the charge, even if the credit card is reported stolen later that day. The encryption also protects merchants: if a credit card number is stolen because of a merchant's negligence, then the merchant can be held liable by the bank for any fraud committed on the card. (Credit card companies have since stated that merchants are indeed responsible for any fraud that results from credit card numbers that are stolen if a merchant didn't use a cryptographically enabled web server. Nevertheless, at this point there has been no publicly reported example of a credit card number being "sniffed" over a network connection, encrypted or not.)

The American Bankers Association maintains that it's in the interest of consumers to protect banks and merchants from fraud. After all, fraud cuts into the profits of banks, forcing them to raise interest rates and making it harder for them to offer new services. Dealing with fraud can also be very difficult for some consumers. Some people panic when faced with a credit card bill that contains thousands of dollars in fraudulent charges. Others simply ignore it. Unfortunately, they do so at their peril: after a period of time (depending on the financial institution), consumers become liable for fraudulent charges that are not contested.

New Lessons from the Credit Card Example

It turns out that both Sonia and the merchant face many other risks when doing business over the Internet--risks that encryption really does not protect against. For Sonia, these risks include:

• The risk that the information she provides for this transaction will be used against her at some time in the future. For instance, personal information may be obtained by a con artist and used to gain Sonia's trust. Or the address that she gives may end up on a mailing list and used to bombard Sonia with unwanted physical or electronic mail.
• The risk that the merchant may experiment with Sonia's sensitivity to price or determine the other stores at which Sonia is shopping, allowing the merchant to selectively raise the prices that are offered to Sonia so that they will be as high as she is willing (or able) to pay--and definitely higher than the prices that are charged the "average" consumer.
• The risk that the merchant might somehow take over Sonia's web browser and use it to surreptitiously glean information from her computer about her tastes and desires.
• The risk that a rogue computer programmer might figure out a way to gain control of Sonia's web browser. That browser could then be used to reformat Sonia's hard disk. Even worse: the rogue program might download a piece of software that scans Sonia's computer for sensitive information (bank account numbers, credit card numbers, access codes, Social Security Numbers, and so on) and then silently upload that information to other sites on the Internet for future exploitation.

Likewise, the merchant faces real risks as well:

• Sonia might try to click into the merchant's web site and find it down or terribly sluggish. Discouraged, she buys the records from a competitor. Even worse, she then posts her complaints to mailing lists, newsgroups, and her own set of WWW pages.
• Sonia might in fact be a competitor--or, actually, a robot from a competing web site--that is systematically scanning the music store's inventory and obtaining a complete price list.
• Sonia might be Jason, a 14-year-old computer prankster who has stolen Sonia's credit card number and is using it illegally to improve his CD collection.
• Once the merchant obtains Sonia's credit card number, it is stored on the hard disk of the merchant's computer. Jason might break into the computer and steal all the credit card numbers, opening the merchant to liability.
• Once Jason breaks into the merchant's computer, he might introduce fraudulent orders directly into the company's order-processing database. A few days later, Jason receives thousands of CDs in the mail.
• Jason might have his own credit card. Having thoroughly compromised the merchant's computer, Jason begins inserting reverse charge orders into the merchant's credit card processing system. The credits appear on Jason's credit card. A few days later, he uses a neighborhood ATM machine to turn the credits into cash.
• As a prank, or as revenge for some imagined slight, Jason might alter the store's database or WWW pages so that the CDs customers receive are not the ones they ordered. This might not be discovered for a week or two, after thousands of orders have been placed. The merchant would have the expense of paying for all the returned CDs, processing the refunds, and losing the customer's faith.
• Or Jason might simply sabotage the online store by lowering the prices of the merchandise to below the store's cost.

These are the real threats of doing business on the Internet. Some of them are shown in The real threats of doing business on the Internet.

 

The real threats of doing business on the Internet

There is nothing that is fundamentally new about these kinds of risks: they have existed for as long as people have done business by computer; some of these problems can also be experienced doing business by telephone or by mail. But the Internet and the World Wide Web magnify the risks substantially. One of the reasons for the heightened threat on today's networks is that the Internet makes it far easier for people to wage anonymous or nearly anonymous attacks against users and businesses. These attacks, in turn, can be automated, which makes it possible for an attacker to scan thousands of web sites and millions of users for any given vulnerability within a very short amount of time. Finally, these attacks can be conducted worldwide, an unfortunate consequence of the Internet's trans-national nature.

Firewalls: Part of the Solution

A firewall is a device (usually a computer running a specially written or modified operating system) that isolates an organization's internal network from the Internet at large, allowing specific connections to pass and blocking others. Ideally, firewalls are configured so that all outside connections to an internal network go through relatively few well-monitored locations. In so doing, firewalls are part of an organization's overall security strategy.

Unfortunately, many organizations have seized upon firewall technology as their sole security strategy. We have seen organizations that realize they have serious security problems on their internal networks--and then attempt to "solve" this problem by simply using a firewall to block external access.

Because firewalls are frequently misused, we are ambivalent about them. We have too often seen firewalls as a substitute for real problem fixing. And because many attacks come from disgruntled or dishonest employees, and not from outsiders, firewalls divert attention from the real problems of network and host vulnerabilities, poor planning, and lack of organizational policies. Thus, firewalls often improve security only a small amount and, in the process, give their owners a false sense of security.

There are some real situations in which to use firewalls. One is that some organizations must use older " legacy systems" that cannot be secured: a firewall can be used to control access to these systems. (Such firewalls should probably be used to control all access to these systems, rather than merely access from outside the organization.) Another reason to use a firewall is that it is much more difficult to track down an attacker who comes from outside a network than one who comes from inside.

Thus, a firewall should only be used to gain additional security that works in conjunction with internal controls--and never as a replacement for them.

Locating Your Web Server with Respect to
Your Firewall

If your organization uses a firewall to protect its internal network from external attacks, you have a number of choices of where to locate your web server:

• You can locate the web server outside your firewall (see A web server located outside a firewall). The advantage of locating the server outside the firewall is that the web server may be subject to ongoing attacks from rogue Internet users; in the event that the web server is broken into, they will not have gained an increased foothold for launching further attacks against your organization. On the other hand, the web server will not be able to benefit from whatever protection the firewall affords.

   

  A web server located outside a firewall

  
• You can place the web server inside your firewall (see A web server located inside a firewall). If you do this, you will need to configure your firewall so that it will pass transactions on TCP port 80, either by directly allowing the packets through or by using a suitable proxying mechanism. The advantage of locating the web server behind your firewall is that the firewall will block outsiders from using other Internet services, such as Telnet and FTP. However, if attackers manage to subvert your web server through a faulty CGI script, they will have full access to your internal network.

   

  A web server located inside a firewall

  
• Your third option is that you can use two firewalls: one to shield your internal network and one to shield your web server (see A web server located between an internal firewall and an external firewall).

   

  A web server located between an internal firewall and an external firewall

  

A properly secured web server gains no benefit by being placed inside a firewall. That's because a properly secured web server offers only two TCP/IP services to the outside world: HTTP on port 80, and HTTP with SSL on port 443. If you placed your web server behind the firewall, you would have to program the firewall to allow incoming connections to ports 80 and 443 from computers on the Internet.

Of course, the computer on which the web server is running may offer other services to the network as well. Administrators need a way of logging into the computer to perform periodic maintenance and update content. While these services can benefit from the added protection of a firewall, those added protections can easily be incorporated directly on the web server's host. For example, most firewalls block incoming Telnet sessions or provide a mechanism for additional authentication using smart cards or one-time passwords. However, services can be selectively blocked and additional authentication mechanisms can be employed directly at the host by installing and properly configuring Wietse Venema's TCP Wrapper on UNIX-based systems, or correctly enabling access control lists in Windows NT 4.0. Support for token-based authentication, such as using Security Dynamics SecureID cards, can be added to practically any network-based computer. (We describe many of these strategies in later chapters.)

Another reason to locate the web server outside your firewall is that your web server is one of the most likely computers to be compromised by an outside attacker because of its visibility and availability. If your web server is located within the firewall, then the attacker will have an ideal foothold for launching further attacks against your organization. This is a serious concern, because organizations that use firewalls often have weaker internal security than those that rely on strong internal security measures to prevent attacks and unauthorized use.

If your web server is repeatedly attacked from a particular host on the Internet, a short-term fix is to locate an additional router between your outside network connection and your web server so that these "attack packets" are dropped rather than passed through to your web server. A longer-term fix is to contact the attacker's Internet service provider or notify a law enforcement agency.

Risk Management

Web security is not "all or nothing"--security is a matter of degree. The more security measures you employ, the more you reduce your risk. Your goal should be to reduce risk as much as is practical (and affordable), and then to take additional measures so that if there is a security incident, you will be able to recover quickly.

Some people think that security is difficult, and that it is impossible to have a system that is completely secure, so why bother trying at all? You may work with people who express this attitude.

Unfortunately, the fact is that computer security is not painless and it is not free. Companies that eschew computer security and decide to take their chances live in a riskier environment. A computer administrator who sets up a security-free system that does not subsequently suffer a break-in may be rewarded for his or her carelessness--possibly being promoted or hired by another organization. If a security incident occurs, the administrator may be long gone.

On the other hand, as this book shows, good web security is becoming easier to implement and work with. And as commerce becomes a part of the Internet, good security is becoming expected as a matter of course. The important thing to realize is that security is not simply a product that can be purchased. Security must be an integrated part of an organization's operation.