Version 1.0 Beta2

Frequently Asked Questions - Applet Security

The goal for JDK 1.0 is to enable browsers to run untrusted applets in a
trusted environment. The approach is to be conservative at first, and to add
functionality when it can be added securely. The intent is to prevent
applets from inspecting or changing files on the client file system. Also,
the intent is to prevent applets from using network connections to
circumvent file protections or people's expectations of privacy.

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.
----------------------------------------------------------------------------

Applets
  1. What are applets prevented from doing?
  2. Can applets read or write files?
  3. How do I let an applet read a file?
  4. How do I let an applet write a file?
  5. What system properties can be read by applets, and how?
  6. How do I hide system properties that applets are allowed to read by
     default?
  7. How can I allow applets to read system properties that they aren't
     allowed to read by default?
  8. How can an applet open a network connection to a computer on the
     internet?
  9. How can an applet open a network connection to its originating host?
 10. How can an applet maintain persistent state?
 11. Can an applet start another program running on the client?
 12. What features of the Java language help people build secure applets?
 13. What is the difference between applets loaded over the net, and applets
     loaded via the file system?
 14. What's the applet class loader, and what does it buy me?
 15. What's the applet security manager, and what does it buy me?
 16. Is there a summary of applet capabilities?
 17. If other languages are compiled to Java bytecodes, how does that affect
     the applet security model?
Examples
     Tiny applet examples that demonstrate the security features of your web
     browser.
Glossary
     Terms used in this FAQ.

----------------------------------------------------------------------------

Applets

  1. What are applets prevented from doing?

     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.

  2. Can applets read or write files?

     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
        o check for the existence of the file
        o read the file
        o write the file
        o rename the file
        o create a directory on the client file system
        o list the files in this file (as if it were a directory)
        o check the file's type
        o check the timestamp when the file was last modified
        o check the file's size

  3. How do I let an applet read a file?

     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.0beta2 and later.) 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 your
          F:\ drive on your PC, and create a top-level directory named
          .hotjava, then your properties file is found in
          F:\.hotjava\properties.

     For example, to allow any files in the directory home/mrm to be read by
     applets loaded into the appletviewer, add this line to your
     ~/.hotjava/properties file.

             acl.read=/home/me

     You can specify one file to be read:

             acl.read=/home/me/somedir/somefile

     Use ":" to separate entries:

             acl.read=/home/foo:/home/me/somedir/somefile

     Allowing 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.

  4. How do I let an applet write a file?

     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=/tmp

     You can allow applets to write to a particular file by naming it
     explicitly:

             acl.write=/home/me/somedir/somefile

     Use : 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.

  5. What system properties can be read by applets, and how?

     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 separator

     Applets 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 directory

     To 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");

  6. How do I hide system properties that applets are allowed to read by
     default?

     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

  7. How can I allow applets to read system properties that they aren't
     allowed to read by default?

     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

  8. How can an applet open a network connection to a computer on the
     internet?

     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);

  9. How can an applet open a network connection to its originating host?

     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.html

     then 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.

 10. How can an applet maintain persistent state?

     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
        o CUPPA, Chat Up Plenty O' People applet, by Paul Burchard
        o Scribble Forum, a shared scribble pad, by Robert O'Callahan

     Although the CUPPA page says that its multiuser chat room shouldn't be
     allowed by the applet security policy, actually, it's fine - there's no
     violation of the security policy here.

 11. Can an applet start another program on the client?

     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.

 12. What features of the Java language help people build secure applets?

        o Java programs do not use pointers explicitly. Objects are accessed
          by getting a handle to the object. Effectively, this is like
          getting a pointer to an object, but Java does not allow the
          equivalent of pointer arithmetic on object handles. Object handles
          cannot be modified in any way by the Java applet or application.

        o C and C++ programmers are used to manipulating pointers to
          implement strings and to implement arrays. Java has high-level
          support for both strings and arrays, so programmers don't need to
          resort to pointer arithmetic in order to use those data
          structures.

        o Arrays are bounds-checked at runtime. Using a negative index
          causes a runtime exception, and using an index that is larger than
          the size of the array causes a runtime exception. Once an array
          object is created, its length never changes.

        o Strings in Java are immutable. A string is zero or more characters
          enclosed in double quotes, and it's an instance of the String
          class. Using immutable strings can help prevent common runtime
          errors that could be exploited by hostile applets.

        o The Java compiler checks that all type casts are legal. Java is a
          strongly typed language, unlike C or C++, and objects cannot be
          cast to a subclass without an explicit runtime check.

        o The final modifier can be used when initializing a variable, to
          prevent runtime modification of that variable. The compiler
          catches attempts to modify final variables.

        o Before a method is invoked on an object, the compiler checks that
          the object is the correct type for that method. For example,
          invoking

            t.currentThread()

          when t is not a Thread object causes a compile time error.

        o Java provides four access modifiers for methods and variables
          defined within classes and makes sure that these access barriers
          are not violated.
             + public: a public method is accessible anywhere the class name
               is accessible
             + protected: a protected method is accessible by a child of a
               class as long as it is trying to access fields in a similarly
               typed class. For example,

                 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.)

             + private: a private method is accessible only within its
               defining class
             + default: if no modifier is specified, then by default, a
               method is accessible only within its defining package

          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.

 13. What is the difference between applets loaded over the net and applets
     loaded via the file system?

     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
        o applets loaded via the file system are allowed to read and write
          files
        o applets loaded via the file system are allowed to load libraries
          on the client
        o applets loaded via the file system are allowed to exec processes
        o applets loaded via the file system are allowed to exit the virtual
          machine
        o applets loaded via the file system are not passed through the byte
          code verifier

     For these reasons, Netscape Navigator 2.0 does not load applets via
     file: URLs.

     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.html

     and the file something.html contains an applet, Netscape Navigator 2.0
     won't load it. You need to specify the URL using the http protocol,
     like so:

             Location: http://someserver/~me/something.html

 14. What's the applet class loader, and what does it buy me?

     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
        o There are no stack overflows or underflows.
        o All register accesses and stores are valid.
        o The parameters to all bytecode instructions are correct.
        o There is no illegal data conversion.

     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.

 15. What's the applet security manager, and what does it buy me?

     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.

 16. Is there a summary of applet capabilities?

     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:
        o NN: Netscape Navigator 2.0beta, loading applets over the Net
        o NL: Netscape Navigator 2.0beta, loading applets from the Local
          file system
        o AN: Appletviewer, JDK beta, loading applets over the Net
        o AL: Appletviewer, JDK beta, loading applets from the Local file
          system
        o JS: Java Standalone applications

                      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

 17. If other languages are compiled to Java bytecodes, how does that affect
     the applet security model?

     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.

----------------------------------------------------------------------------

Examples

None of these examples are malicious - the one line descriptions can be
taken at face value. You can look at the source code for each applet, before
visiting the page that has that applet inside. (The first link in each
example takes you to the source code, and the second link takes you to an
html page that includes the executable content for the example.)

Files:

   * Can this applet read files on your system?
   * Can this applet obtain information about files on your system?
   * Can this applet write a file on your system?
   * Can this applet use File.delete() to delete the file named /tmp/foo?
   * Can this applet use the unix command /bin/rm to delete the file named
     /tmp/foo?

System Properties:

   * Can this applet read the ten system properties that applets are allowed
     to read by default?
   * Can this applet read hidden properties like user.name or user.home?
   * Can this applet replace your browser's property file?

Sockets:

   * Can this applet connect to port 25 on www.netscape.com?
   * Can this applet send data to www.sun.com?

Processes:

   * Can this applet kill your browser?
   * Can this applet run some program on your computer?

Libraries and name spaces:

   * Can this applet load a library on your computer?
   * Can this applet create its own class loader?
   * Can this applet create a class of its own in the java.net namespace?

Windows:

   * What does a window created by an applet look like?

----------------------------------------------------------------------------

Glossary of terms used in this FAQ

Applet
     A Java program that is run from inside a web browser. The html page
     loaded into the web browser contains an <applet> tag, which tells the
     browser where to find the Java .class files. For example,

             appletviewer http://foo.com/~jo/coolApplet.html

Standalone Java application
     A Java program that is run by invoking the java interpreter. For
     example,

             java coolApplication

Server
     The computer that hosts the web page that contains an applet. The
     .class files that make up the applet, and the .html files that
     reference the applet, reside on the server. When someone on the
     internet connects to a web page that contains an applet, the server
     delivers the .class files over the internet to the client that made the
     request.

     The server is also known as the originating host.

Client
     The computer that displays the web page that contains an applet.

     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.

----------------------------------------------------------------------------

Copyright  1995 Sun Microsystems, Inc., 2550 Garcia Ave., Mtn. View, CA
94043-1100 USA. All rights reserved. For Java technical support, see the
newsgroup comp.lang.java or send mail to java@java.sun.com. For problems
with this web site, send mail to webmaster@java.sun.com.

