Java-байт код
Гораздо более интересным является разработка мобильных Java байт-кодов,
которые в терминах Java-технологии называются applets. Концепция
applets была специально разработана для использования в World Wide
Web. Задача applet-ов "оживить" Web. Типичным примером такого
применения applet-ов является приветствующий пользователя симпатичный
человечек из документации по программе HotJava. Для использования
applet-ов в язык гипертекстовой разметки HTML был введен специальный
тег APP, в котором указывается имя applet-а и параметры его вызова. При
этом обработка HTML-документа программой-интерфейсом происходит также
как и при встроенной в документ графике. Сначала запрашивается
документ, анализируется его содержание, и, если есть теги APP,
подгружаются applet-ы. После того как все applet-ы получены они могут
быть выполнены. Из этой схемы ясно, что программа интерфейс является
одновременно и интерпретатором байт-кода Java. Используя библиотеку
классов Java можно разработать довольно эффектные мультимедийные
страницы с движущейся графикой и звуком. Кроме этого применение
байт-кода позволяет организовать распределенные процедуры вычислений с
использованием различных серверов, с которыми можно взаимодействовать по
разным протоколам. Собственно возможность подключения новых протоколов
обмена также декларируется как одно из достоинств нового подхода. Но
даже у неискушенного пользователя сразу возникает закономерный вопрос о
безопасности машины, на которой запускается приложение. Как быть с
традиционным девизом "доверяй, но проверяй" при копировании
неизвестного программного обеспечения? Не надо быть семи пядей во лбу,
чтобы понять, что при использовании HotJava или Navigator пользователь
вольно или невольно запускает на своей машине чужие программы, которые
могут не только "оживить" HTML-страницы, но и несколько "встряхнуть"
владельца компьютера, на котором эти страницы "оживают". Ведь, в принципе
, applet-ы могут выполняться и незаметно для пользователя в фоновом
режиме. Ответ на этот вопрос прост: при разработке applet-ов
используется компилятор байт-кода, который имеет встроенную систему
безопасности, а сама программа просмотра, также анализирует получаемый
байт-код на наличие в нем запрещенных операций. Однако, если отбросить
детали механизмов защиты HotJava и Navigator, все сводится к запретам
записи информации на диск и по адресам оперативной памяти с
использованием адресной арифметики. Совершенно очевидно, что этого явно
недостаточно для построения надежно защищенной системы. Существует
масса способов внедрения в систему и без указанных выше действий,
не говоря просто о непроизводительном использовании ресурсов компьютера.
Первая ласточка уже появилась на свет в виде сообщения CERT о
возможности разработки applet-а, который использует брешь в системе DNS,
и подменяет IP адреса. Правда эта "дырочка" обнаружена в Navigator, а
не HotJava, но и популярность первой программы не идет ни в какое
сравнение популярностью продукта Sun. Netscape уже об'явила о том, что
в систему защиты будут внесены изменения и программа будет проверять
IP-адреса, с которыми работает applet на идентичность с IP-адресом
HTTP-сервера, с которого applet получен. Но естественно встает вопрос о
том как же быть в этом случае с распределенными вычислениями, которые
должны произвести революцию на Internet? В принципе существует пока два
способа защиты: запрет выполнения Java байт-кода программой интерфейсом
и использование проверенных страниц. Запретить выполнение можно,
включив специальный режим настройки программ HotJava и Navigator.
Вообще же говоря, в телеконференции comp.lang.java энтузиасты
новой технологии на проблему безопасности реагируют примерно так - мы
же честные люди, которые не собираются писать всякие пакости. Для
реальной же защиты в программу-интерфейс придется вставить полноценный
firewall с возможностями конфигурирования TCP/UDP портов и анализа
содержания пакетов, и то, как показывает практика, это не приводит к
стопроцентной безопасности.
