I have developed an applet. But when my browser fetches it from the webserver it pops a security warring. I don't want this message to come. Meaning applet should run without the end users permession. How can I do that? Do I need to get my applet signed? If yes, from where can i get it signed? What's the cost of geting it signed?
Your description might relate to a number of problems, such as the code trying to do things which require trust. That does not sound like the case in this instance. If your unsigned code tried to do things that required trust, it would not prompt the user at start-up, but either prompt them when the trusted action is attempted (e.g. for cross site access in later JREs) or just fail with an AccessControlException or similar.
It could be that your applet uses multiple Jars and has run into the mixed code restrictions introduced in Java 1.6.0_20. But the symptoms do not sound quite right for that either.
Is your applet publicly available? What is the URL where I/we can visit it?
As an aside, if your applet tries to break out of the security sand-box, it must be trusted. That means the code must be digitally signed, and OK'd by the end user at the prompt. There is no way around it.
But it does not require a code signing certificate issued from a CA. You can roll your own code signing certificate using the tools of the SDK. I have a few small demos. of code projects that compile and build code before signing it.
You need to get yourself a code-signing certificate. Probably by some "well-known" CA if you want to avoid all warnings. The certificate itself costs money, but once you have it, you can use it to sign as many applets as you want (you do the signing yourself).
Related
I would really like to know if it is even possible to run a self-signed java applet in Java 8. I have tried everything possible except buying a certificate and I my self-signed applet gets blocked every time. I can only just make it accessible if I add an exception in Java Security Settings but Ive never had to do that for anything else and what user is actually going to go to that much trouble. Im using applets because I want to embed a DosBox on my site... But Im beginning to think that Java 8 just can't do self-signed applets, period.
Can anyone else manage to get their self signed applet through security? I'm about to lose my mind with this to be honest.
Self-signed certificates are not trusted, by definition. You have two choices:
Buy a code signing certificate.
Have the user adjust his Java Security Settings, or trust the publisher via the popup dialog.
This is how the system is designed and intended to work. It's been that way for 20 years.
I am writing a Java file uploader applet, but I simply could not figure the following issue out. (The uploader is very specialised, therefore we could not just use a stock solution). I have a self-signed applet, which I am trying to test locally, but I cannot get it to read local files. I have Permissions:all-permissions declared in the manifest.
If I add
<param name="permissions" value="all-permissions" />
to the applet tag , it throws
com.sun.deploy.security.BlockedException: User has denied the privileges to the code
If I avoid this, it throws
java.security.AccessControlException: access denied ("java.io.FilePermission" PATH_TO_FILE" "read")
BlockedException is thrown in the first case, even though when the Java plugin asks me about security issues, I always say "don't block", in order for this code to run.
Any ideas how I can test this? Or could you point me to an open source Java uploader applet implementation I could inspect? Of course, the deployed version of this software will be signed with a trusted certificate, but I need a means to test it....
Thank you!
Update
Here is what needs to be done:
Given a web application which we developed, this application needs a lot of small files from the local filesystem. So, we need to iterate over a directory structure and inspect files in order to find those that the web app needs. This is very cumbersome by hand, therefore we need to automate this.
I thought of two other approaches:
JNLP-applet, however, its API can only display a FileChooser for single or multiple files, but not for a directory
A plain old Java client application, which will find the files it needs and upload them to the server via an API. This client can then be launched via Java Web Start.
..Do you have any more ideas?
What you are trying to do is generally frowned-upon as this is exactly how systems are compromised with Java installed. The operation you want to do is privileged, you will need to run your code in a privileged mode, and, most likely, create a policy file to allow this to work on the client machine. There's a short, concise tutorial on http://www.coderanch.com/how-to/java/HowCanAnAppletReadFilesOnTheLocalFileSystem.
Now, please, this is actually a VERY BAD IDEA. Is there no way that you could rather write a JavaScript page that will perform this upload via some API call at all? That way, you are not bypassing the browser security to perform the upload.
The Java Applet approach is an out-dated, dangerous and down-right nasty solution, and no amount of signing, policy files or tweaks will make this a safe alternative. I'm a huge Java fan, but if there's one thing that gives me nightmares, it's the Java browser plug-in - there's just never a good reason for using it, not when you consider how incredibly unsafe it is. Of course, don't get me started on Flash...
Your idea of using a plain Java client, loaded via Web Start, seems to be the best solution. That way, once installed, your application would have full access to the underlying file system. Of course, this also opens up the debate of whether this is really a situation for using Java in the first place, but that's a whole other kettle of fish.
to do this you have to sign your applet.
keytool -genkey -keystore myKeyStore -alias me
keytool -selfcert -keystore myKeyStore -alias me
jarsigner -keystore myKeyStore jarfile.jar me
A self signed applet working off a local server1 should be able to access the local file-system. It might be necessary to lower the security level in the Java Control Panel. Oracle is in a process of tightening the security of applets, so it will depend on which exact JRE version is loading the applet.
It seems the security environment of an applet loaded off the local file-system is tighter than if it were loaded from localhost. See this answer for details.
I agree with your assessment that the the JNLP based file chooser is unsuited to this task. As you mentioned, it is for working with file resources, not directories. Even worse, I noticed a small applet that I had developed using the JNLP based file open services was throwing NullPointerException while browsing around, with associated odd visual behavior in the chooser itself. Totally inadequate.
As the top poster for applet questions, I strongly actually warn against embedding an uploader in a web page. The biggest problems:
It creates further problems with browser/JRE/JavaScript/applet interaction bugs
It creates a non-resizable GUI. There are ways to create a resizable applet, but last time I checked, they were not reliable across browsers.
So in the end, I recommend using a fully trusted (i.e. all-permissions) app. that uses either the Swing JFileChooser or a variant of the File Browser GUI opened from a free-floating, JNLP launched JFrame. If the use-case is simple enough, we might even be able to dispense with the frame itself, and (visually) go directly to the file chooser.
The 'free-floating' approach will not work in a web-app. that requires JavaScript interaction. If the web-app. requires that, we come back to 'applet', and that is where you'd look to use the doPrivileged(..) functionality you mentioned in a comment. The reason being that if a method is called programmatically by JS, the Java based security manager detects that some frames in the stack are not trusted (the JS), and therefore puts everything back in the sand-box - even if the Java code was originally trusted.
In the previous months I developed a sandbox Java applet for an academic project. I wasn't able to sign it with a trusted Certificate Authority because of the restricted budget.
With the release of Java 1.7.51 I found that the new security restrictions forbid the execution of the applet, because of the lack of signature.
Until now, I have found two rough solutions to this problem:
ask the user to include the applet page on his/her exception lists;
ask the user to set the Java security level to "Medium" (which, of course, is a risky manoeuvre).
Is there a way to overcome the restrictions imposed by Java with a self-signed applet without asking the user to change the security settings?
I would deeply thank you for your answers, since the option to buy a trusted certificate remains an expensive one.
Is there a way to overcome the restrictions imposed by Java with a self-signed applet without asking the user to change the security settings?
Short answer, no. Long answer, nope.
Its not a real solution but maybe a bit more convenient for the enduser:
Write a small programm (as jar file, or batch) which adds your site to the exception list. This tiny programm you offer to the user which can't execute your applet. It only has to be executed once. How this can be done is described here.
The file controlling the Exception Site List is stored in the user’s
deployment location as described in the deployment configuration. On
Windows 7 the location is
C:\Users\username\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites.
The format is one site per line.
If you think that is not really trustworthy to the user you are probably right ;-) who executes a file downloaded from the internet? You can also just add a small description to your page and a user could execute it from commandline. For windows it would like that:
mkdir %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\security
echo http://www.carlos.com >> %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites
The more I read my post I think the best solution is the certificate but still wanted to share this option.
I am able to run applets that have signed jar files on Internet Explorer with Java 1.7 Update 45.
I am however not able to run applets with unsigned jar files.
I tried clearing the cache.
I have also changed the security java control panel settings to Medium.
I still get the error JarSigningException.
Is there any way I can proceed here?
Are only signed jar files allowed? This looks like a major limitation.
Is there anyway I can tweak some settings to get unsigned applets to load?
Any help is appreciated.
Is there any way I can proceed here?
Sure. Digitally sign the code with a certificate that links back to a trusted key chain.
Are only signed jar files allowed?
It is progressing towards that, yes.
Is there anyway I can tweak some settings to get unsigned applets to load?
On your own machine? Probably for a little while longer, as Oracle continues to tighten the security along the lines you have discovered.
For the users? No, nothing that is practical beyond 'educate your users as to the advantages of the digitally signed code', and to 'click OK when prompted'.
The best thing you can do if these are your applets is to sign them with a decent signing key. (Or if the applets are solely for your own use, a self-signed certificate will do once you have imported it into your JVM's keystore as trusted.)
If these are applets supplied by someone else, either convince the supplier to sign them (with a good key), or stop using their applets. Period.
The reason that Oracle are moving in this direction is that applets can do a variety of nasty things to your machine by exploiting security holes of various kinds. Disabling unsigned applets helps protect the user from being a victim of malicious applets ... since the "bad guys" are unlikely to sign their code with a certificate that says who they are.
From appearances, Oracle really screwed up. Not only did they break hundreds of thousands of man-hours worth of benign legacy applets... Having to digitally sign applets between local builds undermines new applet production. They seriously need to give some thought to this.
I guess you can always download and use an old version of Java (one that actually works...):
http://www.oldapps.com/java.php
I will never undestand why have the security slider in the Java settings if it does nothing...
After install, restart your browser.
It works like a charm for me.
I have a Java applet which doesn't need any special privileges to run (i.e, it runs fine in the sandbox), but which expects the user to enter some sensitive information. Therefore, I'd like the user to be able to verify the origin of the applet.
I then signed the applet, and everything appears to be working correctly. The browser apparently accepts the signature; for test purposes, I tried executing PrivilegedActions and everything worked. However, the browser doesn't inform the user that the browser is signed - from user's perspective, both unsigned and signed versions of the applet appear exactly the same.
So my question is: is there a way to instruct the browser to present the signature authority to the user, or something similar?
Firstly, this is not a valid usage for signing a jar.
Did you at some point ever forget to untick the always trust tickbox?
Back to the first point because it is quite important. By signing a jar you are putting the certificates name to the claim that it is secure. Note that being secure is very much broader than being non-malicious. The security dialog which asks whether the user wants to give full local user access pops up if any code anywhere is encountered is signed. It doesn't mean that some particular set of pixels are from a trsuted source.
The correct approach is to use https.