JavaRanch Home    
 
This page:         last edited 23 January 2014         What's Changed?         Edit

How Can An Applet Read Files On The Local File System   

How can an applet read files on the local file system (and circumvent other security restrictions) ?

As a security precaution, applets run in a sandbox inside a browser, which restricts what it is allowed to do. For example, they can't access the local file system, can only make network connections back to the host from which they were served, and they can't read some of the system properties that a Java application can read.

Signing an applet

The way to allow an applet to do all those things is to digitally sign it. In effect the signer says "This applet is safe to use, and if you trust me, you can trust this applet, because through my signature you can be assured that it has not been tampered with since I signed it." The user will then be asked if she wants to trust the signer (usually in a little dialog box), and if she does, the applet can proceed with full privileges. If the trust is denied, the applet continues to run inside the sandbox with limited privileges.

The decision of whether to trust an applet should be made very judiciously, because a trusted applet has the same privileges a locally started application would have: It can read and delete files, and transmit data over the network.

A more thorough explanation of the applet security model can be found here. It includes a full list of applet restrictions.

For an introduction to applet signing and links to more information read this and especially this.

If, even after signing the applet, you still get a SecurityException, try running the code as privileged code:

    AccessController.doPrivileged(new PrivilegedAction() {
        public Object run() {
            // perform the security-sensitive operation here
            return null;
        }
    });
JavaDoc:java.security.AccessController

Policy files

An alternative way to grant an applet additional capabilities is the use of policy files, about which Sun has an introductory article, and another one here specifically for applets. Using policies it is possible to control in a more fine-grained way which privileges to grant an applet. For example, it becomes possible to grant applets access to the local file system, but not any of the other capabilities they are usually denied.

The drawback to using policy files is that they reside on the local file system, so users must make changes to a file that is normally out of their sight, and the contents of which are not trivial to understand.

The following example shows how to revoke most applet restrictions. Any of the permissions can be made more specific, for example FilePermission can be given for only selected files, and with just read-only access. The javadocs for each Permission class explain in detail what's possible. It is good practice to use the most restricted setting possible. RuntimePermission in particular can be used to create ClassLoaders and SecurityManagers, which can circumvent even more applet restrictions.

 grant codeBase "http://www.MyServer.com/MyDirectory/-" {
   permission java.io.FilePermission "<<ALL FILES>>", "read, write, execute, delete";
   permission java.net.SocketPermission "*", "accept, connect, listen, resolve";
   permission java.util.PropertyPermission "*", "read, write";
   permission java.lang.RuntimePermission "*";
   permission java.awt.AWTPermission "showWindowWithoutWarningBanner";
 };

Javadocs



AppletsFaq SecurityFaq

JavaRanchContact us — Copyright © 1998-2014 Paul Wheaton