What we do is "version" our applet and never download the applet to the user's hard drive unless it is a new installation or the version of the applet changes. When we do download the applet to the hard drive, we also create a file called Exc.props ... that contains the version number of the applet that was downloaded.
In our "installl" html page, we load a local js variable with the current version of the applet. The "install" html page loads our "installer" applet. The installer applet knows the version number that is specified in the html and then compares that version to the version contained in the Exc.props file. If the versions don't match, then we download the latest version of our applet from the server. If the versions match, obviously we don't download the version from the server.
Once the "install" applet is finished doing it's thing, we then load another "launcher" html page from our "install" html page ...
It is the exc.html page that actually launches our applet. It is in that html page the we use the codebase param to point to the location, on the hard drive where the applet was downloaded. This is where the problem lies ... we are asking to run the applet from the hard drive and the exc.html that launches the applet is on the web server.
What this does for us, or for our customers, is if the version of the applet, on the hard drive is current, we don't need to get/load the applet that is on the web server. This cuts down on network traffic considerably seeing that our customers can have as many as 20,000+ users running our applet, multiple times, during a months time.
We have been running this way for years without problems ... until now.
If I get rid of the codebase param ... all is cool because the html pages and the applets are in the same directory on the server, but the applet is being served each and every time a user runs our application. We are using pack200 compression on our applet, but it is still 1,405K in size and whatever little network traffic we can save for our customers is very important.
Is the reason for this change (which caused this problem for me) to stop rogue applets from being loaded/run under these conditions ?
Is it considered "more safe" requiring the html that launches an applet and the applet itself be in the same directory ? ... even if the applet is signed ?
Our application is a client/server application. Once a user actually "logs in" to our applet, they have the option to create "offline" usage. When they do so, we do copy the exc.html page to the same directory, on the hard drive, where the applet was downloaded to.
With that, they can load/run the exc.html on the hard drive while they are flying or don't have internet availability and the applet will run and they can input the information, save it to the hard drive as a "draft" and when they do have internet availability, they run the applet again (via the normal URL connection) and then submit their work to the server.
As long as the browser loads exc.html from the hard drive directly too, it will work. You can have the applet codebase points to the harddrive too in that case. (not using http://some_hosts.com/exc.html)
Since you copy exc.html to the local drive too already, can you change the browser to point to that local copy of exc.html to start the applet for offline mode ?
This is a well known security limitation for browser in general. e.g img tag in html behaves the same.
Exactly, if the html and applet are both locally loaded you should be ok.
OR you could deploy using JNLP (webstart) and Java will manage caching the app locally for you. The user can drag the JNLP to their desktop and won't even need to start a browser, unless you need to run in a web page.
Our application is an enterprise-wide solution being used by over 100 corporations (many Fortune 500 companies) and is deployed in over 85 countries. Depending upon the company, the amount of users can be from 500 to over 200,000 ... so this little change, which may seem trivial in some aspects, has thrown quite a wrench into the works as far as we are concerned.
As users download (some automatically) Update 24, and our application stops dead in it's tracks, the noise level rises proportionately.
I would still like to understand why the running of a signed applet, in the way I have described, is a security concern.
If the applet, pointed to by the codebase, is not in the same directory as the html file that is loading the applet, and the applet is signed and the user has accepted the certificate ... then run it.
We are a user of a Java application (which we don't have access to the source code) that has been working perfectly up until the last update of Java _24. Since the update we can no longer use the application. It appears the be the exact same issue discussed here. I do consider it a bug that needs to be fixed. It sounds like the changes made that broke this weren't well documented (if at all) in the release notes for the Java update and there isn't any easy fix other than rolling back to the previous version of Java.
It has been asked several times on this thread and I too am curious what was the driving force behind the change in Java that broke the application we use all the time. Was it just that someone thought it wasn't a good idea and just decided to change it or is there a real security risk that had to be addressed? If so speak up.
The security issue is the html content loaded via http or https remotely by a browser, should not contain reference to any local file system. This is the security problem.
if index.html contains <img src="c:\test.jpg">, browser will not load test.jpg for you, even if it's on the local system. This is the security problem, and all browser blocks that.
That's the same reason why you cannot have <applet codebase="c:\applet" ...> in the index.html above.
Whether the applet JAR in the local computer is signed or not does not matter. The problem is the remote page should not know about installed JARs on the system. Also, if we allowed that JAR on the local system, any other webpage can also use the JAR. This also enable malicious webpage to gain access to installed java applications.
Application should not depend on this security hole to implement the feature they need. It is very likely that there are other ways to implement it and we will be happy to advise on the better approach.
If you still have further questions regarding this issue, you can consider to use the official Oracle support channel, e.g:
I'm getting "java.security.AccessControlException: access denied" since update 24, On my website Fatpaint.com.
It uses a normal signed applet to access the user's local hard drive and to do some socket communication, all requiring privileged access. This worked fine before this update. The applet is loaded from the same server as the webpages.