7.3. Applet Security
One of the most important features of Java is its security model.
It allows untrusted code, such as applets downloaded from
arbitrary web sites, to be run in a restricted environment that
prevents that code from doing anything malicious, like deleting
files or sending fake email. The Java security model has evolved
considerably between Java 1.0 and Java 1.2 and is covered in
detail in Java in a Nutshell.
To write applets, you don‘t need to understand the entire Java
security model. What you do need to know is that when your applet
is run as untrusted code, it is subject to quite a few
security restrictions that limit the kinds of things it can do.
This section describes those security restrictions and also
describes how you can attach a digital signature to applets, so
that users can treat them as trusted code and run them in a less
restrictive environment.
The following list details the security restrictions that are
typically imposed on untrusted applet code. Different web
browsers and applet viewers may impose slightly different security
restrictions and may allow the end user to customize or
selectively relax the restrictions. In general, however, you
should assume that your untrusted applet are restricted in the
following ways:
-
Untrusted code cannot read from or write to the local
filesystem. This means that untrusted code cannot:
-
Read files
-
List directories
-
Check for the existence of files
-
Obtain the size or modification date of files
-
Obtain the read and write permissions of a file
-
Test whether a filename is a file or directory
-
Write files
-
Delete files
-
Create directories
-
Rename files
-
Read or write from FileDescriptor objects
-
Untrusted code cannot perform networking operations, except in
certain restricted ways. Untrusted code cannot:
-
Create a network connection to any computer other than the
one from which the code was itself loaded
-
Listen for network connections on any of the privileged
ports with numbers less than or equal to 1,024
-
Accept network connections on ports less than or equal to
1,024 or from any host other than the one from which the
code itself was loaded
-
Use multicast sockets
-
Create or register a SocketImplFactory,
URLStreamHandlerFactory, or
ContentHandlerFactory
-
Untrusted code cannot make use of certain system
facilities. It cannot:
-
Exit the Java interpreter by calling System.exit()
or Runtime.exit()
-
Spawn new processes by calling any of the
Runtime.exec() methods
-
Dynamically load native code libraries with the
load() or loadLibrary() methods of
Runtime or System
-
Untrusted code cannot make use of certain AWT facilities.
One major restriction is that all windows created by
untrusted code display a prominent visual indication
that they have been created by untrusted code and are
"insecure."
This is to prevent
untrusted code from spoofing
the on-screen appearance of trusted code. Additionally,
untrusted code cannot:
-
Untrusted code has restricted access to system properties.
It cannot call System.getProperties(), so it cannot
modify or insert properties into the system properties list.
It can call System.getProperty() to read individual
properties but can read only system properties to which it
has been explicitly granted access. By default,
appletviewer grants access to only the following 10
properties. Note that user.home and
user.dir are excluded:
-
java.version
-
java.class.version
-
java.vendor
-
java.vendor.url
-
os.name
-
os.version
-
os.arch
-
file.separator
-
path.separator
-
line.separator
-
Untrusted code cannot create or access threads or
thread groups outside of the thread group in which the
untrusted code is running.
-
Untrusted code has restrictions on the classes it can load
and define. It cannot:
-
Explicitly load classes from the sun.* packages
-
Define classes in any of the java.* or
sun.*
packages
-
Create a ClassLoader object or call any
ClassLoader methods
-
Untrusted code cannot use the java.lang.Class
reflection methods to obtain information about nonpublic
members of a class, unless the class was loaded from the
same host as the untrusted code.
-
Untrusted code has restrictions on its use of the
java.security package. It cannot:
-
Manipulate security identities in any way
-
Set or read security properties
-
List, look up, insert, or remove security providers
-
Finally, to prevent untrusted code from circumventing all of
these restrictions, it is not allowed to create or register a
SecurityManager object.
7.3.1. Local Applets
When an applet is loaded from the local filesystem, instead of
through a network protocol, web browsers and applet viewers may
relax some, or even many, of the preceding restrictions. The reason
for this is that local applets are assumed to be more
trustworthy than anonymous applets from the network.
Intermediate applet security policies are also possible. For
example, an applet viewer can be written so that it places
fewer restrictions on applets loaded from an internal corporate
network than on those loaded from the Internet.
7.3.2. Signed Applets
Java 1.1 added the ability to attach a digital signature to a JAR
file that contains an applet. This signature securely identifies
the author or origin of an applet. If you trust the author or
originating organization, you can configure your web browser or
applet viewer to run applets bearing that signature as trusted
code, rather than as untrusted code. Such an applet runs
without the onerous security restrictions placed on untrusted
applets. Java 1.2 platform actually allows the security policy to be
customized based on the origin of an applet. This means that an
end user or system administrator may define multiple levels of
trust, allowing fully trusted applets to run with all the
privileges of a standalone application, while
partially trusted applets run with a reduced list of security
restrictions.
The process of attaching a digital signature to an applet‘s JAR
file is platform dependent. In Java 1.1, you use the
javakey program. In Java 1.2, this program
has been superseded by jarsigner. Netscape
and Microsoft also provide their own digital signature programs
that are customized for use with their browsers.
The process of telling your web browser or applet viewer which
digital signatures to trust is also vendor dependent, of course.
In Java 1.1, you use javakey to specify
which signatures are trusted. In Java 1.2, you use a different
tool, policytool, to specify trusted
signatures and the security policies
associated with them. See Java in a
Nutshell for further details.
|