The World Wide Web Security FAQ

9. Client Side Security

(Thanks to Laura Pearlman, who contributed many of the Q&A's in this section).

Q54: Someone suggested I configure /bin/csh as a viewer for documents of type application/x-csh. Is this a good idea?

This is not a good idea. Configuring any command-line shell, interpreter, macro processor, of scripting language processor as the "viewer" for a document type leaves you vulnerable to attack over the Web. You should never blindly execute any program you download from the Internet (including programs obtained by FTP). It is safer to download a script as text, look it over to make sure it isn't doing anything malicious, and then run it by hand.

These words of warning apply also to the macro worksheets generated by popular PC spreadsheet programs. Although it seems natural to declare a type "application/x-msexcel-macro" in order to receive spreadsheets that automatically recalculate themselves, some of the functions in the Excel macro language have the potential to inflict damage on other worksheets and files. These warnings even apply to such seemingly innocuous things as word processor style sheets and template files! Many high end word processors have a built-in macro processing ability. An example of the way in which word processing macros can be misused is the Microsoft Word "prank macro", which has the ability to spread, virus-like, from document to document.

I have heard of at least one individual who decided he'd only be using the C-shell to download scripts written by himself and other trusted parties. He screened all URLs by hand to make sure they didn't end with a .csh extension before downloading them. Unfortunately the file extension is not a reliable way to determine what a URL contains. The type of a document is determined by the Web (HTTP) server, not the browser, and a document of type application/x-csh can just as easily have an extension of .txt or no extension at all.

In short, beware of declaring an external viewer for any file that contains executable statements.

This security problem is addressed by scripting languages as Java and Safe Tcl in which dangerous functions can be disabled. There's even a prototype "Safe Perl" that can be used as a safer external viewer for perl programs.

Q55: Is there anything else I should keep in mind regarding external viewers?

Yes. Whenever you upgrade a program that you've configured as an external viewer you should think about the issues related in Q54 in light of the program's new features. For example, if the viewer is a word processor, and the new version has just added scripting/macro features, is there any chance that loading and displaying the document could automatically launch a script?

Q56: How do I turn off the "You are submitting the contents of a form insecurely" message in Netscape? Should I worry about it?

This message indicates that the contents of a form that you're submitting to a CGI script is not encrypted and could be intercepted. Right now you'll get this message whenever you submit a form to any non-Netscape server, since only the Netsite Commerce Server can handle encrypted forms. You probably shouldn't send sensitive information such as credit card numbers via unencrypted forms (however if you're the type who reads his credit card number over cellular phones, an even more insecure means of communication, go right ahead!).

To turn this warning off, select Preferences from Netscape's Options menu, choose "Images and Security", and uncheck the checkbox labeled "Warn before submitting forms insecurely."

Q57 How secure is the encryption used by SSL?

SSL uses public-key encryption to exchange a session key between the client and server; this session key is used to encrypt the http transaction (both request and response). Each transaction uses a different session key so that if someone manages to decrypt a transaction, that does not mean that they've found the server's secret key; if they want to decrypt another transaction, they'll need to spend as much time and effort on the second transaction as they did on the first.

Netscape servers and browsers do encryption using either a 40-bit secret key or a 128-bit secret key. Many people feel that using a 40-bit key is insecure because it's vulnerable to a "brute force" attack (trying each of the 2^40 possible keys until you find the one that decrypts the message). This was in fact demonstrated in 1995 when a French researcher used a network of workstations to crack a 40-bit encrypted message in a little over a week. It is thought that with specialized hardware, 40-bit messages can be cracked in minutes to hours. Using a 128-bit key eliminates this problem because there are 2^128 instead of 2^40 possible keys. To crack a message encrypted with such a key by brute force would take significantly longer than the age of the universe using conventional technology. Unfortunately, most Netscape users have browsers that support only 40-bit secret keys. This is because of legal restrictions on the encryption software that can be exported from the United States.

In Netscape you can tell what kind of encryption is in use for a particular document by looking at the "document" information" screen accessible from the file menu. The little key in the lower left-hand corner of the Netscape window also indicates this information. A solid key with two teeth means 128-bit encryption, a solid key with one tooth means 40-bit encryption, and a broken key means no encryption. Even if your browser supports 128-bit encryption, it may use 40-bit encryption when talking to older Netscape servers or Netscape servers outside the U.S. and Canada.

Q58 My Netscape browser is displaying a form for ordering merchandise from a department store that I trust. The little key at the lower left-hand corner of the Netscape window is solid and has two teeth. This means I can safely submit my credit card number, right?

Not quite. A solid key with two teeth appears indicates that SSL is being used with a 128-bit secret key and that the remote host owns a valid server certificate that was certified by some authority that Netscape recognizes. At this point, however, you don't know who that certificate belongs to. It's possible that someone has bought or stolen a server certificate and then diverted network traffic destined for the department store by subverting a router somewhere between you and the store. The only way to make sure that you're talking to the company you think you're talking to is to open up the "Document Information" window (from the File menu) and examine the server certificate. If the host and organization names that appear there match the company you expect, then you're probably safe to submit the form. If something unexpected appears there (like "Embezzlers R Us") you might want to call the department store's 800 number.

Q59: How private are my requests for Web documents?

Read section (7) above. All requests for documents are logged by the Web server. Although your name is not usually logged, your IP address and computer's host name usually is. In addition, some servers also log the URL you were viewing (such as your home page) at the time you requested the new URL. If the site is well administered, the record of your accesses will be used for statistics generation and debugging only. However, some sites may leave the logs open for casual viewing by local users at the site or even use them to create mailing lists.

The contents of queries in forms submitted using the GET request appear in the server log files because the query is submitted as part of the URL. However, when a query is submitted as a POST request (which is often the case when submitting a fill-out form), the data you submit doesn't get logged. If you are concerned about the contents of a keyword search appearing in a public log somewhere, check whether the search script uses the GET or POST method. The easiest technique is to try an innocuous query first. If the contents of the query appear in the URL of the retrieved document, then they probably appear in the remote server's logs too.

Server/browser combinations that use data encryption, such as Netsite/Netscape, encrypt the URL request. Furthermore the encrypted request, because it is submitted as a POST request, does not appear in the server logs.

Q60: What's the difference between Java and JavaScript?

Despite the similarity in names, Java and JavaScript are two separate entities. Java is a language designed by Sun Microsystems. Java scripts are precompiled into a compact form and stored on the server's side of the connection. HTML documents refer to the mini-applications known as Java "applets" by incorporating <APPLET> tags. Browsers that support the <APPLET> tag (Netscape Navigator 2.0, Microsoft Internet Explorer 3.0 and Sun's HotJava), download the compiled Java applications and execute them.

JavaScript is a series of extensions to the HTML language designed by the Netscape Corporation and understood by Netscape Navigator versions 2.0 and higher, as well as by Microsoft Internet Explorer version 3.0 and higher. It's an interpreted language designed for controlling the browser; it has the ability to open and close windows, manipulate form elements, adjust browser settings, and download and execute Java applets.

Although JavaScript has a similar syntax to Java, it is quite distinct in many ways.

Q61: Are there any known security holes in Java?

Java scripts, because they execute on the browser's side of the connection instead of on the server's, move the security risk squarely from the server to the client. Is there anything for the client to worry about?

Several failsafes are built into Java to prevent it from compromising the remote user's machine. When running as applets, Java scripts are restricted with respect to what they are allowed to do by a "security manager" object. The security manager does not ordinarily allow applets to execute arbitrary system commands, to load system libraries, or to open up system device drivers such as disk drives. In addition, scripts are generally limited to reading and writing to files in a user-designated directory only (the HotJava browser allows you to set this directory, while Netscape disallows all file manipulation).

Applets are also limited in the network connections they can make: An applet is only allowed to make a network connection back to the server from which it was downloaded. This is important for reasons discussed below.

Finally, the security manager allows Java applets to read and write to the network, read and write to the local disk, but not both. This limitation was created to reduce the risk of an Applet spying on the user's private documents and transmitting the information back to the server. Since the Netscape implementation disables all local file manipulation anyway, this restriction is currently moot.

Security holes

Unfortunately in the short time since its release, a number of security holes have been found in Java caused by bugs in the implementation. Although most of the worst bugs have been fixed in the current release, at least one serious security hole remains and there are a number of worrisome potential vulnerabilities in the design of the language itself, not least of which is the Java Security: From HotJava to Netscape and Beyond, a paper published by Drew Dean, Edward Felten and Dan Wallach in the 1996 IEEE Symposium on Security and Privacy, presents a complete of anatomy of Java security holes and concludes with the following sobering assessment:
We conclude that the Java system in its current form cannot easily be made secure. Significant redesign of the language, the bytecode format, and the runtime system appear to be necessary steps toward building a higher-assurance system.

Because of the current problems with Java, the safest course is to turn Java off (from the Netscape Security Preferences menu item) except when retrieving URLs from well-known and trusted hosts.

Below are some of the specific holes present in the Java implementation distributed with Netscape 2.0 and/or 2.01.

Ability to Execute Arbitrary Machine Instructions

On 22 March 1996, Drew Dean ( ddean@CS.Princeton.EDUand Ed Felton ( felten@CS.Princeton.EDU) of the Princeton Dept of Computer Science, announced that they had successfully exploited a bug in Java to create a applet that deletes a file on the user's local disk. In this bug, a binary library file is first downloaded to the user's local disk using the Netscape caching mechanism. The Java interpreter is then tricked into loading the file into memory and executing it.

This bug is present in version 2.0 of Netscape as well as the recent 2.01 "security enhancements" release. Although the bug was demonstrated on a Unix system, it appears that Windows systems are vulnerable as well.

More information on this bug can be found at

Vulnerability to Denial of Service Attacks

Applets can hog system resources such as memory and CPU time. This may happen as the result of a programmer error, or maliciously in order to slow down the computer system to the point of unusability. Applets running under the same browser are not protected from one another. One applet can easily discover another's existence and interfere with it, raising the interesting spectre of one vendor's applet deliberately making a competitor's applet appear to behave erratically.

If an applet appears to be behaving improperly, closing the page from which it originated does not necessarily shut it down. It may be necessary to shut off the browser entirely.

Ability to Make Network Connections with Arbitrary Hosts

Version 2.0 of Netscape Navigator contained another Java bug, this one involving the restriction on Applets from contacting arbitrary hosts. This bug has been fixed in version 2.01 of Netscape, and you should upgrade to a more current version if you haven't already.

Applets are supposed to be able to talk only to the server that they originated from. However in early March 1996, Steve Gibbons (a href="" and Drew Dean (ddean@CS.Princeton.EDU) independently discovered holes in the implementation that allows Applets to make connections to any host on the Internet. This is a serious problem: once downloaded to a user's machine, the applet can now attempt to make a connection to any machine on the user's local area network, even if the LAN is protected by a firewall. Many LANs are set up so that local machines are trusted to access services that distant machines are not. As a trivial example, an Applet could open up a connection to the organization's private news server, fetch recent postings to an internal newsgroup, and transmit them back to a foreign host.

Unix users who are familiar with the Berkeley rsh, rlogin and rcp commands will see that this bug represents a risk to systems that trust each other enough to allow commands to be executed remotely. This bug also makes it possible for Applets to collect detailed information on network topology and name services from behind a firewall.

This security hole involves Java's trusting use of the Domain Name System (DNS) to confirm that it is allowed to contact a particular host. A malfeasant using his own DNS server can create a bogus DNS entry to fool the Java system into thinking that a script is allowed to talk to a host that it is not authorized to contact.

More information about Java and security can be found at URL:

Q62: Are there any known security holes in JavaScript?

JavaScript also has a troubling history of security holes, three of which have persisted despite the Netscape developers' attempts to close them.

Unlike the Java hole, which can actively damage the user's machine, the JavaScript holes all involve infringements on the user's privacy. The following holes exist in Netscape versions 2.0 and 2.01. They were discovered and publicized by John Robert LoVerso of the OSF Research Institute (

  1. JavaScripts can trick the user into uploading a file on his local hard disk or network mounted disk to an arbitrary machine on the Internet. Although the user must click a button in order to initiate the transfer, the button can easily masquerade as something innocent. Nor is there any indication that a file transfer has occurred before or after the event. This is a major security risk for systems that rely on a password file to control access, because a stolen password file can often be readily cracked.
  2. JavaScripts can obtain directory listings of the user's local hard disk and any network mounted disks. This represents both an invasion of privacy and a security risk, since an understanding of a machine's organization is a great advantage for devising a way to break into it.
  3. JavaScripts can monitor all pages the user visits during a session, capture the URLs, and transmit them to a host somewhere on the Internet. This hole requires a user interaction to complete the upload, but as in the first example the interaction can be disguised in an innocuous manner.
  4. JavaScripts can trigger Netscape Navigator into sending off e-mail messages without the user's knowledge. This technique can be used to capture user's e-mail addresses.
A description of these bugs can be found at:

All of these JavaScript bugs have been closed in Netscape Navigator versions 3.0 and higher. The exception is the e-mail address capture hole, which was closed in version 2.01 but reappeared again in version 3.0. This hole has again been closed in version 3.01, which offers a checkbox in the Network & Security Options dialog box to warn you before Navigator sends e-mail in your name. Microsoft Internet Explorer, which supports a dialect of JavaScript, has a similar option in its Options window.

People who worry about undiscovered JavaScript security holes may elect to turn it off completely (using the checkbox in the Network & Security Options dialog) except when retrieving URLs from well-known and trusted hosts.

Q63: What is ActiveX? Does it pose any risks?

ActiveX is a technology developed by the Microsoft Corporation for distributing software over the Internet. Like Java Applets, an ActiveX "control" can be embedded in a Web page, where it typically appears as a smart interactive graphic. A number of ActiveX controls are available for the Microsoft Internet Explorer (the only browser to support them so far), including a scrolling marquee, a background sound generator, and an ActiveX control that executes Java applets. Unlike Java, which is a platform-independent programming language, ActiveX controls are distributed as executable binaries, and must be separately compiled for each target machine and operating system.

The ActiveX security model is considerably different from Java applets. Java achieves security by restricting the behavior of applets to a set of safe actions. ActiveX, on the other hand, places no restrictions on what a control can do. Instead, each ActiveX control can be digitally "signed" by its author in such a way that the signature cannot be altered or repudiated. The digital signatures can then be certified by a trusted "certifying authority", such as VeriSign, to create the equivalent of a shrink-wrapped software package. If you download a signed ActiveX control and it crashes your machine, you'll at least know who to blame.

This security model places the responsibility for the computer system's security squarely on the user's head. Before the browser downloads an ActiveX control that hasn't been signed at all, or that has been signed but certified by an unknown certifying authority, the browser presents a dialog box warning the user that this action may not be safe. The user can elect to abort the transfer, or may continue the transfer and take his chances.

The ActiveX certification process ensures that ActiveX controls cannot be distributed anonymously and that a control cannot be tampered with by third parties after its publication. However, the certification process does not ensure that a control will be well-behaved. Although it is unlikely that signed and certified ActiveX controls will behave in a malicious fashion, it is not impossible. To illustrate this point, software developer Fred McLain ( recently published an ActiveX control named Exploder. This control, which has been fully signed and certified, performs a clean shutdown of any Windows95 machine that downloads it. The shutdown occurs automatically soon after the user views an HTML page that contains the Exploder control (using Microsoft Internet Explorer version 3.0 or higher). While Exploder does not cause any data loss, a less friendly control might reformat the user's hard disk or plant a virus. In fact, it's conceivable that an ActiveX control could take some subtle action, such as transmitting confidential configuration information from the user's computer to a server on the Internet, that would escape detection for a long period of time.

ActiveX can be turned off completely from the Options menu of Microsoft Internet Explorer. Look for references to "active content" and choose the "most secure" option.

Q64: Do "Cookies" Pose any Security Risks?

A "cookie" is a mechanism developed by the Netscape Corporation to make up for the stateless nature of the HTTP protocol. Normally, each time a browser requests the URL of a page from a Web server the request is treated as a completely new interaction. The fact that the request may be just the most recent in a series of requests as the user browses methodically through the site is lost. Although this makes the Web more efficient, this stateless behavior makes it difficult to create things like shopping carts that must remember the user's actions over an extended period of time.

Cookies solve this problem. A cookie is a small piece of information, often no more than a short session identifier, that the HTTP server sends to the browser when the browser connects for the first time. Thereafter, the browser returns a copy of the cookie to the server each time it connects. Typically the server uses the cookie to remember the user and to maintain the illusion of a "session" that spans multiple pages. Because cookies are not part of the standard HTTP specification, only some browsers support them: currently Microsoft Internet Explorer 3.0 and higher, and Netscape Navigator 2.0 and higher. The server and/or its CGI scripts must also know about cookies in order to take advantage of them.

Cookies cannot be used to "steal" information about you or your computer system. They can only be used to store information that you have provided at some point. To give a benign example, if you fill out a form giving your favorite color, a server can turn this information into a cookie and send it to your browser. The next time you contact the site, your browser will return the cookie, allowing the server to alter background color of its pages to suit your preferences.

However cookies can be used for more controversial purposes. Each access your browser makes to a Web site leaves some information about you behind, creating a gossamer trail across the Internet. Among the tidbits of data left along this trail are the name and IP address of your computer, the brand of browser you're using, the operating system you're running, the URL of the Web page you accessed, and the URL of the page you were last viewing. Without cookies, it would be nearly impossible for anyone to follow this trail systematically to learn much about your Web browsing habits. They would have to reconstruct your path by correlating hundreds or thousands of individual server logs. With cookies, the situation changes considerably.

The DoubleClick Network is a system created by the DoubleClick Corporation to create profiles of individuals using the World Wide Web and to present them with advertising banners customized to their interests. DoubleClick's primary customers are Web sites looking to advertise their services. Each member of the DoubleClick Network becomes a host for the advertising of other members of the network. When a Web site joins DoubleClick it creates advertisements for its services and submits them to DoubleClick's server. The Web site then modifies its HTML pages to include an <IMG> graphic that points to DoubleClick. When a user goes to view one of these modified HTML pages, her browser makes a call to DoubleClick's server to retrieve the graphic. The server chooses one of its member's advertisements and returns it to the browser. If the user reloads the page, a different advertisement appears. If the user clicks on the graphic, her browser jumps to the advertised site. Currently many hundreds of sites belong to DoubleClick.

From the user's point of view DoubleClick's graphics appear no different from any other Web advertisement, and there's no visible indication of anything special about the graphic. However, there is an important difference. When a user first connects to the DoubleClick server to retrieve a graphic, the server assigns the browser a cookie that contains a unique identification number. From that time forward whenever the user connects to any Web site that subscribes to the DoubleClick Network, her browser returns the identification number to DoubleClick's server, allowing the server to recognize her. Over a period of time DoubleClick compiles a list of which member sites the user has visited and revisited, using this information to create a profile of the user's tastes and interests. With this profile in hand the DoubleClick server can select advertising that is likely to be of interest to the user. It can also use this information to compile valuable feedback for its member Web sites, such as providing them with audience profiles and rating the effectiveness of the advertisements.

Although names and e-mail addresses are not part of the information that DoubleClick records, other information that the browser leaves behind is sufficient, in many cases, to identify the user. See Server Logs and Privacy for more information. For this reason many people are uncomfortable with DoubleClick's use of cookies. To find out whether you have been tracked by DoubleClick, examine your browser's cookies file. On Unix systems using Netscape, the cookies file can be found in your home directory in the file ~/.netscape/cookies. If a line like this appears: FALSE / FALSE 942195440 IAA d2bbd5
then you are carrying a DoubleClick cookie.

Windows users will find the equivalent information in the file cookies.txt, located in their C:\Programs\Netscape\Navigator directory, while Macintosh users should look in their System Folder under Preferences:Netscape. Users of Microsoft Internet Explorer should examine the files located in C:\Windows\Cookies.

Current versions of both Netscape Navigator and Internet Explorer offer the option of alerting you whenever a server attempts to give your browser a cookie. If you turn this alert on, you will have the option of refusing cookies. You should also manually delete any cookies that you have already collected. The easiest way to do this is to remove the cookies file entirely.

The drawback to this scheme is that many servers will offer the same cookie repeatedly even after you refuse to accept the first one. This rapidly leads to a nuisance situation. Before you panic over cookies, it's worth remembering that the vast majority of cookies are benign attempts to improve your Web browsing experience, not intrusions on your privacy.

Lincoln D. Stein,
Whitehead Institute/MIT Center for Genome Research
Last modified: Fri Nov 8 02:48:23 EST 1996