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.
Related
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.
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 want to read the web address of all open windows. As soon as the window closes, I should know it too.
One way to do this is by asking the user to download a firefox plugin. This plugin should monitor the user web address.
But is this possible? How to go about executing it. I am pretty decent in Java and PHP.
EDIT:
What if the user wants to give permission to access all the websites he or she visits?
I want to display in a visual manner the statistics of the sites being visited by users who grant permission.
As noted, this cannot be done with standard JavaScript/DOM methods that run inside a page, for security and privacy reasons.
You could definitely do it with a Firefox add on, plugin or extension.
I suggest reading the Firefox addons developer guide and the Developer Hub in general. The language used to develop for Firefox is JavaScript.
nsIWindowMediator can be used to enumerate open windows, and properties can be obtained through the nsIDOMWindow objects. As explained here,
"While you can use JavaScript to get child windows opened from the parent window, you cannot get dialogs or windows that have no relation to that window. To overcome this limitation, nsIWindowMediator makes it possible to access all of Firefox's windows."
this likely violates the same origin policy, which rules this out
it basically controls the code so that it does not read anything it did not create
so no spying can be done
No, this would be a major security and privacy issue.
This is definitely a security violation similar to sniffing; and would require certain privileges to run on each platform (such as an activeX or plugin or a privileged applet).
However, this can be done using javascript only the page containing the script it self is responsible for opening windows (meaning not all windows such as window opened by user) - if that is what you are looking for, let me know.
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).
I'm currently developing a support system for a university. The system is written in PHP and I would like to be able to get a current list of software and basic computer information on a computer. Basically when one of the faculty or staff creates a ticket from our web interface, I would like to have a Java Applet or similar that could be run and would return the information to the help desk PHP script. Does something like this exist?
There are lots of programs that do this sort of thing. Googling for "CMDB" should give you a reasonable start -- a couple of them are open source, though others aren't even close to free (e.g., BMC Atrium).
To keep things closer to topical (i.e., programming related), one of the main frameworks for this sort of situation is called Web-Based Enterprise Management (WBEM). On Windows this is implemented as WMI. On Linux there are a couple of implementations including OpenWBEM and HP WBEM.
In Java? You'd probably have a hard time even finding, let alone making, an applet that can get that info without already having some software installed on the user's end. The biggest features of java are (1) that it runs in a virtual machine (read: getting to the underlying OS/hardware is not something it likes to do), and (2) that in a browser, applets generally run in a "sandbox" that keeps the applet from doing anything remotely dangerous. Basically the most it can do is tie up resources.
Number 2 can be worked around by signing the applet, but that'll require you either buy a code signing certificate or install a self-signed certificate on any computer that'll run your app.
Number 1 might be worked around with some help from Runtime.exec and ...\wmic.exe, but that assumes the WMI stuff is installed -- which is rarely the case unless someone does a full install.