Hi all Java/Applet gurus,
I've stumbled upon an interesting problem with the latest JDK build (1.8.0_b26).
When running Sandbox Java Applet with the latest JDK, from within Java code we try to connect back to the server with a different protocol - instead of original HTTPS we use WSS (secured Websockets connection, we use third party Websockets Client Java library). As the result, JVM tries to retrieve crossdomain.xml file from the server. The problem is, that the file is retrieved using HTTP (and not HTTPS) protocol.
For example, in our case the server IP is 192.168.1.1, the applet is loaded over HTTPS default port (443). Using trace level 5 in Java console we see that the crossdomain.xml is retrieved from http://192.168.1.1:443. And of course it doesn't work because the server listens only for HTTPS connections on port 443 (and not HTTP).
On the other hand, when we use HTTP protocol and open new WS (unsecured Websockets connection) to the server, the problem doesn't appear, because crossdomain.xml is retrieved from http://192.168.1.1:80 and it is completely correct.
As the problem was further investigated, we've made few more observations:
It is possible to provide alternative location of crossdomain.xml file using jnlp.altCrossDomainXMLFiles Java VM parameter. We've never succeed to make this parameter work for us though (tried both in java_arguments list and as lone applet parameter). The possible reason might be that the parameter should be used only with Webstart application (although it is not written specifically in specs).
While establishing Websockets connection, the connection stack trace is as follows:
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:790) at
sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at
sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:787) at
sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534)
at
sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90)
at
sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1431)
at
sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1429)
at java.security.AccessController.doPrivileged(Native Method) at
java.security.AccessController.doPrivileged(AccessController.java:713)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1428)
at com.sun.deploy.net.CrossDomainXML.check(Unknown Source) at
com.sun.deploy.net.CrossDomainXML.check(Unknown Source) at
sun.plugin2.applet.SecurityManagerHelper.checkConnectHelper(Unknown
Source) at
sun.plugin2.applet.AWTAppletSecurityManager.checkConnect(Unknown
Source) at
sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:624)
So we looked at the latest publicly available source code of CrossDomainXML.java class (back from 2010 though). And from the code it is evident, that http connection is always used while retrieving crossdomain.xml file from server, regardless what is the original browser connection.
So the questions are:
Might it be a JDK bug or the strict usage of HTTP for crossdomain.xml is by design?
Is jnlp.altCrossDomainXMLFiles JVM parameter supported inside Sandbox applet?
Is there a way access the latest version of com.sun.deploy.net.CrossDomainXML.java source code to get a full picture of what is going on?
Thank you very much in advance.
Best regards,
Mark
in order to get rid of the http://myhost/crossdomain.xml request, there is nothing you can do except adding something like this into your java.policy file:
permission java.net.SocketPermission "myhost:1024-", "connect, resolve";
You can restrict that to a specific certificate signer in order to enforce this policy, see https://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html#SocketPermission
We use it like this in an applet early in the init-process (applet constructor) and it works:
try
{
System.setProperty("jnlp.altCrossDomainXMLFiles", //
"http://www.some-domain.de/crossdomain.xml" //
+ ",https://www.secure-domain.de:8443/crossdomain.xml" //
);
}
catch (Exception e)
{
e.printStackTrace();
}
I downloaded Netbeans 7.4 and Java 7 Update 51. I get the below error when I try to start Java DB or derby connection from Netbeans. This is on a windows 8 PC. I downloaded the version for windows xp 32 bit at work. It works fine. I am not sure what is missing.
Thu Jan 16 00:48:23 EST 2014 : Security manager installed using the Basic server security policy.
Thu Jan 16 00:48:24 EST 2014 : access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
at java.security.AccessController.checkPermission(AccessController.java:559)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkListen(SecurityManager.java:1134)
at java.net.ServerSocket.bind(ServerSocket.java:375)
at java.net.ServerSocket.<init>(ServerSocket.java:237)
at javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
at org.apache.derby.impl.drda.NetworkServerControlImpl.createServerSocket(Unknown Source)
at org.apache.derby.impl.drda.NetworkServerControlImpl.access$000(Unknown Source)
at org.apache.derby.impl.drda.NetworkServerControlImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(Unknown Source)
at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(Unknown Source)
at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
This is what I did:
Find out exactly where the java home is by executing this instruction from NetBeans 7.4 :
System.out.println(System.getProperty("java.home"));
This is the output for my case:
C:\Program Files\Java\jdk1.7.0_51\jre
which is quite important for me, I was modifying another java.policy and took no effect and wasted me a couple of hours.
For reason of java.policy is an unix style file and read-only, I opened and edited it with notepad++ and executed as administrator (under the same java home):
C:\Program Files\Java\jdk1.7.0_51\jre\lib\security\java.policy
Add only these lines into the file after the first grant:
<pre>grant {
permission java.net.SocketPermission "localhost:1527", "listen";
};</pre>
Save the file, which is a little tricky for reason of the permission. But if you run notepad++ or any other edit program as administrator, you can solve the problem. Then try to connect the database from NetBeans, it works for me.
According to Java™ SE Development Kit 7, Update 51 Release Notes
Change in Default Socket Permissions
The default socket permissions assigned to all code including untrusted code have been changed in this release. Previously, all code was able to bind any socket type to any port number greater than or equal to 1024. It is still possible to bind sockets to the ephemeral port range on each system. The exact range of ephemeral ports varies from one operating system to another, but it is typically in the high range (such as from 49152 to 65535). The new restriction is that binding sockets outside of the ephemeral range now requires an explicit permission in the system security policy.
Most applications using client tcp sockets and a security manager will not see any problem, as these typically bind to ephemeral ports anyway. Applications using datagram sockets or server tcp sockets (and a security manager) may encounter security exceptions where none were seen before. If this occurs, users should review whether the port number being requested is expected, and if this is the case, a socket permission grant can be added to the local security policy, to resolve the issue.
This means that you have to explicity set the permissions for your application to be able to access the ports range between 1025 and 49151. You can therefore grant this permission by appending this line in the list of permissions granted:
Visit your Java Home Directory and access your policy file at $JAVA_HOME/jre/lib/security/java.policy and make the following changes.
grant{
//List of granted permissions
permission java.net.SocketPermission "localhost:1527", "listen";
}
See http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html for the description of the "problem". Search other-libs/javadb
Depending on your requirement, what I did was go and modify the default security policy
cd $JAVA_HOME/jre/lib/security
Edit java.policy (make a backup first!)
Add the following
grant codeBase "file:${java.home}}/../db/lib/*" {
permission java.security.AllPermission;
};
Note that this is my requirement.
I'm granting every app who uses the u51 JRE the permission to start Derby.
EDIT
The alternative would be to use a less permissive set of permissions like:
grant codeBase "file:${java.home}}/../db/lib/*" {
permission java.net.SocketPermission "localhost:1527", "listen,resolve";
};
NetBeans, by default, uses the derby version installed with GlassFish. So my permissions look like this on the Mac. It will be similar on Windows, but the path will need to change.
grant codeBase "file:/Applications/NetBeans/glassfish-4.0/javadb/lib/*" {
permission java.net.SocketPermission "localhost:1527", "listen,resolve";
};
Because the upper measures didn't work I added the following permission to the end of the main permission section:
permission java.net.SocketPermission "localhost:1527", "listen,resolve";
You can also solve the problem on a per-user basis by granting the needed permission in a file called .java.policy in your home directory.
Works on both Unix and Windows systems as documented here: http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html
This might be useful if the system-wide policy file gets overwritten, for example when updating your JDK, or if you don't have permission to edit the system file.
This is what I have in my $HOME/.java.policy:
grant {
permission java.net.SocketPermission "localhost:1527", "listen";
};
I got a bit fed up with Oracle's approach to security lately. They seem to be trying to protect us from ourselves in ways that would be more appropriate to naive users than programmers. My view is that the code I put on my own machine should be able to do whatever it needs to. It's my fault if I put code there that does bad things. Clearly not a universally reliable perspective, but it's worked for me for about 35 years. On that basis, I add this to my /lib/security/java.policy file:
grant codeBase "file:/-" {
permission java.security.AllPermission;
};
note that the file:/- matches any file on the system, and the grant block says, in essence, "if the class is loaded from this file system, then trust it".
This was doing my head in for a bit until I stumbled across the following in the NetBeans wiki
JavaDB grant permissions
JavaDB grant permissions
How to grant permissions for Java DB / How to start Java DB
Related to issue #239962
JDK 7u51 comes with some security improvements which are causing
problems with starting Java DB on this Java version.
When you try to start DB from NetBeans you will probably get the
Exception:
java.security.AccessControlException: access denied
("java.net.SocketPermission" "localhost:1527" "listen,resolve")
The same exception you will get while starting using script /db/bin/startNetworkServer
Because there is no suitable way to fix it on the NetBeans side and
this should be fixed on the side of the Java DB.
There are several ways how to deal with this problem. I will mention
only the easiest way. You have to start DB manually from command line.
• Start Java DB with -noSecurityManager argument.
(JDK 7u51 location)/db/bin/startNetworkServer -noSecurityManager
Although it’s not exactly a solution it is usable as a quick workaround.
My solution to this was to reinstall jdk 1.7.45, uninstall netbeans and reinstall it selecting the outdated jdk. Don't know if there is a way to change sdk in NB without reinstalling it but it worked this way.
Well, one alternative is to change the port JavaDB listens to, to be now in the high range (such as from 49152 to 65535).
Go to Window->Services, then right click Java DB and in "Java DB Properties Dialog" goto to "Database Location", which in my system is "C:\Users\ahernandeza.netbeans-derby"
In that directory edit or create the file derby.properties, and add/edit the line:
derby.drda.portNumber=XXXX
Where XXXX is the new port, in my case i put 51527 and worked just fine.
EDIT
At fisrt glance it worked, the service started just fine, but when creating or starting a database in NB, i got the error Unable to connect. CAnnot establish a connection to jdbc:derby://localhost:1527/sample
Although i changed the pprt to 51527, it tries to connect to 1527
If linux, then
file=`find $(dirname $(readlink -f $(which java)))/.. -iname 'java.policy'`; grep 1527 $file || sudo sed -i '0,/"listen"/{s/"listen".*/\0\n\tpermission java.net.SocketPermission "localhost:1527", "listen";/}' $file
cat $file
it automatically finds your java and changes permissions
I found a quick solution to this problem -
Start your JavaDB from the command line\terminal like so:
<base folder>/db/bin/startNetworkServer -noSecurityManager
Then it runs fine without adding new permissions.
The problem is the Java 7u51, it have a bug that affect Derby and other programs and libraries, I suggest to install the Java 7u45
I've tried to get my Java Applet to read from my text file, but I do not have sufficient privaleges to read the file when i run the applet in my browser.
I have tried to use policy files but I cannot seem to get them to work.
I later tried
System.setProperty("java.security.policy", "*filelocation*");
but i got this error
java.security.AccessControlException: access denied (java.util.PropertyPermission java.security.policy write)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.System.setProperty(Unknown Source)
at BIT.init(BIT.java:35)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
What ways can I get my applet to run in my browser? It works fine in Eclipse's applet viewer.
The reason is specified within the What Applets Can and Cannot Do. It clearly specifies that:
Applets that are not signed are restricted to the security sandbox,
and run only if the user accepts the applet. Applets that are signed
by a certificate from a recognized certificate authority can either
run only in the sandbox, or can request permission to run outside the
sandbox. In either case, the user must accept the applet's security
certificate, otherwise the applet is blocked from running.
Later it states that:
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.
To know about how to sign an Applet look here : How to Sign Applets Using RSA-Signed Certificates
You really ought to consider signing the applet.
This (short!) FAQ discusses both policies and signing:
http://www.coderanch.com/how-to/java/HowCanAnAppletReadFilesOnTheLocalFileSystem
Here is the offician documentation:
http://docs.oracle.com/javase/6/docs/technotes/guides/security/doprivileged.html
http://docs.oracle.com/javase/tutorial/deployment/applet/security.html
And here is a good (albeit old) tutorial:
http://faculty.kutztown.edu/spiegel/CSc421/SigningAnApplet.htm
I have an applet running in jnlp. My single jar file is signed. I accept the permissions prompt each time the JNLP client is launched. I can obtain the BasicService but it still throws a url permission denied exception when I try to follow a URI:
file:///D:\temp\test.txt
The file is present on all the Windows client machines I've tried and there are no security issues with opening it.
The issue happens when using a 32 or 64-bit JRE on the client. The server is 32-bit but I would think this irrelevant. The only clue (or red-herring perhaps) is that I get no security exception when the client and server are on the same host. If I use a remote client then I get the exception.
Whilst I needed to include the jnlp.jar file to compile the code, I assume it is not needed on the client if run using Java WebStart.
What else might you need to know? What else should I try?
Later that day...
Now this may or may not be a bug, it may be something wrong with the parameters in my jnlp file but I suspect that I'm using the wrong approach. Just to reitterate I'm trying to open a file:// url.
Here is what I am now doing:
I assumed that the Desktop facilities were only available in a Desktop Application - not an applet. I was wrong (and the documentation is scant - even on this hallowed site the only reference tells me to use JNLP Services for an Applet and Desktop for an Application) - Wrong (thankfully)
So you can use Desktop (having first checked that Desktop.isDesktopSupported() of course) in an applet - as long as you are running through WebStart not embedded as an applet.
I would propose the following approach to anyone.
See if Desktop is supported and use that.
Desktop.getDesktop().open(file);
If not then see if you can get the Basic JNLP Service.
BasicService bs = (BasicService)ServiceManager.lookup("javax.jnlp.BasicService");
and if that is available the use it with boolean openedOK = bs.showDocument(url);
Finally resort to the applet API.
AppletContext context = applet.getAppletContext();
context.showDocument(url, targetFrame);
I've got a signed java applet (using a self-signed-certificate) which has to access the user's file system. I have to do it, so please no replies ala "you shouldn't do it" :)
The thing is, when I execute the Applet from Firefox 3.0 / Mac, everything works as desired, I get all access just as it should.
When I use Safar 4 / Mac, I don't get access. The line I especially have problems with is System.getProperty() (although when I stub that out, the FS access doesn't work either)
String home = System.getProperty("user.home");
The Exception I get is the following:
java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
at java.lang.System.getProperty(System.java:628)
at de.samedi.searcher.Searcher.<init>(Searcher.java:49)
at de.samedi.searcher.Applet.getSearcher(Applet.java:193)
at de.samedi.searcher.Applet.getSearcher(Applet.java:187)
at de.samedi.searcher.Applet.addPatient(Applet.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at sun.plugin.javascript.invoke.JSInvoke.invoke(JSInvoke.java:19)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at sun.plugin.javascript.JSClassLoader.invoke(JSClassLoader.java:44)
at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(SecureInvocation.java:658)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.liveconnect.SecureInvocation$2.run(SecureInvocation.java:214)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.liveconnect.SecureInvocation.CallMethod(SecureInvocation.java:192)
at sun.plugin.liveconnect.SecureInvocation.access$300(SecureInvocation.java:52)
at sun.plugin.liveconnect.SecureInvocation$CallMethodThread.run(SecureInvocation.java:123)
As I said, this works perfectly on Firefox. Gotta check Windows Browser today...
Any Ideas?
Once you have your jar compiled and signed you should run the -verify option to ensure its signed properly.
If the verification is ok look at the installed certificates on your browsers.
I haven't done anything in Safari only IE, but I imagine there is a place similar to I.E. where you can at least view the installed certificates. I would verify the certificate is installed.
Also make sure your code is running in a privileged block.
String home = System.getProperty("user.home");
will always throw an error in 1.4 or higher. Unless you have edited the java.policy file for All Permissions
Try using this in combination with your signed jar.
String home = (String) AccessController.doPrivileged(new PrivilegedAction()
{
public Object run()
{
return System.getProperty("user.home");
}
});
Has the user accepted full access for your applet in Safari? Sounds like the security manager kicking in.
I remember having a similar problem in an older version of Safari (this was years ago), and the solution I found was adding a delay to the applet. It seemed Safari for some reason was allowing the applet to run before the user was given the "trust this applet" dialogue (other browsers would not start the applet until after the user granted or denied access). At that point the applet was not trusted and a security exception would occur. Even though the user would then allow trust, it was too late as the applet had already run and failed. I had to add a delay for safari, so it would not try doing anything that needed secure access until a period of time had passed, allowing the user to give access before the applet tried doing anything needing security access.