Доступ запрещен (java.net.SocketPermission 127.0.0.1:8080 connect, resolve)

У меня есть Java-апплет, вставленный на простой HTML-странице, расположенной в http://localhost:8080/index.html:

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

Java-апплет имеет метод, похожий на приведенный ниже код:

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();
}

Когда я запускаю код апплета из JavaScript следующим образом:

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

Я получаю следующую ошибку:

доступ запрещен (java.net.SocketPermission 127.0.0.1:8080 подключиться, разрешить)

Кажется, что Java-код разрешает домен localhost эквивалентному IP-адресу и, следовательно, повышает уровень безопасности междоменной безопасности. Он отлично работает, когда я выполняю тот же код из http://127.0.0.1:8080/index.html. Файл lib.jar подписан.

Во всяком случае, чтобы избежать этого?

Ответы

Ответ 1

Я столкнулся с той же проблемой после установки Java 6 Update 22. Мой аплет был в сети в течение нескольких лет без сообщений об ошибках. Когда я понижаюсь до версии 6 Update 21, все работает отлично. Мой апплет не подписан.

РЕШЕНИЕ: Мне потребовалось, чтобы найти причину проблемы. Фактически в моем случае было несколько факторов, вызывающих ошибку безопасности. Проблема была решена с помощью файла crossdomain.xml. Java-апплет попытался загрузить файл crossdomain, не удалось, и даже не потрудился отображать ошибку в консоли java (уровень отладки 5). Java попыталась загрузить файл из ip-адреса моего домена (http://ip-address/crossdomain.xml), а не корневого сайта моего сайта (http://domain-name/crossdomain.xml). Думаю, это лучше для аспекта безопасности? Затем мне пришлось настроить веб-сервер, чтобы открыть crossdomainfile по IP-адресу. В моем случае я удалил веб-сайт по умолчанию в ISS по соображениям безопасности и должен был создать новый веб-сайт. Затем я обнаружил, что java-апплет не работает с файлами crossdomain, которые я использую со вспышкой:

<?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>

Мне пришлось удалить узлы управления сайтом и allow-http-request-headers из узлов из xml файла, чтобы заставить апплет работать.

Ответ 2

Я думаю, что я слишком поздно, но так или иначе... Ребята, вы не можете поверить, насколько легко решить эту проблему.

Проблема в том, что код Java-апплета, вызываемый из JavaScript, имеет только разрешения, являющиеся пересечением кода JavaScript и вашего кода апплета, - и, как-то, разрешения JavaScript рассматриваются как меньше, что приводит к этому Исключению.

Вот что я сделал: предположим, что у вас есть функция innocentFunc(), которая выдает исключение java.net.SocketPermission, поэтому ваш код выглядит примерно так:

String s = innocentFunc();

Теперь вы можете изменить его на что-то вроде этого:

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

Этот вызов AccessController в основном указывает на виртуальную машину Java, что выполняемый код не должен подчиняться разрешениям из цепочки вызовов, а скорее только разрешениям вызывающего абонента.

Конечно, вы должны сделать что-то подобное, только убедившись, что этот вызов innocentFunc не может сделать ничего плохого, даже если он вызван вредоносным кодом.

Ответ 3

Я получаю то же самое с Update 22, а не Update 21.

Я использую TinyPlayer апплет, который я контролирую с помощью JavaScript.

Я загружаю аудиофайлы из одного домена (mydomain.example.com, IP 1.2.3.4) в качестве страницы, на которую загружается апплет - все ссылается на относительные URL-адреса.

Когда я пытаюсь воспроизвести звук, он не воспроизводится, и я получаю: доступ запрещен (java.net.SocketPermission 1.2.3.4:80 подключиться, разрешить)

Глядя на журналы доступа, я получаю запрос на crossdomain.xml прямо перед этим. Но уловка в том, что Java не запрашивает crossdomain.xml от mydomain.example.com/crossdomain.xml ... но вместо этого 1.2.3.4/crossdomain.xml

Обходной путь, который, кажется, работает для меня, - это настроить виртуальный хост, который отвечает за IP-адрес 1.2.3.4, и предоставить ему crossdomain.xml, чтобы Java могла найти crossdomain.xml в (неправильном) место, которое оно ищет.

Я просто тестировал содержимое:

<?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>

... но это возможно сделать это более ограничительным.

При этом звук воспроизводится правильно.

Ответ 4

Просто добавьте здесь кое-что, что точно соответствует проблеме, которую я получаю - она специально упоминает управление апплетом с помощью JavaScript.

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

Исправление для CVE-2010-3560 может привести к некоторые апплеты Java, работающие в новый Java Plug-in, чтобы прекратить работу, если они встроены в веб-страницы, которые содержать JavaScript, который вызывает Java для выполнения действий, которые требуют разрешения сетевой безопасности. Эти апплеты могут выйти из строя с помощью сети исключение безопасности обстоятельства, если служба имен который разрешил исходную веб-страницу Имя хоста URL не возвращает совпадающее имя в результате обратный поиск адреса.

Их предложение состоит в том, чтобы добавить специальную сумасшедшую запись Just-for-Java в DNS, например:

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

Ответ 5

IIRC, политика одинакового происхождения JavaScript предотвращает доступ к тому же хосту/другому порту. PlugIn LiveConnect применяет эту политику только для локального хоста.

Ответ 6

Смотрите: http://download.oracle.com/javase/tutorial/deployment/applet/security.html

Неподписанные апплеты могут выполнять следующие операции:

Они могут делать сетевые подключения к хосту, из которого они пришли.

Если Java не разрешает исходную систему на localhost, апплет не сможет открывать сокеты.

Ответ 7

У меня была аналогичная проблема, и это происходит только тогда, когда я использую "localhost" в качестве части URL-адреса страницы с апплетом. Когда я использовал URL-адрес с фактическим именем хоста или IP-адресом в качестве части URL-адреса, проблемы не произошло. Я не уверен, что это дефект для плагина Java...

Например, когда я использовал URL-адрес, например http://localhost:9080/app_id/appletPage, возникла проблема, но когда я использую URL-адрес, используя фактическое имя IP или хоста, проблема не возникала.

Ответ 8

Я не думаю, что файл crossdomain.xml более ограничительный, в настоящее время Java-апплеты поддерживают только (domain = "*" )

см. здесь http://www.oracle.com/technetwork/java/javase/index-135519.html#CROSSDOMAINXML

Ответ 9

Вы должны проверить разрешения виртуального каталога.

Ответ 10

Обновление от @Kristian выше спасло мой день.

У меня был access denied (java.net.SocketPermission <server_ip>:<server port> connect,resolve) из апплета в веб-приложении.

В нашем DNS произошли изменения, так что IP-адрес балансира нагрузки сервера приложений не разрешал имя с доменом. Поэтому подозрительное "междоменное соединение" с апплета на сервер блокировалось. Я добавил crossdomain.xml с

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

до <tomcat-home>/webapps и проверил, что он доступен с помощью http://<server name>:<server port>/crossdomain.xml