By Simson Garfinkel
With Gene Spafford

Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: The Web Security Landscape

Content preview·Buy reprint rights for this chapter

In this chapter, we'll look at the basics of web security. We'll discuss the risks of running a web server on the Internet and give you a framework for understanding how to defend against those risks. We'll also look at the hype surrounding web security, analyze what companies (probably) mean when they use the phrase "secure web server," and discuss overall strategies for reducing the risks of operating a site and publishing information on the World Wide Web.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Web Security in a Nutshell

Content preview·Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Web Security Problem

Content preview·Buy reprint rights for this chapter

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

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Credit Cards, Encryption, and the Web

Content preview·Buy reprint rights for this chapter

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.

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

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Firewalls: Part of the Solution

Content preview·Buy reprint rights for this chapter

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.

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:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Risk Management

Content preview·Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: The Buggy Browser: Evolution of Risk

Content preview·Buy reprint rights for this chapter

Web browsers are extremely complex pieces of software that seem to be getting more complex all the time. Every time new features are added, there are more chances for something to go wrong. That's good news for crooks and attackers and bad news for people interested in web security. Most security bugs are fundamentally programming bugs.

Fortunately, by understanding the real risks of browsers, it is possible to manage many of their associated risks.

The first web browsers were developed by scientists at CERN for publishing papers about high-energy particle physics. These early browsers could display web pages containing text and links to other pages of text. The pages were created with a WYSIWYG (What-You-See-Is-What-You-Get) editor written for NeXT computers and stored in HTML files.

Mosaic 2.0, the browser created at the National Center for Supercomputing Applications, introduced the ability to display forms and simple widgets, with text fields, push buttons, radio buttons, and pull-down menus. Combined with CGI (Common Gateway Interface), forms and widgets gave web programmers a kind of generic user interface. It was simple: Display a form, have the user fill in some fields, press a button, and display a new form with new fields to be filled in.

There was nothing fundamentally new about the web's style of computing: IBM computers were doing it in the 1970s on 3270 terminals. Called "block mode," this style of computing involved a simple three-step process:

1. The host computer displayed a form on the user's terminal.
2. The user filled in the fields. Editing was done locally so that it didn't consume expensive communication and centralized CPU resources.
3. Finally, the user clicked the SEND button and the contents of the form were sent back to the central computer. The terminal then waited until the computer sent a new form to display, which started the process all over again.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Browser History

Content preview·Buy reprint rights for this chapter

The first web browsers were developed by scientists at CERN for publishing papers about high-energy particle physics. These early browsers could display web pages containing text and links to other pages of text. The pages were created with a WYSIWYG (What-You-See-Is-What-You-Get) editor written for NeXT computers and stored in HTML files.

Mosaic 2.0, the browser created at the National Center for Supercomputing Applications, introduced the ability to display forms and simple widgets, with text fields, push buttons, radio buttons, and pull-down menus. Combined with CGI (Common Gateway Interface), forms and widgets gave web programmers a kind of generic user interface. It was simple: Display a form, have the user fill in some fields, press a button, and display a new form with new fields to be filled in.

There was nothing fundamentally new about the web's style of computing: IBM computers were doing it in the 1970s on 3270 terminals. Called "block mode," this style of computing involved a simple three-step process:

1. The host computer displayed a form on the user's terminal.
2. The user filled in the fields. Editing was done locally so that it didn't consume expensive communication and centralized CPU resources.
3. Finally, the user clicked the SEND button and the contents of the form were sent back to the central computer. The terminal then waited until the computer sent a new form to display, which started the process all over again.

Block mode was as familiar a concept to the users of IBM's OS/360 mainframes in 1976 as it is to people surfing the Internet with Netscape Navigator today. Block mode systems are well-suited to libraries, reference systems, and scholarly journals. Sending commands and waiting for the result emulates other kinds of academic operations, such as turning the pages of a magazine, checking a book out of a library, or doing a long Monte Carlo simulation run on a mainframe computer. Thus, it's not surprising that this was the style developed by a bunch of physicists working in Europe. The mapping was natural.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Data-Driven Attacks

Content preview·Buy reprint rights for this chapter

It is possible for an attacker to give malicious data to a normally well-behaved application to produce undesirable results.

Consider the case of a user who has not followed our advice in the previous section and has set up Microsoft Word as a helper application for files ending in the letters ".doc". Normally there will be no problem at all. But if the unsuspecting user tries to download a particular Microsoft Word file, his computer might become infected with a virus. Or consider a user who is still using Version 3.0 of Microsoft's Internet Explorer—the one with the big security hole. Normally this user will have no problems. But one day, he may chance upon a web page that exploits the bug and erases all of his files.

These sorts of attacks are called data-driven attacks, because the type and nature of the attack is determined by data that is downloaded to the user's computer. Most Internet-based attacks are in fact data-driven attacks because they rely on downloading malicious data, rather than programs, to the victim's computer.

The remainder of this section looks at a variety of data-driven attacks.

One of the simplest and most effective data-driven attacks is to give the user a message asking him to do something that is unsafe. These attacks are effective because most users are conditioned to follow whatever instructions appear on the computer screen. One unfortunate result of the web's ease of publishing is that attackers can publish information as easily as legitimate data providers can.

Here are some types of messages that an attacker might wish to display on a user's screen:

• "There is a problem with your account. Please change your password to NowSafe and await further instructions."

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Implementation Flaws: A Litany of Bugs

Content preview·Buy reprint rights for this chapter

Most web browsers implement a security policy that is designed to protect the user from both malicious eavesdropping and hostile web pages. Unfortunately, bugs in the browser can effectively subvert such a policy, leaving the user open to those attacks.

Throughout 1995, Netscape's early browsers were subject to a high degree of scrutiny. Often, reports of these bugs appeared on the front pages of major daily newspapers, rather than the academic press. The public's confidence in Netscape Navigator's security was so shaken, in fact, that Netscape announced that it would pay users up to $1000 for each bug that was discovered. Netscape's theory was that the increased scrutiny that its product received as a result of the bounty program would make the product more secure. Netscape has also made its source code available on some occasions to academics involved in security-related research.

Here are some of the more important bugs that were discovered in Netscape Navigator:

• In September 1995, Ian Goldberg and David Wagner, two graduate students at the University of California at Berkeley working with professor Eric Brewer, discovered a flaw in the way that the UNIX version of the Netscape Navigator generated random numbers. Instead of seeding the random number generator with a number that was unpredictable, such as the user's mouse motions, programmers at Netscape had decided to use the computer's time-of-day clock, the Navigator's process number, and other information that was trivial to determine. The students discovered that they could determine this information and predict the results of the random number generator. Some articles describing this attack can be found at http://www.cs.berkeley.edu/~iang/press/.
• In October 1995, the same group of students discovered an even more impressive attack against Navigator: they could simply patch out the random number generator, so that it always used the same key.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 3: Java and JavaScript

Content preview·Buy reprint rights for this chapter

Java and JavaScript are both languages for adding interactivity to web pages. Both languages can be run on either a web browser or a web server (or even stand-alone). Both languages have a syntax that resembles the C++ language.

Despite these apparent similarities, Java and JavaScript are actually two completely different languages with different semantics, different user communities, and different security implications. This chapter explores the security issues in each language.

Although today Java is widely thought of as a language for writing programs that are downloaded over the Internet to web browsers, it wasn't designed for that purpose. Indeed, Java's security model was largely added as an afterthought. To understand the security issues with Java today, it's important to understand the history of the language.

Java's history started in 1991 when a group of engineers at Sun Microsystems were hard at work on a stealth project designed to catapult Sun into the world of consumer electronics. Sun envisioned a future in which toasters, remote control systems, stereos, and cable decoder boxes were all programmed using a common computer language with programs that could be easily downloaded over a network. The stealth project was designed to leverage Sun's experience with computer languages, system design, and silicon manufacturing to turn the company into a major supplier for this new world order.

The key to dominating this new world was a new computer language developed by James Gosling. Called Oak, the language was designed to produce programs that would be compact and highly reliable. Compactness was necessary because Oak programs were going to be downloaded over networks whenever it was necessary to change them. And reliability was necessary too, because programs in this language had to be able to run for weeks or months at a time without outside intervention: you can't expect to dominate the market if you sometimes need to tell the average American that his toaster oven has to be rebooted to continue operation.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Java

Content preview·Buy reprint rights for this chapter

Although today Java is widely thought of as a language for writing programs that are downloaded over the Internet to web browsers, it wasn't designed for that purpose. Indeed, Java's security model was largely added as an afterthought. To understand the security issues with Java today, it's important to understand the history of the language.

Java's history started in 1991 when a group of engineers at Sun Microsystems were hard at work on a stealth project designed to catapult Sun into the world of consumer electronics. Sun envisioned a future in which toasters, remote control systems, stereos, and cable decoder boxes were all programmed using a common computer language with programs that could be easily downloaded over a network. The stealth project was designed to leverage Sun's experience with computer languages, system design, and silicon manufacturing to turn the company into a major supplier for this new world order.

The key to dominating this new world was a new computer language developed by James Gosling. Called Oak, the language was designed to produce programs that would be compact and highly reliable. Compactness was necessary because Oak programs were going to be downloaded over networks whenever it was necessary to change them. And reliability was necessary too, because programs in this language had to be able to run for weeks or months at a time without outside intervention: you can't expect to dominate the market if you sometimes need to tell the average American that his toaster oven has to be rebooted to continue operation.

Instead of being compiled for a specific microprocessor, Oak was designed to be compiled into an interpreted bytecode that would run on a virtual machine. Simple economics drove the decision to use a virtual machine: a portable bytecode would allow a consumer electronics manufacturer to change its microprocessor without losing compatibility with existing programs. Unlike today's desktop computers, the microprocessor would truly become a commodity.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

JavaScript

Content preview·Buy reprint rights for this chapter

JavaScript, originally known as LiveScript, is a programming language that Netscape developed to make animation and other forms of interaction more convenient. JavaScript programs reside in HTML files, usually surrounded by both <script> tags (so that they will be recognized by JavaScript-enabled browsers) and HTML comment tags (so that they will be ignored by browsers that do not understand JavaScript).

Netscape's JavaScript allows HTML files to command the browser. JavaScript programs can create new windows, fill out fields in forms, jump to new URLs, process image maps locally, change the HTML content of the HTML page itself, compute mathematical results, and perform many other functions.

JavaScript is the native language of Netscape's web browser. For this reason, JavaScript has many functions specifically designed to modify the appearance of web browsers: JavaScript can make visual elements of the web browser appear or disappear at will. JavaScript can make messages appear in the status line of web browsers. Some of the earliest JavaScript applications displayed moving banners across the web browser's status line.

Because JavaScript programs tend to be small functions that tie together HTML files, GIFs, and even other programs written in JavaScript, many people call JavaScript a "scripting language." But JavaScript is a full-fledged general-purpose programming language, exactly like every other programming language. You could write an accounts receivable system in it if you wanted to.

JavaScript programs should be inherently more secure than programs written in Java or other programming languages for a number of reasons:

• There are no JavaScript methods for directly accessing the client computer's file system.
• There are no JavaScript methods for directly opening connections to other computers on the network.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Denial-of-Service Attacks

Content preview·Buy reprint rights for this chapter

A significant security problem with both Java and JavaScript is the difficulty of preventing denial-of-service attacks.

A denial-of-service attack is an attack in which a user (or a program) takes up so much of a shared resource that none of the resource is left for other users or uses. Although the mainframe computers of yesteryear had some defenses against denial-of-service attacks, modern computer systems are notoriously poor at handling such attacks.

Of course, any programming language or environment that allows systemwide resources to be allocated, and then places no limitations on the allocation of such resources, is subject to denial-of-service attacks. But Java and JavaScript seem to be especially sensitive to them, apparently because the authors of these languages have not considered denial-of-service attacks to be serious threats. Programs written in Java and JavaScript can easily command large amounts of system resources, and there are few avenues available for a user who is under attack to regain control of his system.

Should we be concerned about denial-of-service attacks? Dennis Ritchie, one of the original creators of the UNIX operating system, didn't think so back in the 1970s when UNIX was first designed. When Simson interviewed Ritchie in 1988, Ritchie said that UNIX wasn't built to withstand denial-of-service attacks because most of these attacks were either launched "by accident, or it was relatively easy to figure out who was responsible. The individual could [then] be disciplined outside the operating system by other means."

These days, many programmers seem to feel the same way. Protecting against denial-of-service attacks is very difficult. Instead of trying, most programmers simply don't bother. After all, it's usually relatively easy to determine who is responsible for a denial-of-service attack. It's usually easier to deal with these people by nontechnical means.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

JavaScript-Enabled Spoofing Attacks

Content preview·Buy reprint rights for this chapter

Ed Felten at Princeton University notes that people are constantly making security-related decisions. To make these decisions, people use contextual information provided by their computer. For example, when a user dials in to a computer, the user knows to type her dial-in username and password. At the same time, most users know to avoid typing their dial-up username and password into a chat room on America Online.

The combination of Java and JavaScript can be used to confuse the user. This can result in a user's making a mistake and providing security-related information to the wrong party.

When an untrusted Java applet creates a window, most web browsers label the window in some manner so that the user knows that it is unsecure. Netscape Navigator, for instance, will display the window with the message "untrusted applet." The intention of this labeling is to alert the user: users may not wish to type their login usernames and passwords into a window that's not "trusted."

When an applet runs inside a browser window itself, no such labeling takes place. A rogue HTML page can easily display an innocuous background and then use a Java applet to create a traditional web browser username/password panel. The applet can even detect an attempt to drag the spoofed "window" and make it move on the page appropriately. The user can't determine the difference unless she tries to drag the window outside the browser's window.

Applets aren't limited to spoofing web username/password panels. An applet could easily display other username/password panels. For example, a web server could check to see if a user has accessed a web page using a Windows 95 personal computer dialed up with the Microsoft PPP dialer. If this is detected, the applet could display a window that told the user that the connection had been disconnected, followed by a request to reconnect (see Figure 3.4 and Figure 3.5).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Conclusion

Content preview·Buy reprint rights for this chapter

Java and JavaScript are both here to stay, as both of the languages give web developers powerful techniques for creating new content for the Web. Unfortunately, both of these languages have profound security implications. The challenge for software vendors will be to discover ways of making the implementations of these languages secure enough so that users can download and run programs from any web site without fear.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 4: Downloading Machine Code with ActiveX and Plug-Ins

Content preview·Buy reprint rights for this chapter

One of the most dangerous things that you can do with a computer that is connected to the Internet is to download a program and run it. That's because most personal computer operating systems place no limits on what a program can do once it starts running. When you download a program and run it, you are placing yourself entirely in the hands of the program's author.

Most programs that you download will behave as expected. But they don't have to. Many programs have bugs in them: running them will cause your computer to crash. But some programs are malicious: they might erase all of the information on your computer's disk. Or the program might seek out confidential information stored on your computer and transmit it to a secret location on the Internet. The program might even send threats to the president of the United States and the U.S. Congress, possibly granting you a visit from the Secret Service.

The goal of an attacker is to be able to run a program of his choice on your computer without your knowledge. Once this ability is gained, any other attack is possible.

The easiest way for an attacker to accomplish this goal is to give or download a program to you for your computer to run. One would think that an easy way to defend against this attack would be to inspect all downloaded programs to see if they contain malicious code. Unfortunately, it's theoretically impossible to determine what a computer program will do without running it. What's possibly even more frightening is the fact that it's frequently impossible to determine what a program is doing even after you have run it: programs have many ways of hiding their operations.

Even secure operating systems with memory protection and other security mechanisms, such as Windows NT and UNIX, offer users no real security against programs that they download and run. That's because once the program is running, it inherits all of the privileges and access rights of the user who invoked it. No commercially available operating system allows users to create a "sandbox" in which to run suspicious code.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

When Good Browsers Go Bad

Content preview·Buy reprint rights for this chapter

The goal of an attacker is to be able to run a program of his choice on your computer without your knowledge. Once this ability is gained, any other attack is possible.

The easiest way for an attacker to accomplish this goal is to give or download a program to you for your computer to run. One would think that an easy way to defend against this attack would be to inspect all downloaded programs to see if they contain malicious code. Unfortunately, it's theoretically impossible to determine what a computer program will do without running it. What's possibly even more frightening is the fact that it's frequently impossible to determine what a program is doing even after you have run it: programs have many ways of hiding their operations.

Even secure operating systems with memory protection and other security mechanisms, such as Windows NT and UNIX, offer users no real security against programs that they download and run. That's because once the program is running, it inherits all of the privileges and access rights of the user who invoked it. No commercially available operating system allows users to create a "sandbox" in which to run suspicious code.

Internet users have been taught to download programs and run them without question. Web browsers like Netscape Navigator and Internet Explorer are distributed by downloads. And systems that extend the capabilities of these web browsers, such as the RealAudio player and the Adobe Acrobat Reader, are distributed by downloads as well.

Already, users have lost thousands of dollars by the actions of hostile programs that they have downloaded and run on their computers. These losses are likely to mount as technologies for downloading executable code become more widespread.

In January 1996, First Virtual Holdings demonstrated a program designed to show how easy it is to compromise a computer system. Affectionately called "Card Shark," the program appeared to be a screensaver. Normally, the program would run silently in the background of your computer. If you didn't type on your computer's keyboard for a while, the screen would blank. You could make the screen reappear by typing a few characters.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Netscape Plug-Ins

Content preview·Buy reprint rights for this chapter

Although the two examples in the preceding section involved standalone programs, increasingly there is interest in using downloaded programs to extend the capabilities of web browsers. One way to do this is with helper applications , such as the RealAudio player. Another way is through the use of plug-ins.

Plug-ins were introduced with Netscape Navigator as a simple way of extending browsers with executable programs that are written by third parties and loaded directly into Netscape Navigator. One of the simplest uses for plug-ins is to replace helper applications used by web browsers. Instead of requiring that data be specially downloaded, saved in a file, and processed by a helper application, the data can be left in the browser's memory pool and processed directly by the plug-in. But plug-ins are not limited to the display of information. In the fall of 1996, Microsoft released a plug-in that replaced Netscape's Java virtual machine with its own. And PGP, Inc., is developing a plug-in that adds PGP encryption to Netscape Communicator's email package.

Plug-ins are manually downloaded by the web user and stored in a special directory located in the Netscape Navigator program directory. The web browser scans this directory when it starts up to discover what plug-ins are available.

Two popular plug-ins are the Macromedia Shockwave plug-in, which can play animated sequences, and the Adobe Acrobat plug-in, which lets Navigator display PDF files. Both of these plug-ins have been used since shortly after the introduction of Netscape's plug-in architecture.

When Netscape Navigator encounters a document that requires a plug-in to be properly viewed, Navigator displays a window such as the one in Figure 4.1.

Figure 4.1: Netscape Navigator displays a special window when it encounters a document for which a plug-in is required

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

ActiveX and Authenticode

Content preview·Buy reprint rights for this chapter

ActiveX is a collection of technologies, protocols, and APIs developed by Microsoft that are used for downloading executable code over the Internet. The code is bundled into a single file called an ActiveX control. The file has the extension OCX.

Microsoft has confusingly positioned ActiveX as an alternative to Java. ActiveX is more properly thought of as an alternative to Netscape's plug-ins. ActiveX controls are plug-ins that are automatically downloaded and installed as needed, then automatically deleted when no longer required. Adding to the confusion is the fact that ActiveX controls can be written in Java!

Despite the similarities between ActiveX controls and Netscape plug-ins, there are a few significant differences:

• Whereas plug-ins usually extend a web browser so that it can accommodate a new document type, most ActiveX controls used to date have brought a new functionality to a specific region of a web page.
• Traditionally, ActiveX controls are downloaded and run automatically, while plug-ins need to be manually installed.
• ActiveX controls can be digitally signed using Microsoft's Authenticode technology. Internet Explorer can be programmed to disregard any ActiveX control that isn't signed, to run only ActiveX controls that have been signed by specific publishers, or to accept ActiveX controls signed by any registered software publisher. Netscape Navigator 3.0 has no provisions for digitally signing plug-ins, although this capability should be in Navigator 4.0.

ActiveX controls can perform simple animations, or they can be exceedingly complex, implementing databases or spreadsheets. They can add menu items to the web browser, access information on the pasteboard, scan the user's hard drive, or even turn off the user's computer.

Fundamentally, there are two kinds of ActiveX controls:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Risks of Downloaded Code

Content preview·Buy reprint rights for this chapter

Fred McLain's Internet Exploder showed that an ActiveX control can turn off your computer. But, as we've said, it could have done far worse damage. Indeed, it is hard to overstate the attacks that could be written and the subsequent risks of executing code downloaded from the Internet.

Increasingly, programs running computers can spend the money of their owners. What happens when money is spent by a program without the owner's permission? Who is liable for the funds spent? How can owners prevent these attacks?

To answer these questions, it's necessary to first understand how the money is being spent.

Section 4.4.1.1: Telephone billing records

One of the first recorded cases of a computer program that could spend money on behalf of somebody else was the pornography viewer distributed by the Sexy Girls web site (described at the beginning of this chapter).

In this case, what made it possible for the money to be spent was the international long distance system, which already has provisions for billing individuals for long distance telephone calls placed on telephone lines. Because a program running on the computer could place a telephone call of its choosing, and because there is a system for charging people for these calls, the program could spend money.

Although the Sexy Girls pornography viewer spent money by placing international telephone calls, it could just as easily have dialed telephone numbers in the 976 exchange or 900 area code, both of which are used for teletext services. The international nature of the telephone calls simply makes it harder for authorities to refund the money spent, because the terms of these calls are subject to international agreements.

One way to protect against these calls would be to have some sort of trusted operating system that does not allow a modem to be dialed without informing the person sitting at the computer. Another approach would be to limit the telephone's ability to place international telephone calls, the same as telephones can be blocked from calling 976 and 900 numbers. But ultimately, it might be more successful to use the threat of legal action as a deterrent against this form of attack.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Is Authenticode a Solution?

Content preview·Buy reprint rights for this chapter

Code signing is an important tool for certifying the authenticity and the integrity of programs. But as we will see, Authenticode does not provide "safety," as is implied by Internet Explorer's panel.

Code signing does not provide users with a safe environment where they can run their programs. Instead, code signing is intended to provide users with an audit trail. If a signed program misbehaves, you should be able to interrogate the signed binary and decide who to sue. And as the case of Fred McLain's Internet Exploder demonstrates, once the author of a malicious applet is identified the associated software publisher's credentials can be revoked, preventing others from being harmed by the signed applet.

Unfortunately, security through code-signing has many problems:

Audit trails are vulnerable.

Once it is running, a signed ActiveX control might erase the audit trail that would allow you to identify the applet and its author. Or the applet might merely edit the audit trail, changing the name of the person who actually signed it to "Microsoft, Inc." The control might even erase itself, further complicating the task of finding and punishing the author. Current versions of Microsoft's Internet Explorer don't even have audit trails, although audit trails may be added to a later release.

The damage that an ActiveX control does may not be immediately visible.

Audit trails are only useful if somebody looks at them. Unfortunately, there are many ways that a rogue piece of software can harm the user, each of which is virtually invisible to that person. For example, a rogue control could turn on the computer's microphone and turn it into a clandestine room bug. Or the applet could gather sensitive data from the user, such as scanning the computer's hard disk for credit card numbers. All of this information could then be surreptitiously sent out over the Internet.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Improving the Security of Downloaded Code

Content preview·Buy reprint rights for this chapter

Although this chapter tells many scary stories, there are real protections that both users and developers can employ in order to protect against the dangers of downloaded code.

One way to improve the security of downloaded code is to rely only on code from vendors with a good reputation who follow high standards in writing their programs.

If you choose to trust the code of these vendors, you also need to make sure that the programs you download are actually the programs these companies have created—and not booby-trapped copies. This is, in fact, exactly the rationale behind Microsoft's Authenticode system.

Another way to run downloaded code safely is to minimize the privileges available to the execution context in which the downloaded code runs. This is precisely the idea behind the Java "sandbox." Unfortunately, implementing separate execution contexts for executable machine code requires modifications to both the browser and the operating system.

ActiveX controls currently run in the same execution context as the user's web browser. With Windows 95, this means that the control has full access to the system. But on operating systems like Windows NT, it is possible that a control could be executed within a more restricted context with added security.

To realize added security, it would be necessary for the control to be run in a separate thread that lacked the ability to modify any portion of the web browser or any other executable on the operating system. Additional privileges could be added to this thread similar to the way additional privileges can be given to Java applets.

Without separate execution contexts, it is doubtful that the overall security of ActiveX can be improved—even on operating systems such as Windows NT. This is because the web browser is normally run with privileges that can do substantial damage to the operating system: many people who install Windows NT systems either install all system software from the same user account or, even worse, give themselves administrator privileges so the system's security won't "get in the way." Doing so all but eliminates the security advantages of operating systems such as Windows NT

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 5: Privacy

Content preview·Buy reprint rights for this chapter

Privacy is likely to be a growing concern as Internet-based communications and commerce increase. Designers and operators of web sites who disregard the privacy of users do so at their own peril. Users of web services who are not concerned with privacy may soon find they have none. Users who feel that their privacy has been violated may leave the Web. Stories of problems may keep others away. Thus, it behooves everyone to pay attention to the task of protecting personal privacy on the Web.

Every time a web browser views a page on the web, a record is kept in that web server's log files.

Log files are under the control of the person or organization that controls the web server. They could be used against you in a court of law. They could be given to your employer to show what you do during the day when you're being paid to work. They could be used by a jilted lover to spy on your activities. Worse things have happened. But most likely, the information will lay low, never raising its head. It might even be deleted . . . then again, it might not.

Each time a page is downloaded or a CGI script is run from a web server, the web server records the following information in its log files:

• The name and IP address of the computer that made the connection
• The time of the request
• The URL that was requested
• The time it took to download the file
• The username of the person who downloaded the file, if HTTP authentication was used
• Any errors that occurred
• The previous web page that was downloaded by the web browser (called the refer link)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Log Files

Content preview·Buy reprint rights for this chapter

Every time a web browser views a page on the web, a record is kept in that web server's log files.

Log files are under the control of the person or organization that controls the web server. They could be used against you in a court of law. They could be given to your employer to show what you do during the day when you're being paid to work. They could be used by a jilted lover to spy on your activities. Worse things have happened. But most likely, the information will lay low, never raising its head. It might even be deleted . . . then again, it might not.

Each time a page is downloaded or a CGI script is run from a web server, the web server records the following information in its log files:

• The name and IP address of the computer that made the connection
• The time of the request
• The URL that was requested
• The time it took to download the file
• The username of the person who downloaded the file, if HTTP authentication was used
• Any errors that occurred
• The previous web page that was downloaded by the web browser (called the refer link)
• The kind of web browser that was used

This information can be combined with other log files—such as login/logout information from Internet service providers, or logs from mail servers—to discover the actual identity of the person who was doing the downloading. Normally this sort of cross-correlation requires the assistance of another organization, but that is not always the case.

For example, many ISPs dynamically assign IP addresses to computers each time they call up. A web server may know that a user accessed a page from the host,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Cookies

Content preview·Buy reprint rights for this chapter

Netscape introduced the "cookies" specification with Navigator Version 2.0. The original purpose of cookies was to make it possible for a web server to track a client through multiple HTTP requests. This sort of tracking is needed for web-based applications. For example, an online catalog might store a session ID in a cookie so that the web server can keep track of what items are in a customer's "shopping cart."

A cookie is a block of ASCII text that a web server can pass into a user's instance of Netscape Navigator (and many other web browsers). Once received, the web browser sends the cookie every time a new document is requested from the web server.

Cookies are kept in the web browser's memory. If a cookie is persistent, the cookie is also saved by the web browser. Persistent cookies can be used to store a user's preferences for things like screen color, so that the user does not need to re-register preferences each time he or she returns to a web site.

Netscape browsers store cookies in the file called cookies.txt, which can be found in the user's preference directory. Internet Explorer saves cookies in the directory C:\Windows\Cookies on Windows systems.

Netscape's cookies can be used to remove anonymity on the web or to enhance it. Unfortunately, the choice is not in the hands of the web user: it is under the control of the web server. Furthermore, it can be difficult for users to tell to what purpose cookies are being used.

RFC 2109 describes the HTTP state management system (cookies). According to the RFC, any web browser that implements cookies should provide users with at least the following controls:

• The ability to completely disable the sending and saving of cookies
• A (preferably visual) indication as to whether cookies are in use

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Personally Identifiable Information

Content preview·Buy reprint rights for this chapter

Online businesses know a lot about their customers—and they can easily learn a lot more. What standards should web sites follow with personally identifiable information that they gather?

As with any business, online service providers know the names, addresses, and frequently the credit card numbers of their subscribers. But records kept by the provider's computers can also keep track of who their customers exchange email with, when they log in, and when they go on vacation.

Internet service providers can learn even more about their customers, because all information that an Internet user sees must first pass through the provider's computers. ISPs can also determine the web sites that their users frequent—or even the individual articles that have been viewed. By tracking this information, an Internet provider can tell if its users are interested in boats or cars, whether they care about fashion, or even if they are interested in particular medical diseases.

The Electronic Frontier Foundation thinks that it has a solution to the cookie privacy problem. Called eTrust, the program's goal is to develop standards for online privacy. One of the things that those standards would govern is what web sites can do with personal information they collect about their users. Web sites would display a particular eTrust logo indicating their privacy policy; in return, they would submit to data audits by a recognized accounting firm.

Something like the eTrust program is a good idea, because even with smart cookies, some personal information is inevitably going to be stored on web servers. But the real hope is that web sites will start using cookies intelligently to cut down on the amount of personal information that's being collected.

Our second hope is that nations will pass privacy laws regulating what can and cannot be done with information that is collected online.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Anonymizers

Content preview·Buy reprint rights for this chapter

One clever approach to privacy is to use an anonymizing Web server. These are servers that are designed to act as proxies for users concerned with privacy. A user sends a URL to the anonymizer as an addition to the URL for the anonymizer itself. The software at the anonymizer then strips off the additional URL and makes a request for that URL itself. The destination server receives the request, apparently from a user on the anonymizing server. The information returned from the destination server is passed back to the anonymizer. The anonymizing site then passes this information back to the end user.

Anonymizers vary in their sophistication and their capabilities. For instance, some of the simplest anonymizers will not properly handle forms-based input for a third party. Cookies holding personal preferences are not passed along to the destination. Although this protects the privacy of the user, it may also hinder customization.

Anonymizers have trouble with active content, such as Java and ActiveX. Both of these systems for running programs on the user's machine contain method calls that allow a running program to determine the name of the machine on which it is running. If this information is passed back to the original web server, the anonymizer is useless. Thus, if you wish to truly surf the Web anonymously through an anonymizer, you should also disable the execution of active content such as Java, JavaScript, and ActiveX.

Anonymizers are simple to set up, and there may be a number of reasons to do so:

• If you believe that people should be able to surf the Web anonymously, you might set up an anonymizer as a public service.
• You might run an anonymizer that displays an advertisement in addition to the selected page.
• You might run an anonymizer that covertly monitors the people who