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

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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