Most users would download and install software from unkown sources without even a blink of an eye. Sometimes these downloads contain trojans, worms, viruses and many other kinds of unfriendly creatures. Yet the same users are very worried about applets having access to their hard disk. Because of these unfounded fears applets are forced into a sandbox from which they cannot escape out of without the user's permission.

Before we go any further let's see what really happens when an applet tries to do something trivial like displaying an image stored on a remote webserver. While there's nothing wrong with the code itself, as you will see when you click on the demo link, the applet fails rather miserably. If you open the plug-in console window you will see a heap of error messages.

This article will attempt to provide two different solutions to overcome sandbox restrictions. The first approach which involves the use of signed applets can be used in almost any situation. The second approach is transparent to the user but cannot be used in certain situations.

Part I : Signed Applets Thanks to countless changes and bugs in different versions of the sdk, signed java applets have not found widespread use. Having created the signed applet you still need to convince the user to grant the additional permissions, so you may be better off with the alternative approach described in the second part of this article.

Part II: Using a Proxy

Applets are allowed to make connections to their own server. It's possible to make use of this in ertain situation such as retrieval of remote files over HTTP or FTP with the use of a script that acts as a proxy.

In the introduction to tutorial you would not have seen any images getting loaded when you clicked on the applet. If you did congratulations you have detected a major bug in the java plug-in. If you missed the demo link here it is again. You might want to take a look at the source code as well.

If you open the console window, it should display something similar to the following stacktrace:

   java.security.AccessControlException: access denied 
   (java.net.SocketPermission radinks.com resolve)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
	at java.security.AccessController.checkPermission(AccessController.java:401)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
	at java.lang.SecurityManager.checkConnect(SecurityManager.java:1023)
	at sun.awt.SunToolkit.createImage(SunToolkit.java:519)
	at com.radinks.tests.UnsignedApplet.init(UnsignedApplet.java:32)
	at sun.applet.AppletPanel.run(AppletPanel.java:353)
	at java.lang.Thread.run(Thread.java:534)

Sponsered Content

Rad SFTP - A Pure java secure FTP applet.

Close inspection reveals that the plug-in is pointing the fingure at line 32 of our applet. That's the line which attempts to create an image from a remote URL. This is an example of how the sandbox prevents applets from carrying out certains tasks. The java plug-in does not think our applet should be allowed to open socket connections to remote hosts and throws an exception.

Some clues to the solution can also be found in the stacktrace. It mentions an AccessController class. Reading through the docs reveals that it can be used overcome the Sandbox restrictions. So we will change our code for the init method to make use of the AccessController.

Even after you recompile the applet you find that the same exception is still being thown. Now the problem is that your applet is still untrusted. Even though your code is now equiped to break out of the sandbox you still need to package it properly, and digitally sign it. That would enable the applet to ask for and obtain the required permissions. We will look into that in the next step in this guide.

Before you can sign an applet you need to have a digital signature, these can be created and managed with the keytool application that's part of the j2sdk. You can either use a 'self signed' certificate to sign your applet or use a third party verified digital signature.

Since most third party verified signatures cannot confirm anything more than the fact that someone answers the phone in your office, we will only look at self signed certificates in ths guide. Please refer java tool docs which provides a wealth of information on this topic for more details.

First let's choose an alias for your key. This is a short name that you will use to identify yourself to the keystore. Let's suppose that you have chosen colombo as your alias. To generate your key type in the following command at the console.

keytool -genkey -alias colombo

You will then be prompted for the for information about yourself and the organization that you belong to. Once you have entered all this information (don't forget your password) you have a hot new self signed certificate which you can use to sign applets with the jarsigner. The jarsigner is what we are going to look at in the next step.

If you have followed the tutorial so far you have an applet that requests special permissions and you have a signature which you can use to sign the applet, but you still need to package the classes properly into jarfile before you sign it. To create the jar, cd to the appropriate directory and type

jar -cvf applet.jar com

You are now ready to sign your first applet. The command is:

jarsigner applet.jar colombo

you will be prompted for the password to the keystore. The jarsigner will place your signature inside the jar file that you created above. You can confirm this by examining the jar file with file-roller,winzip or similar tool.

Now all you need to do is to actually run the applet and that's very straight forward you do not need to anything special since the plug-in will take care of asking for extra permissions.

That brings us to the end of part I of this article, we will return shortly to look at other ways in which we can 'jump' the sanbox'

If you have read the first part of this article you would have seen how the sandbox prevents applets from accessing remote websites. Though signing your code would allow your applets to connect to other websites, there will be situations where the user does not grant the required permissions hence the need for an alternative.

By default an applet can connect only to the same server on which it was hosted on. But that server can host a simple script which can retrieve the remote url and pass the contents back to the browser. This is very similar to the service performed by a proxy server such as squid. Our script is just more specialized, it's not suitable for use as a general purpose proxy since it cannot offer the same levels of scalability as squid of apache.

When connecting to a remote page, our applet would use a url similar to the following:

http://example.com/script.php?url=http%3A%2F%2Fwww.radinks.com%2F

In this case example.com is the server from which the applet was delivered. And script.php is our proxy script. The remote web page that we are trying to retrieve is http://www.radinks.com/ but it appears as http%3A%2F%2Fwww.radinks.com%2F we have escaped all the special characters.

Java gurus will not disagree when I say the best server side programming language is PHP. It takes less than a minute to write the simple proxy script of the kind that we have been discussing.

Sponsered Content

Java online business card designer.

That's all there is to it! You still need to tighten up the code to ensure that it does not get abused. That needs to be done regardless of the language of choice. You should at least try to protect the script from being used as a open proxy. There are many ways of doing so, including checking the HTTP referer or exchanging keys between the applet and the script. That discussion would be a separate article on it's own right, so let's stop for now and look at how we should modify our applet from part I

The above is an extract from the init method. The full code includes a try catch block as well. The two interesting points to note is that the applet is only connecting to it's originating server. Second the final destination url has to be escaped with the call to the static encode() method in the UrlEncoder class.

Part II of this article is short and sweet. Hope you found it usefull

	/*
 	 * in a production env, this variable could be loaded from a 
	 * property file.
	 */
	String proxyScript = "http://raditha/java/sandbox/test.php";	
	/*
	 * The actual URL would be what the user inputs.
	 */
	String target = URLEncoder.encode(
			"http://radinks/images/drop-logo100.jpg","UTF-8");


	URL u = new URL(proxyScript + "?url=" + target);

	img = getToolkit().createImage(u);

  <?
	  $url = $_REQUEST['url'];
	  $fp = fopen($url,"rb");
	  if($fp)
	  {
		  fpassthru($fp);
	  }
  ?>

 public void init()
 {
    AccessController.doPrivileged(new PrivilegedAction() {
        public Object run() {
            try {
                /*
                * create the url that references an image stored on a remote server
                */
                URL u = new URL("http://radinks/images/images/drop-logo100.jpg");
                img = getToolkit().createImage(u);

                System.out.println("ok" + img);
            }
            catch (MalformedURLException ex) {
                System.err.println("err: malformed url");
            }
            return null;
        }
    });
 }

discuss this topic to forum