доступ запрещен (соединение java.net.SocketPermission 127.0.0.1:8080, разрешение

Question

У меня есть 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 connect, решите)

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

Есть ли способ избежать этого?

Answer 1

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

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

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

Answer 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 не может сделать ничего плохого, даже если он вызван вредоносным кодом.

Answer 3

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

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

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

Их предложение заключается в добавлении в DNS специальной сумасшедшей записи "просто для Java", например:

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

Answer 4

Я получаю то же самое с обновлением 22, а не с обновлением 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>

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

Обновление от @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

Answer 9

Вам следует проверить права доступа к вашему виртуальному каталогу.

Answer 10

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

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