My client wants to use an applet to do drag and drop file transfers from the browser. We have everything working for the most part, but the .java.policy file granting the applet file system access needs to be uploaded to every client in order for the applet to have permission to read/write to the file system.
My technical counterpart at the client has just done some research and wants me to look into the java deployment toolkit (a js library that takes care of deployment instead of using html tags). He wants me to see if I can configure the applet to use a policy file requested from a URL. I haven't been able to find how to do this, which is what I expected, since I think it would be a terrible security risk.
The trouble is that they need to be able to grant the applet read/write file system access, but I feel that requesting a policy file from a URL is a bad idea and I need help explaining why.
So that's my question: is requesting a .java.policy file from a URL even possible? If so, isn't that a terrible security risk?
So that's my question: is requesting a .java.policy file from a URL even possible?
Yes it is, but not in any way that is practical. The thing is:
The policy file needs to be in a certain location on the local file system, in order to work.
Any Java app. or applet would need trust to place it there, or even find out where the right location is.
A Java app. needs extended permissions to be able to import the policy file to where it will have an affect.
If a Java app. has the permissions to insert the policy file, it is already trusted.
If so, isn't that a terrible security risk?
Yes, it would be.
If this applet needs trust, digitally sign it.
Addendum
See Java 7 Update 21 Security Improvements in Detail for more info. on the ever tightening Java security environment.
It is apparently planned to have a future JRE default to maximum security. That would mean that by default, only classes in a Jar, digitally signed by a certificate issued by a Certification Authority (e.g. Comodo $180/year, Thawte $300/year) would ever run. Everything else would be rejected.
Related
I just don't know what the right codes should i put, i already tried so many ways to have an access to read and write. My main goal is when i click the button in Java Application, the download will start.
You can't access the local filesystem from a Java sandbox applet. Reading the documentation What Applets Can and Cannot Do, you will see:
Sandbox applets cannot perform the following operations:
They cannot access client resources such as the local filesystem, executable files, system clipboard, and printers.
They cannot connect to or retrieve resources from any third party server (any server other than the server it originated from).
They cannot load native libraries.
They cannot change the SecurityManager.
They cannot create a ClassLoader.
They cannot read certain system properties. See System Properties for a list of forbidden system properties.
If you want to bypass these restrictions you have to use a priviliged applet:
Privileged applets do not have the security restrictions that are imposed on sandbox applets and can run outside the security sandbox.
For this, you will need to sign your jar and add the following code snippet in the JNLP file:
<security>
<all-permissions/>
</security>
Then the user has to grant the permission. From the documentation:
The first time an RIA is launched, the user is prompted for permission to run. The dialog shown provides information about the signer's certificate and indicates if the RIA requests permission to run outside the sandbox. The user can then make an informed decision about running the application.
Read Security in Rich Internet Applications and Deploying With the Applet Tag for more information.
I've made a Java applet and I self signed it before, but due to security changes in recent Java updates, self signing no longer gives the applet the necessary permissions.
I need the applet to be able to read the local file system to use images and to be able to connect to a MYSQL database.
The applet used to work with the database when I self signed it, but not anymore.
In addition, many unknown users will be using the applet, so I won't have control over their machines.
Where can I get my applet professionally signed and if possible, is there another way to self sign that will make the applet work?
Purchase a certificate from any reputable certificate authority. Use that to sign your code. List of CAs
Or, some companies also do this: Sign the jars themselves, but pre-populate the JDK trust store with your (self created) CA cert. If you have control over the JRE that is installed on all user machines, you can place your certificate in JRE/lib/security/cacerts so that is trusted ahead of time.
update: This page (Java Control Panel Documentation) describes what type of signature is required for various client side security level settings:
As long as the applet 'phones home' to the DB & this demo. of the JNLP API file services1 works for the problem machines you should be set to go for a Plug-In 2 JRE (1.6.0_10+) JRE. And if the client has less than that, they should seriously look to update. The Deployment Toolkit Script can assist with that.
It is relevant in that:
It uses a self signed certificate
It allows a sand-boxed app. to read/write to the local file system.
An applet launched using JWS has access to the API.
This should only be considered a work-around. The correct way to solve the problem is to heed the advice offered to get a certified code certificate. Oracle seems to be heading towards making it so that unsigned or self-signed code will not just be sand-boxed, but entirely forbidden (& that is for the best).
As an aside re. DB access: For the protection of the DB. The applet should be forced to go through a 'public interface' (via the site that hosts the applet). Do not give the applet direct access to the DB. Otherwise hackers also have direct DB access.
I recently stumbled across a problem when starting my application via JNLP. I now narrowed it down to a java.security.AccessControlException, which denies me to shut down my ExecuterService.
So, I did some reading and found out that I'll need the permission (modifyThread) to successfully shut down the service. I also found out that I should use the <security>-tag (in the JNLP-file) to request it, but I'm a little confused about how.
The documentation of the tag says:
[...] If the all-permissions element is specified, the application
will have full access to the client machine and local network. If an
application requests full access, then all JAR files must be
signed. The user will be prompted [...]
From reading this it seems to me, that I can choose to either get all or no permissions... which seems like a confusing Implementation. Because I only need the one to shutdown my service.
I also read this article, telling me that I should not request all permissions, because I would then open up the users computer for malicious code.
So, is there a way to specify that I only need the specific permission (modifyThread) and I therefor don't need to sign my jar? Or will I have to go with the "sign my jar and request everything"-approach?
..will I have to go with the "sign my jar and request everything"-approach?
Yes. JWS permissions come in 3 levels1, the only one where modifying threads is permitted, is all-permissions.
1) JWS security levels
Sand-boxed. Provides a very limited environment. Access to things like printers and the local file-system is only permitted using the JNLP API services, which provide more limited forms of File after prompting the user. Come with window banners. Can only communicate with own server.
j2ee-application-client-permissions - provide those JNLP API services unprompted (after the user accepts the digitally signed code) removes the window banners.
all-permissions - pretty much anything, including replacing the existing security manager (yes, even 'all permissions' code gets a security manager in JWS - it is just very lenient).
Also chase the links from the JNLP & JWS pages. I can personally recommend those summaries & links.
I was wondering if anybody can show me way to be able to create read file permissions for my java applet.
The exact exception I receive is
java.security.AccessControlException: access denied(java.io.FilePermission filename.pdf write)
I've put f.setReadable and f.setWriteable where f is the file and nothing. A little help please.
There's security limits on what an unsigned applet can do, and one of the things it can't do is access the local filesystem (see here for a full list). You have several options:
Sign your applet. If a user then runs your applet it won't run with any security restrictions. However, signing your applet with a trusted certificate costs at least $100 a year, and if you self-sign then nobody is going to trust your applet. And even if you do sign with a trusted certificate the user might decide not to run it.
Set up your applet with a JNLP file. This will let your applet use the javax.jnlp package. You can then use the FileOpenService and FileSaveService to ask the user to let you read/write one particular file. Alternatively, you can use the PersistenceService to store a small amount of data persistently within the browser.
Why doesn't my Java Applet ask me for permission to start when I open HTML page with it on my localhost?
What is more, the applet starts but it cannot do anything. One of its duties is to connect with a webpage. But it doesn't. In console I can read:
java.security.AccessControlException: access denied (java.net.SocketPermission www.onet.pl:80 connect,resolve)
I guess there is a problem with the security settings of my Java.
It's some time since I programmed my last Applet, but I think you probably need to sign your jars.
The general policy for untrusted (i.e. not signed) applets is that they are only allowed (network-wise) to connect to the server they are loaded from. For applets loaded locally from the file system, this means they can connect localhost.
Asking the user for permission will only occur if either the applet is signed (but then the user gives permission for everything, if there is not a special security policy file) or the applet uses the JNLP functions to request some access (but this is only for local access) - for this, you would need the latest plugin (1.6.0_10 or later).
As Tom mentioned, a remote server can permit applets (and other dynamic web-content like JavaScript, Flash and so on) from other sites to access his server with a cross domain policy file. I'm not sure from which version on the Java plugin implements this, though.