Сокетное соединение с исходным сервером неподписанного Java-апплета

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

Ошибка установления сокетного соединения:
java.security.AccessControlException: 
  доступ запрещен (java.net.SocketPermission 127.0.0.1:11000 подключиться, разрешить)

Код, вызвавший исключение:

private void sendMsg(String msg) {
   Socket s = null;
   try {
      s = new Socket("localhost", 11000);
   }
   catch (Exception e) {
      System.err.println("Error establishing socket connection:");
      e.printStackTrace();
      return;
   }

   try {
      OutputStream out = s.getOutputStream();
      out.write(msg.getBytes());
      out.flush();
      s.shutdownOutput();
      s.close();
   }
   catch (Exception e) {
      System.err.println("Error in writing to the socket:");
      e.printStackTrace();
   }

Сначала я подумал, что в моем коде есть проблема, из-за которой моя неопытность заставила меня скучать. Тем не менее, я получаю то же исключение при попытке запустить пример Talk Server из официальных учебников по Java. Это приводит меня к мысли, что у меня действительно есть проблема с настройкой или неправильное понимание ограничений безопасности по умолчанию. Предотвращает ли менеджер безопасности по умолчанию открытие сокетов на машине, на которой запущен апплет, даже если это также машина, обслуживающая апплет? Если это так, то это проблема для меня, потому что развернутая система должна позволять пользователю, вошедшему в систему на фактическом сервере, использовать тот же апплет, что и удаленный пользователь. Есть ли способ обойти исключение, которое я получаю, которое не включает в себя подписание апплета? Я не хочу идти на неприятности, если не нужно.

ПРИМЕЧАНИЕ. Я знаю, что было бы лучше, чтобы пользователи не обращались к апплету с сервера. Это был не оригинальный дизайн, но, к сожалению, практические соображения заставили меня пойти на компромисс.

ОБНОВЛЕНИЕ: Просмотр страницы апплета с веб-сервера решает проблему. Даже если сервер является локальным. Обновление безопасности в Java 1.6.0_11 применяется только к апплетам, загружаемым непосредственно из локальной файловой системы.

Источник

3 ответа

Решение

Это связано с изменением плагина, введенного в недавнем обновлении безопасности. Сожалею! Апплетам, загруженным из локальной файловой системы, больше не предоставляются разрешения сокетов для localhost.

Решение 246387: Уязвимость безопасности в среде выполнения Java может позволить коду, загруженному из локальной файловой системы, получить доступ к LocalHost

Java Runtime Environment (JRE) позволяет коду, загруженному из локальной файловой системы, получать доступ к localhost. Это может позволить коду, который злонамеренно помещается в локальную файловую систему и затем запускается, иметь сетевой доступ к локальному хосту, который иначе не был бы разрешен, если бы код был загружен с удаленного хоста. Это может быть использовано для кражи файлов cookie и сеансов захвата (для доменов, которые отображают имя на локальный хост).

Источник

Я подозреваю, что вы запускаете апплет из локального файла HTML (например, applet.html), что вызывает ошибку, о которой упоминает Том Хоутин.

Вместо этого запустите веб-сервер (например, Tomcat) на своем компьютере и получите доступ к файлу через http://localhost/applet.html

Вероятно, было бы лучше открыть порт сокета из сервлета в вашем веб-сервере. Таким образом, ваш веб-сервер управляет всей вашей системой, и это может быть проще для переноса между компьютерами.

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

Источник

Oracle знает об этой проблеме Java, которая строго ограничивает использование апплетов: уязвимость безопасности в среде выполнения Java может позволить коду, загруженному из локальной файловой системы, получить доступ к LocalHost - это то, что они говорят. Это был Bug Id 6704154

И их решение таково: для этой проблемы не существует обходного пути; этот "обходной путь" был выпущен 03 декабря 2008 г. Итак, если вы хотите использовать Applets с Tomcat или любым другим подобным сервером, вам придется вернуться к Java 1.4.2

Мне потребовалось больше недели, чтобы полностью документировать эти факты, и так как я в одной лодке.

Источник
Другие вопросы по тегам