access denied (java.net.SocketPermission 127.0.0.1:8080 connect,resolve)

Question

I have a Java Applet inserted on a simple HTML page located at http://localhost:8080/index.html:

<applet id="applet" code="SomeCode.class" archive="lib.jar" Width="1" Height="1"></applet>

The Java Applet has a method that looks similar to the code below:

public void PostStuffToServer() {
  String server = "http://localhost:8080/PostHandler.ashx";
  URL u = new URL(server);
  URLConnection con = u.openConnection();
  con.setDoOutput(true);
  con.getOutputStream().write(stream.toByteArray());
  con.connect();
}

When I execute the applet code from JavaScript like so:

obj = document.getElementById('applet');
obj.getClipboardImageURL();

I get the following error:

access denied (java.net.SocketPermission 127.0.0.1:8080 connect,resolve)

It seems like the Java code resolves the domain localhost to its equivalent IP address and therefore raises a cross domain security restrain. It works fine when I execute the same code from http://127.0.0.1:8080/index.html. The lib.jar file is signed.

Is there anyway to avoid this?

Redskin

Try signing lib.jar and all other external jar files you are using – Delia

Do not use localhost! I will explain also why: there is no guarantee localhost is 127.0.0.1 at all. Also use getCodeBase() always from applets, do not use hard-coded locations. – Kokaras

Answer 1

I encountered the same problem after installing Java 6 Update 22. My applet has been online for several years with no reported errors. When I downgrade to version 6 Update 21, everything works perfect. My applet is not signed.

SOLUTION: It took me ha while to find the cause of the problem. Actually in my case there were several factors causing the security error. The problem was solved by the crossdomain.xml file. The Java applet tried to download the crossdomain file, failed, and did not even bother to display an error in the java console (debug level 5). Java tried to download the file from the ip adress of my domain (http://ip-address/crossdomain.xml), and not the root of my website (http://domain-name/crossdomain.xml). I guess it is better for the security aspect? I then had to configure the webserver to expose the crossdomainfile on the IP address. In my case I have removed the default website in ISS for security reasons, and had to create a new website. I then discovered that the java applet did not work with the crossdomain files i use with flash:

<?xml version="1.0"?>
<cross-domain-policy>
   <site-control permitted-cross-domain-policies="master-only"/>
   <allow-http-request-headers-from domain="*" headers="*"/>
   <allow-access-from domain="*" />
</cross-domain-policy>

I had to remove the site-control and allow-http-request-headers-from nodes from the xml file in order to make the applet work.

Vanadous

Answer 2

I think I'm too late, but anyways... Guys you cannot believe how easy a solution this problem has.

The problem is that Java applet code called from JavaScript has only permissions that are the intersection of the JavaScript's code and your applet code - and somehow the JavaScript's permissions are seen as less, which results in this Exception.

Here is what I did: assume you have a function innocentFunc() that throws the java.net.SocketPermission exception, so your code is something like so:

String s = innocentFunc();

Now what you can do is to change it to something like so:

String s = AccessController.doPrivileged(
      new PrivilegedAction<String>() {
          public String run() {
              return innocentFunc();
          }
        }
     );

This AccessController call basically states to the Java Virtual Machine that the code it runs should not obey to the permissions from the call chain, but rather only the caller's permissions in its own.

Of course, you should do something like this only after making sure that this innocentFunc call can't do anything bad, even if invoked by malicious code.

Raindrop

I just wanted to reply with a similar solution. Seeing your's, I instead took the liberty to edit it, adding some explanation. – Molasses

Answer 3

I'm getting the same thing with Update 22, and not Update 21.

I'm using the TinyPlayer applet, which I'm controlling via JavaScript.

I'm loading audio files from the same domain (mydomain.example.com, IP 1.2.3.4) as the page the applet is loading on - everything is referenced using relative URLs.

When I try to play the audio, it fails to play and I get: access denied (java.net.SocketPermission 1.2.3.4:80 connect,resolve)

Looking at the access logs, I get a request for crossdomain.xml right before this happens. But the catch is that Java isn't asking for a crossdomain.xml from mydomain.example.com/crossdomain.xml ...but instead from 1.2.3.4/crossdomain.xml

The workaround that seems to work for me is to set up a virtual host that responds for the IP address 1.2.3.4, and give it a crossdomain.xml, so that Java can find the crossdomain.xml in the (wrong) place that it's looking for it.

I just tested with the contents:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

...but it's probably possible to make this more restrictive.

With that in there, the audio plays correctly.

Expulsive

Answer 4

Just to add, there's some stuff here which exactly matches the issue I've been getting - it specifically mentions controlling an applet with JavaScript.

http://www.oracle.com/technetwork/java/javase/6u22releasenotes-176121.html

The fix for CVE-2010-3560 could cause certain Java applets running in the new Java Plug-in to stop working if they are embedded in web pages which contain JavaScript that calls into Java in order to perform actions which require network security permissions. These applets may fail with a network security exception under some circumstances if the name service which resolved the original web page URL host name does not return a matching name as the result of a reverse address lookup.

Their suggestion is to add a special crazy just-for-Java A record to the DNS, like:

10.11.12.13    foo.bar.com.auth.13.12.11.10.in-addr.arpa

Expulsive

Answer 5

IIRC, the JavaScript same-origin policy prevents access to same-host/different-port. The PlugIn's LiveConnect enforces this policy for localhost only.

Laufer

I'm not sure what thies means? Does this mean that if I deploy this code to production (e.g. www.productiondomain.com) the code will work and not resolve to the IP address? – Redskin

It should do. (Unless that host name resolves to localhost, of course.) – Laufer

you can connect to any port at the same host from an applet – Kokaras

Answer 6

See: http://download.oracle.com/javase/tutorial/deployment/applet/security.html

Unsigned applets can perform the following operations:

They can make network connections to the host they came from.

If Java does not resolve the originating system to localhost then the applet will not be able to open sockets.

Gyrostat

Answer 7

I had the similar issue and it only occurs when I use the "localhost" as a part of the URL for the page with the applet. When I used the URL with the actual host name or IP address as a part of the URL, the problem didn't happen. I am not sure this is a defect for the Java plug-in...

For example when I used the URL like http://localhost:9080/app_id/appletPage the problem occurred but when I use the URL by using the actual IP or host name, the problem did not occur.

Harpp

Answer 8

I don't think is possible to made the crossdomain.xml file more restrictive, at current time Java applets only support the (domain="*")

see here http://www.oracle.com/technetwork/java/javase/index-135519.html#CROSSDOMAINXML

Dusk

Answer 9

You should check your virtual directory permissions.

Fionafionna

Answer 10

Update from @Kristian above saved my day.

I had access denied (java.net.SocketPermission <server_ip>:<server port> connect,resolve) from an applet in a web application.

There had been change in our DNS, such that the IP of the load-balancer of the application server was not resolving to a name with domain. Therefore the suspected "cross-domain connection" from applet back to server was blocked. I added crossdomain.xml with

<?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>

to <tomcat-home>/webapps and checked that it is accessible with http://<server name>:<server port>/crossdomain.xml

Sutherland