http://www.javasoft.com/sfaq/ (PC Press Internet CD, 03/1996)
A goal for future releases is to enable loading and authentication of signed classes. This enables browsers to run trusted applets in a trusted environment. That will not make obselete the need to run untrusted applets in a secure way. We are also exploring ways to expand the functionality of unauthenticated applets, without compromising security.
Steve Gibbons also independently suggested this attack scenario: see http://www.aztech.net/~steve/java/
In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host.
In addition, applets loaded over the net are prevented from starting other programs on the client. Applets loaded over the net are also not allowed to load libraries, or to define native method calls. If an applet could define native method calls, that would give the applet direct access to the underlying computer.
There are other specific capabilities denied to applets loaded over the net, but most of the applet security policy is described by those two paragraphs above. Read on for the gory details.
In Netscape Navigator 2.0, applets cannot read or write files at all.
Sun's JDK 1.0 appletviewer allows applets to read files that reside in directories on the access control lists.
If the file is not on the client's access control list, then applets cannot access the file in any way. Specifically, applets cannot
Applets loaded into Netscape Navigator 2.0 can't read files.
Sun's appletviewer allows applets to read files that are named on the
access control list for reading. The access control list for reading
is null by default (in JDK 1.0 and in JDK1.0beta2.) You can allow applets
to read directories or files by naming them in the
acl.read property in your
~/.hotjava/properties file.
Note: The "~" (tilde) symbol is used on UNIX systems to refer to your home directory. If you install a web browser on yourF:\drive on your PC, and create a top-level directory named.hotjava, then your properties file is found inF:\.hotjava\properties.
For example, to allow any files in the directory home/me
to be read by applets loaded into the appletviewer, add this line to
your ~/.hotjava/properties file.
acl.read=/home/meYou can specify one file to be read:
acl.read=/home/me/somedir/somefileUse ":" to separate entries:
acl.read=/home/foo:/home/me/somedir/somefileAllowing an applet to read a directory means that it can read all the files in that directory, including any files in any subdirectories that might be hanging off that directory.
Applets loaded into Netscape Navigator 2.0 can't write files.
Sun's appletviewer allows applets to write files that are named on the access control list for writing. The access control list for writing is empty by default.
You can allow applets to write to your /tmp directory by setting the acl.write property in your ~/.hotjava/properties file:
acl.write=/tmpYou can allow applets to write to a particular file by naming it explicitly:
acl.write=/home/me/somedir/somefileUse : to separate entries:
acl.write=/tmp:/home/me/somedir/somefile
Bear in mind that if you open up your file system for writing by applets, there is no way to limit the amount of disk space an applet might use.
In both Netscape Navigator 2.0 and the appletviewer, applets can read
these system properties by invoking
System.getProperty(String key):
key meaning ____________ ______________________________ java.version Java version number java.vendor Java vendor-specific string java.vendor.url Java vendor URL java.class.version Java class version number os.name Operating system name os.arch Operating system architecture file.separator File separator (eg, "/") path.separator Path separator (eg, ":") line.separator Line separatorApplets are prevented from reading these system properties:
key meaning ____________ _____________________________ java.home Java installation directory java.class.path Java classpath user.name User account name user.home User home directory user.dir User's current working directoryTo read a system property from within an applet, simply invoke
System.getProperty(key) on the property you are
interested in.
For example,
String s = System.getProperty("os.name");
There's no way to hide the above ten system properties from applets
loaded into Netscape Navigator 2.0. The reason is that Netscape
Navigator 2.0 doesn't read any files, as a security precaution, including
the ~/.hotjava/properties file.
From the appletviewer, you can prevent applets from finding out
anything about your system by redefining the property in your
~/.hotjava/properties file. For example, to hide the
name of the operating system that you are using, add this line to your
~/.hotjava/properties file:
os.name=null
There's no way to allow an applet loaded into Netscape Navigator 2.0 to read system properties that they aren't allowed to read by default.
To allow applets loaded into the appletviewer to read the property
named by key, add the property
key.applet=true to your ~/.hotjava/property
file. For example, to allow applets to record your user name, add
this line to your ~/.hotjava/properties file:
user.name.applet=true
Applets are not allowed to open network connections to any computer,
except for the host that provided the .class files. This is either
the host where the html page came from, or the host specified in the
codebase parameter in the applet tag, with
codebase taking precendence.
For example, if you try to do this from an applet that did not originate from the machine foo.com, it will fail with a security exception:
Socket s = new Socket("foo.com", 25, true);
Be sure to name the originating host exactly as it was specified when the applet was loaded into the browser.
That is, if you load an HTML page using the URL
http://foo.state.edu/~me/appletPage.htmlthen your applet will be able to connect to its host only by using the name
foo.state.edu. Using the IP address for
foo.state.edu won't work, and using a "shorthand" form of the host
name, like foo.state instead of foo.state.edu, won't work.
There is no explicit support in the JDK 1.0 applet API for persistent state on the client side. However, an applet can maintain its own persistent state on the server side. That is, it can create files on the server side and read files from the server side.
Interesting examples are
No, applets loaded over the net are not allowed to start programs on the client. That is, an applet that you visit can't start some rogue process on your PC. In UNIX terminology, applets are not allowed to exec or fork processes. In particular, this means that applets can't invoke some program to list the contents of your file system, and it means that applets can't invoke System.exit() in an attempt to kill your web browser. Applets are also not allowed to manipulate threads outside the applet's own thread group.
String class. Using immutable strings can help prevent
common runtime errors that could be exploited by hostile applets.
final modifier can be used when initializing a
variable, to prevent runtime modification of that variable. The
compiler catches attempts to modify final variables.
t.currentThread()when
t is not a Thread object causes a
compile time error.
class Parent { protected int x; }
class Child extends Parent { ... }
The class Child can access the field "x"
only on objects that are of type Child (or a subset of
Child.)
For example, programmers can choose to implement sensitive functions as private methods. The compiler and the runtime checks ensure that no objects outside the class can invoke the private methods.
There are two different ways that applets are loaded by a Java system. The way an applet enters the system affects what it is allowed to do.
If an applet is loaded over the net, then it is loaded by the applet class loader, and is subject to the restrictions enforced by the applet security manager.
If an applet resides on the client's local disk, and in a directory that is on the client's CLASSPATH, then it is loaded by the file system loader. The most important differences are
As of 2.0beta4, Netscape Navigator uses the applet class loader to load applets specified with file: URLs. So, the restrictions and protections that accrue from the class loader and its associated security manager are now in effect for applets loaded via file: URLs in NN2.0.
This means that if you specify the URL in the textfield at the top of Netscape Navigator like so:
Location: file:/home/me/public_html/something.htmland the file something.html contains an applet, Netscape Navigator 2.0 loads it using its applet class loader.
Applets loaded over the net are loaded by the applet class loader. For example, the appletviewer's applet class loader is implemented by the class sun.applet.AppletClassLoader.
The class loader enforces the Java name space hierarchy. The class loader guarantees that a unique namespace exists for classes that come from the local file system, and that a unique namespace exists for each network source. When a browser loads an applet over the net, that applet's classes are placed in a private namespace associated with the applet's origin. Thus, applets loaded from different network sources are partitioned from each other.
Also, classes loaded by the class loader are passed through the verifier. The verifier checks that the class file conforms to the Java language specification - it doesn't assume that the class file was produced by a "friendly" or "trusted" compiler. On the contrary, it checks the class file for purposeful violations of the language type rules and name space restrictions. The verifier ensures that
The verifier accomplishes that by doing a data-flow analysis of the
bytecode instruction stream, along with checking the class file
format, object signatures, and special analysis of
finally clauses that are used for Java exception
handling.
Details on the verifier's design and implementation were presented in a paper by Frank Yellin at the December 1995 WWW conference in Boston.
A web browser uses only one class loader, which is established at start-up. Thereafter, the system class loader cannot be extended, overloaded, overridden or replaced. Applets cannot create or reference their own class loader.
The applet security manager is the Java mechanism for enforcing the applet restrictions described above. The appletviewer's applet security manager is implemented by sun.applet.AppletSecurity.
A browser may only have one security manager. The security manager is established at startup, and it cannot thereafter be replaced, overloaded, overridden, or extended. Applets cannot create or reference their own security manager.
The following table is not an exhaustive list of applet capabilities. It's meant to answer the questions we hear most often about what applets can and cannot do.
Key:
Stricter ------------------------> Less strict NN NL AN AL JS read file in /home/me, no no no yes yes acl.read=null read file in /home/me, no no yes yes yes acl.read=/home/me write file in /tmp, no no no yes yes acl.write=null write file in /tmp, no no yes yes yes acl.write=/tmp get file info, no no no yes yes acl.read=null acl.write=null get file info, no no yes yes yes acl.read=/home/me acl.write=/tmp delete file, no no no no yes using File.delete() delete file, no no no yes yes using exec /usr/bin/rm read the user.name no yes no yes yes property connect to port no yes no yes yes on client connect to port no yes no yes yes on 3rd host load library no yes no yes yes exit(-1) no no no yes yes create a popup no yes no yes yes window without a warning
The verifier is independent of Sun's reference implementation of the Java compiler and the high-level specification of the Java language. It verifies bytecodes generated by other Java compilers. It also verifies bytecodes generated by compiling other languages into the bytecode format. Bytecodes imported over the net that pass the verifier can be trusted to run on the Java virtual machine. In order to pass the verifier, bytecodes have to conform to the strict typing, the object signatures, the class file format, and the predictability of the runtime stack that are all defined by the Java language implementation.
Files:
user.name or user.home?
<applet> tag, which tells the browser where to find
the Java .class files. For example,
appletviewer http://foo.com/~jo/coolApplet.html
java interpreter. For example,
java coolApplication
The server is also known as the originating host.
The terms server and client are sometimes used to refer to computers, and are sometimes used to refer to computer programs. For example, www.sun.com is a server, and the httpd process running on www.sun.com is its server process. My computer at home is a client, and the web browser running on my computer at home acts as the client process.
