There are three security-related areas in OJI:
For general information about security and applets, see Java Plug-in Security.
Previous to Netscape 6, Netscape had its own security model and its own signing
method called Netscape
Object Signing. The Object-Signing Tools could be used to sign a Java applet
so that it could be executed in the JVM. Netscape also provides a set of Java
classes, netscape.security
, that is used by the applet to enable
security in the browser.
In Netscape 6, two mechanisms may be used for applet signing:
In Netscape 4 an applet must call into the netscape.security
package
to enable a privilege even if the applet is signed. If it does not, it
will be treated as untrusted. Thus applet signing and granting of privileges
are treated separately.
In Netscape 6, signed applets are directly supported by the Java Plug-in. When the browser encounters a signed applet, a security dialog is automatically popped up. The applet does not have to call any method to enable privileges; privileges are already enabled.
However, so that Netscape 4 applets will continue to work in Netscape 6, a
stub class for the netscape.security
package has been included.
The stub class does nothing other than allow the applet to load into Java Plug-in
as though it were loading in Netscape 4.
With this release of Java Plug-in, HTTPS is completely handled by the browser. Thus, anything related to HTTPS, such as the service certificate, can be configured through the browser.
LiveConnect allows bi-directional communication between Java and JavaScript. But such communication can present security problems. For instance, suppose an applet and a web page originate from different hosts. Without a security policy, the applet might request sensitive information from a page through a call to JavaScript. Since an applet is allowed to connect to any host, it might then send such information out over the network in an irresponsible manner. A security policy has been implemented to prevent such actions from occurring.
Each direction of communication is considered separately below.
In JavaScript-to-Java communication, a call from JavaScript to an applet is allowed only if one or both of the following is true:
UniversalBrowserRead
permission is
enabled for JavaScript.Without 1 or 2 being true, no call will be allowed from JavaScript to Java.
Given that a call is allowed, then there are two possibilities: JavaScript will have default or all permissions.
Permissions are determined by checking JavaScript signing:
UniversalJavaPermissions
, then it will be
granted all permissions.UniversalJavaPermissions
, then
permissions will depend on local Java policy, which is set by the JRE in the
browser. Local Java policy will consider the origin of the JavaScript, determine
a set of permissions based on origin, then perform actions on the Java side
accordingly.Note that to access an applet from JavaScript, the applet tag will need to
specify an ID
or NAME
attribute.
A call from Java to JavaScript is allowed only if the applet and JavaScript have the same origin.
Assuming the above condition is met, the applet is checked for its permissions.
If it has all, then JavaScript will perform the requested actions. If the applet
does not have all permissions, then JavaScript checks the origin of the applet
and the SecurityManager
of the browser then determines what actions
the JavaScript engine may perform.
Note that to access JavaScript, Java does so through an instance of the netscape.javascript.JSObject
class. For more information, see How
Java-to-JavaScript Communication Works in Java Plug-in.
Copyright © 2000 Sun Microsystems, Inc. All Rights Reserved. Please send comments to: java-plugin-feedback@java.sun.com |
Java Software |