Browser-Specific Security Rules (Ch. 2, Sec. 11) [Securing Java]

The Base Java Security Model: The Original Applet Sandbox
CHAPTER SECTIONS: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9 / 10 / 11 / 12 / 13

Section 11 -- Browser-Specific Security Rules

Security Manager, are meant to be defined by application authors (including browser vendors) through subclassing. The rules that Web browsers enforce make up the security policy defined by a particular vendor. Ultimately, Netscape could decide to implement different rules than Microsoft.

Of course, every browser's security implementation depends entirely on the rest of the security model being properly defined. Critical pieces of the Java environment directly affecting security include the Java VM, and the built-in libraries. If any of these pieces have errors, the entire security system will break, regardless of which vendor does the other parts.

Netscape Navigator and Microsoft Internet Explorer

All Netscape Navigator versions subsequent to 2.0 are Java enabled. All Microsoft Internet Explorer versions subsequent to 3.0 also include Java. It is, however, very easy to disable Java in both kinds of browsers as long as you can find the right dialog box (see Chapter 4). There is a toggle switch for the entire Java environment. In both Netscape Navigator and Internet Explorer, Java is enabled by default.

The two browsers' security policies are, at the present time, very similar. Both are somewhat strict. The following rules apply to all untrusted applets running under Netscape Navigator and Internet Explorer:

Applets cannot read or write files locally.
Applets cannot open a client-side network connection to any machine other than the applet's origin host. Applets after JDK 1.1 can open a server socket as long as the port number is greater than the privileged port number on the machine (usually 1024).
Applets can read only nine system properties. This allows an applet to access information such as the vendor who created the Java VM, the VM version number, the file separation character (either \ or /), the character used to separate lines, and so on. Applets are not permitted to read any other system properties.
If an applet is loaded using the file: URL, and it does not reside in a directory in CLASSPATH, it is loaded by an Applet Class Loader.

There is no reason that all future browser vendors will choose to implement similar security policies. That two major vendors now do so is probably an artifact of Java's short history. Once browsers begin to implement different policies, security issues will become more complex.

We can see a split among vendors happening already with the 4.x versions of Netscape Navigator and Internet Explorer. Both products offer complex security models based on digital signatures and partial trust. Although the models are quite similar to each other and to the model defined by Java 2, there are many detailed differences that annoy developers and users.

One side effect of the common ground between different vendors' Java security implementations was that early on in Java's history, security holes often cut across all Java implementations. That is, the same problem would be exploitable in all Java VMs, regardless of the browser. These days, it is more common for errors to be relegated to one browser or another. We have more to say about vendors, implementations, and security holes in Chapter 5.

Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Front -- Contents -- Help