If the only benefit of downloading code from the web and running it locally was fancier dancing icons, then this would be a very short paper: it would say, "don’t do it". On the Internet today, servers provide real-time services to thousands of clients simultaneously. They do it over relatively slow networks and they provide the services on an ad-hoc basis, i.e. the clients were not designed with these specific services in mind. Today’s servers download code and data to clients. Clients execute the code and perhaps return processed data. Downloading code specific to the service being provided and executing as much of the application as practical on the client helps insulate end users from network latency and server computational bottlenecks far better than the alternative of using the client as a terminal to accept input and display output. Similarly, automatically downloading program upgrades or browser extensions helps increase the seamless nature of the computing experience, and potentially saves much time and hassle for the user.

Downloading a program and running it locally provides that program the ability to do almost anything you can do when you sit at your computer. For example it might be able to:

• Modify your local information
• Access other computers as if it were you
• Send e-mail signed by you
• Execute a virus or Trojan horse
• Purchase goods or transfer funds as if it were you
• Change security settings
• And good stuff too

Of course, if your e-mail program requires that you type in a password before it will electronically sign your mail, and if that password is not stored anywhere on your system, then a rogue program cannot send e-mail on your behalf. However, it might be able to discover your password by monitoring the next time you type it in. The point here is not to be alarmist, but to illustrate that executing code obtained from someone else, allowing "guest code" into your system, is serious business, and deserves serious consideration. Even if the author intended no harm, it is possible that the code has a bug or feature that could unintentionally harm the host running it. For instance, the guest program might create a directory called tempfor storing temporary data while it is running, and then clean up when it has finished by removing the tempdirectory. If you already had a directory called tempwhich you used for storing valuable, but temporary data, your data could be erased when the guest program runs.

One approach to safety is to insulate the host from the guest program by limiting what the guest program can do. There are many ways the guest program can be limited. For instance:

• Limit what the program can try to do (require the program to be written in a limited-function language)
• Limit what the program can actually do (use access controls to limit the program to actions that you approve of)
• Search the code for viruses or Trojan horses before letting it run (virus scanners and the like)
• Manually limit the code’s behavior by asking the operator for permission (ask the user)

Every Web browser interprets limited function languages designed to protect the client from unwanted Web server interactions. Perhaps the best known example of a limited browser language is HyperText Markup Language (HTML). HTML has an instruction set which has been carefully limited to displaying text and graphics, transporting files to the client, and retrieving text typed into forms displayed at the client. There are no HTML commands to read or write specific files stored on the system, or to perform mathematical calculations. The continual desire for increased web browser functionality has led to extensions to HTML like, Dynamic HyperText Markup Language (DHTML) and Extensible Markup Language (XML) which are based on the same limited function concept, but provide additional capabilities without crossing the line into a full function language. Scripting languages such as JavaScript and VBScript go even further toward allowing full programmability of Web pages, without allowing full access to the system’s resources.

Java is a language that was designed with security in mind. One of the design criteria for the language was that programs could be monitored to control their access to system resources. For instance, when a Java program attempts to read or write a file, the Java Security Manager is always called, to determine whether or not the operation should be allowed. If the Java program is an untrusted "Applet" running within your Web Browser, and your browser is sensibly configured not to allow untrusted Applets to read and write files, the operation will fail, and the program will not be allowed to do the reading or writing. The Security Manager is consulted for a variety of operations, including access to the environment and the filesystem, interaction with the network, and the creation of dialog boxes. Limiting Java Applets to a predefined set of limits is sometimes referred to as "running in the sandbox".

Several vendors provide anti-virus programs that integrate with Web browsers or the operating system. When the browser initiates a download of a file type that has been identified by the anti-virus program for scanning, the file will be scanned after it is downloaded but before it is released to the browser. If the file is identified as containing a known virus or Trojan horse, or something sufficiently like one, the anti-virus program takes appropriate actions. Since most virus incidents are caused by already-known viruses, looking for known viruses can be a very effective strategy. Looking for known Trojan horses can also be effective in some cases, but effective Trojan horse prevention requires more than this.

ALIGN="CENTER">Manually limit the code’s behavior by asking the operator for permission

Web browsers are frequently configured to consult with the user before performing any one of a variety of actions. In fact, if all of the notifications are turned on, the browser can easily become unusable due to the sheer number of questions to which the user must respond. The most notorious of the popups is the notification that a web site is trying to read or set a cookie. Under some conditions access to cookies take place at a rate of over 100 per minute. Appropriately used, user prompts can be valuable; however, they are frequently abused, either by overwhelming the user with questions she no longer reads before answering, or asking questions the user is not qualified to answer with authority. A good security system would allow the user to set an overall policy once, and then seldom or never again prompt the user for decisions about specific actions.

Fortification is a powerful technology; if programs can be limited to doing only what they are supposed to do, Trojan horses and related security attacks can be prevented. On the other hand, perfect fortification is impossible; if we knew how to keep programs from doing anything undesirable, we could eliminate not only Trojan horses, but program bugs of all kinds. This is obviously not something we know how to do! More realistic, and therefore imperfect, fortification systems have to strike a balance between requiring the user to make numerous and complex policy decisions, imposing such broad controls that guest programs are prevented from doing anything useful at all, and imposing insufficient controls that allow free reign to attackers.

There are two parts to trusting programs that you run from others: deciding whom to trust, and enforcing your decisions. Signing authorities recognize and help fulfill the need for the first; browser writers recognize and provide lots of technologies to help you with the second.

A digital signature is a number delivered along with a digital object. A digital signature can be used to verify the origin and authenticity of the digital object it came with.

Here is a brief outline of how the system works. In order for an author to digitally sign an object she must first obtain a digital identity. She does this by obtaining a private/public key pair. She keeps the private key hidden where no one else can find it. She publishes the public key where it is easily accessible by all.

When she has an object she wants to digitally sign, she privately feeds her digital object and her private key into a program that generates a number called a digital signature. (At this point she is finished with her private key so she hides it away again.) Generating the digital signature and attaching it to a digital object is called digitally signing the object.

When she sends her signed digital object to someone else, they can separate the digital signature from the object. They can then feed the object, the digital signature, and her public key to a program that uses a mathematical algorithm to ascertain if they all belong together. If they do, then the receiver can be confident that this digital signature was indeed generated by someone in possession of the private key that matches the public key in his possession. If he knows who the public key came from, then he knows where the digital object came from and that it has not been modified since she signed it (assuming that no one else has a copy of her private key; an issue that we’ll mention below). The power of the digital signature comes from the fact that, while it’s easy to check that a given signature matches a given digital object and public key, it’s essentially impossible, given a public key and a digital object, to generate a matching signature, if you don’t have the corresponding private key as well.

Key management is critical to the usefulness of a digital signature system. If I go to IBM and pick up their public key then I can verify that any digitally signed program they send me is authentic. Since I trust IBM to be competent and honorable, I am willing to trust the code that came from them once I authenticate it. Of course, there are many other reputable sources for code; will I have to go obtain public keys from all of them as well? This is the problem of public key management. There are literally millions of sources of information on the Web. No one will be able to visit millions of people or organizations to pick up each public key. Digital certificate authorities address this potentially thorny problem.

Digital certificate authorities let you submit a digital object with your public key, name, address and other information necessary to identify you or your organization. They will take this digital object and attempt to verify the information it contains. If they are satisfied that the information is correct, they will sign your object with their private key and give it back to you. This signed object, declaring that a given public key really belongs to you, is known as a certificate. The next time you send out a digital object, you can attach this digital certificate to the object and then sign the entire package. When the receiver of this package tries to verify its authenticity, he will first view the contents of the digital certificate. There he will see the name and address of the document signer (you). Of course, he cannot yet be sure that this information is valid. As long as a certificate authority that he is familiar with has signed the certificate, he can verify the authenticity of the certificate using the authority’s public key. Now he knows that the public key of the author (obtained from the certificate) corresponds to the name and address in the certificate. He uses that public key obtained from the certificate to verify that the entire object has been delivered to him without modification.

Fortunately for all of us, the rather complex manual steps outlined above have been automated in modern Web browsers. When a signed program is received, your browser starts by showing you the digital certificate displayed on your screen, along with the name of the digital certificate signing authority. You can choose to accept or reject the program. You can also direct the browser to remember the author’s public key and automatically accept anything signed with the same key in the future. Web browsers commonly come equipped with the public keys of a number of popular certificate authorities, to bootstrap the process.

Perhaps the greatest danger in this system is that an author’s private key can be stolen. Anyone in possession of the author’s private key can sign packages just as if they came from the private key’s rightful owner. If the private key’s owner knows that their key has been stolen they can notify the signature authority. The signature authority will then label the public key as revoked and so inform any browser which inquires about that public key. The greatest threats are private keys that have been compromised unknown to the rightful owner. Forged documents signed with these keys will be accepted as authentic.

Building fortifications to prevent a program from performing activities that could result in objectionable consequences is a fundamentally proactive approach. The difficulty with being proactive is that it requires anticipating all possible outcomes in advance. The conditions necessary to insure that all possible outcomes will be acceptable are frequently very restrictive. For instance, suppose you found a program on the Web that helped you search for an address in an online phone book, and then automatically added the search results to a file named Addresses on your hard drive. How bad could it be, just one little file? If you give this program the ability to add lines to one little file on the system it could add, "format d:" to a little file called autoexec.bat. Generally speaking, programs that write to your hard drive pose an unacceptable risk of damage. Unless you trust the author, or can analyze the code yourself, you probably would not want to allow this program to run, even if you desired the function. This is the way the Java sandbox model works: Java would monitor the program, see that it is attempting to write to the hard drive, and then prevent it from doing so.

An alternative approach to protecting your files would be to allow you to specify, for each file that a program might want to access, whether or not the access should be allowed. This would be difficult in practice, though. Making the decision in advance for each of thousands of files would be infeasible; on the other hand, asking the user to make snap decisions of the form "Should this Web page be allowed to alter the file c:\setup\stark\rebla97.ini?" is not a good basis for system security.

Of course, programs received from a trusted party have the ability to cause damage just the same as programs received from untrusted parties. It does not matter how much you trust an author, given enough opportunities, any author will eventually write a program that causes a problem for you. The reason you trust the author is because you believe the risk is acceptably small. If a problem occurs, then you know who the author is and you can complain, or at least let the author know about the problem so he can fix it. Trust is a fundamentally reactive approach in that no effort is expended until there is a problem. One potential problem with relying entirely on trust and retribution is that the same malicious program that damages your data may also erase your record of where it came from.

As is usually the case, the best results are achieved by building on the strengths of each approach. In the next section we will discuss the classes of programs that current browsers execute, and the security models which are applied to each of them in an attempt to exercise both fortification and levels of trust.

In the next sections, we consider some of the features of two popular Web browsers, Microsoft Internet Explorer Explorer and Netscape Navigator, as they relate to the security of downloaded programs. Browsers run many different programs. In order to organize the discussion we will use the following (somewhat arbitrary) taxonomy to divide the programs browsers run into three classes.

• Programs that are functionally within in the browser
• Interpreters for HTML, DHTML, XML,
• JavaScript, Java applets, etc.

Programs that are functionally within the browser all interpret limited function or access-controlled languages in an effort to make them safe for arbitrary input received from untrusted sources. These programs are all configured within the browser and are each subject to security concerns. Java Applets are an interesting case, because the limitations on the language can be tailored to each applet based on its origin (i.e. who signed it).

• Programs installed to extend the browser
• Navigator plug-ins such as the RealAudio plug-in
• Internet Explorer ActiveX controls

The writers of both Internet Explorer and Netscape Navigator realize that one of the great strengths of Web browsers is their ability to be extended. More often than not, extensions to browsers require unrestricted access to the operating system in order to accomplish their goals. Programs that extend browsers enjoy full function interfaces to the operating system and to the internals of the browsers. Navigator plug-ins have no architected mechanism for enforcing digital signing, in contrast to Internet Explorer ActiveX controls which can optionally be required to have digital signatures before they are installed. Once an ActiveX control is installed however, it has free run of the machine.

• Programs started by the browser but executed by the OS
• Programs already installed e.g. download a doc file and start Microsoft Word to process it
• Arbitrary downloaded programs

The browsers we are considering will only start locally installed programs in response to a Web server request if they locate an entry for the associated data type in a locally maintained database. This database associates typed input data with the programs that are to be used to process the input data. Entering a program in this database is typically refereed to as registering the program. For instance, Microsoft Word or the Word Viewer may be registered as the program associated with files whose extension is "doc".

Browsers can also start normal executable programs downloaded over the web. When a user clicks on a link pointing to a file with MIME type "file/executable" (as indicated by the server when it delivers the file), the browser will look in the database to ascertain what to do with the file. The default action entry for file/executable is typically to ask the user if the program should be launched, or saved to disk.

In either of the above cases, the registration database can be configured such that to the browser startsstart programs automatically without prompting the user.

Summaries of the languages and interfaces browsers employ along with their characteristics are outlined in Fig. 1.

This section gives just some of the details of how to find out your browser’s current security settings, and how to modify them to meet your needs. The main lesson to come away with, beyond the details of menus and mouse-clicks, is that the security and configuration infrastructures of these systems are extremely complex, and not simple to understand or correctly utilize. We can only hope that they will become simpler with time!

The examples and conclusions in these sections are based on experimentation with the browsers and operating systems in question, and a (generally fruitless) attempt to find relevant details in the published documentation. Because of the complexity of the systems, the number of different programs explicitly and implicitly involved, and the many different versions of these programs currently in use, your mileage may vary: where we found a setting on by default, you may find that it’s off. Where we got one result from one order of software installation, you may get the opposite result if you install the programs in some other order. Such is the nature of workstation software in 1998. The following roadmaps were developed under Windows 98, using Internet Explorer 4.01 and Netscape Navigator 4.05.

Working with programs that are functionally contained within the browser

Safe for Scripting

One of the challenges in complex environments is to understand the implications of how all the pieces work together. This is particularly complicated in a dynamic browser environment where programs may interact with each other in unanticipated ways. One example of this effect is the way JavaScript or VBScript programs interact with ActiveX controls under Now that we have looked at programs that extend the browser, the "Scripting" section of Figure 2 is worth a short digression. In Internet Explorer. By design, , Web-downloaded programs written in JavaScript or VBScript are restricted so they cannot directly access many system resources (such as files and environment variables) as discussed in the earlier section on limited function languages. But these programs can invoke, or attempt to invoke, ActiveX controls which have unrestricted access to your operating system. . In the previous section we discussed the techniques Internet Explorer employs to prevent you from installing ActiveX controls unless they were signed by a party you trust. It is not unusual to visit sites where you will receive JavaScript or VBScript programs along with one or more signed ActiveX controls that augment the functionality of the JavaScript or VBScript. In such cases you have received programs from a party you trust. In order for the ActiveX control to interact with its JavaScript or VBScript companion it must contain an internal parameter set by the ActiveX control’s author that indicates the ActiveX control is safe for scripting. The level of complexity becomes more apparent when you consider that once an ActiveX control is marked as safe for scripting, any JavaScript or VBScript program from any source can attempt to interact with it. There is a configuration setting in the Internet Explorer security settings (shown in Fig. 2) which allows you to prevent JavaScript or VBScript from interacting with ActiveX controls even those controls marked Safe for Scripting, however the (as shipped) default for Internet Explorer is to allow interaction.

In theory, ActiveX authors should never mark a control as "Safe for Scripting" unless the control will never, regardless of what arguments it is passed, do anything undesirable to your system. In practice, achieving this is a very difficult task: some ActiveX authors probably do not take the requirement as seriously as they should, and others no doubt attempt to, but fail. C; creating perfectly secure code is very difficult, and even moderately secure code requires considerable expertise and testing. When you install an ActiveX control that is marked Safe for Scripting, not only are you trusting the author himself not to have any ill intent, but you are assuming that his code cannot be abused by others to do you harm. For instance, if an ActiveX control contains a function that will take an arbitrary string of characters and execute it as an operating system command, that control should never be marked "Safe for Scripting". If an attacker found such an ActiveX control on the Web signed by someone you trust they could, since an attacker could create a Web page that first caused the ActiveX control to be installed the control (and, if the control was signed by someone you trusted, you would allow that installation) and then abused the control's execution function to erase critical files on your system, or format your hard drive. Subtler features that make a control unsafe for scripting include the ability to read and write files, access environment variables, alter the Registry, and so on.

In order to ascertain which programs Netscape Navigator will start when it encounters input data from a Web server, you can examine its program registration database by choosing Edit® Preferences® Applications from the Navigator main window, which will display a dialog similar to that shown in Fig. 9. These dialogs work similarly to the Windows dialogs shown in Fig. 8, but they are contained within the browser itself, rather than the operating system. On the other hand, Netscape appears to be using the same underlying database as Internet Explorer (changes made to some settings in the Navigator dialogs are reflected in the corresponding operating system dialogs). Netscape simply provides another interface, within the browser, to these settings.

Working with digital signatures: Whom does my browser trust?

When a signed Java Applet executing under Internet Explorer needs privileges beyond those which you have configured it will put up a dialog box similar to the one shown in Fig. 15 requesting additional privileges.