Tuesday, October 17th, 2006

Using Applets to Play Outside of the Sandbox

Category: Security

Imaging Experts has a solution to allow you to get out of the sandbox via signed applets the right way.

The problem they ran into was that they were getting the following message when trying to write to a file, even with a signed applet:

java.security.AccessControlException: access denied (java.io.FilePermission C:\images\img1.tif read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkWrite(Unknown Source)

The solution was found via google:

I figured I would use the JavaScript method just to set some properties in the Applet. I would then create a separate thread that could be responsible for listening to changes in these fields, and calling the openFile method on behalf of the JavaScript.

  1. Thread javascriptListener = new Thread()
  2.             {
  3.                 public void run()
  4.                 {
  5.                     while (true)
  6.                     {
  7.                         if (gJavascriptCalled)
  8.                         {
  9.                             gJavascriptCalled = false;
  10.                             openFile(gJavascriptFilename);
  11.                         }
  12.                         try
  13.                         {
  14.                             sleep(JAVA_SCRIPT_POLL_INTERVAL);
  15.                         }
  16.                         catch (Throwable t)
  17.                         {
  18.                             t.printStackTrace();
  19.                         }
  20.                     }
  21.                 }
  22.             };
  23.             javascriptListener.start();

Ah the fun people have to go through to get past the sandbox.

Posted by Dion Almaer at 7:48 am

3.4 rating from 11 votes


Comments feed TrackBack URI

I’m gonna bookmark this page just in case! I remember doing some stuff with signed applets a couple years back, an absolute nightmare…

Comment by Thomas Messier — October 17, 2006

I had same problem several months ago trying to print barcode labels from a web application and that was the only way to avoid the security warning everytime, I found it on Sun forums (had to dig a lot tho).

Comment by JacSoyYo — October 17, 2006

MashProxy is another Java based solution to extend the browser, but with cross-domain capabilities: http://mashproxy.com/
The problem with Java is that once you manage to pry the door open, things quickly become dangerous. It’s hard to achieve a controlled amount of openess and it’s easy to create additional security risks.

Comment by Julien Couvreur — October 17, 2006

I met the same thing about 2 years ago. And many of my JavaScript calls are restricted so the calls need to be asynchronized. But my JavaScript calls just should be a syncrhronous call. So callbacks are used, and the Applet is now became a server! And JavaScript became a browser! Both are in asynchronous mode! What about there are two restricted calls should work together with a middle JavaScript DOM action and before/after actions? You must block and indicate the user in JavaScript side. Lots of other problems came to me contributing paints at that time.

I just remember that nightmare of integrating Java Applet and JavaScript together. So I recommend you NOT to rush to such “JavaScript in Applets – Getting Out of the Sandbox technology” until you are ready for nightmares. Actually I recommend NO Java Applet + JavaScript.

Comment by Zhou Renjian — October 17, 2006


tluoqbzblo ykgaujhdxi gdzmxmisa dglptfxldc

Trackback by usdubxllc — October 21, 2006

Leave a comment

You must be logged in to post a comment.