At the same time, scripting also adds to the power of an adversarial entity. A user might visit a dubious site (crook.com) and (unknowingly) download scripts. Indeed, in the summer of 1997 we reported in [CERT97,AM98] an attack against both JavaScript and VBScript that allows a hostile entity to plant a Trojan Horse script in a user's browser. This script subsequently reports back all Web activity - URLs visited, private data supplied by the user in a Web form, e.g., credit card numbers, social security numbers, company passwords, etc. Such an attack works even when the user employs encryption (e.g., SSL) or when a user is behind a firewall, because the data is captured from the browser inside the firewall, before it is encrypted. We further learned that other people had discovered a series of security flaws in earlier browser versions (see [L96] for an overview). Unfortunately, the ``tradition'' of security weaknesses being discovered did not stop with us (see [K98] for an overview).
In March of 1998, Netscape decided to make the Navigator source code available to the public (under the name ``Mozilla''). We consequently decided to implement a new security model for JavaScript in Mozilla. A technical description of the security primitives used in our model can be found in [AM98b].
We gave a demo of an early prototype ``Bell Labs Mozilla'' to Netscape in late fall of 1998. Given the positive feedback, we then went on to complete ``our'' Mozilla and ship it to Netscape in March 1999. As of this writing, our contacts at Netscape started to integrate our code into Navigator 5.0, currently scheduled for release in late fall, 1999. Check www.mozilla.org for updates on the progress of Mozilla.
In this paper we focus on how our new model benefits both the end user who surfs the Web and the JavaScript programmer who designs the Web sites that the end user visits. We also devote some of the discussion on our implementation experience integrating our model into the existing Mozilla source code base.