Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации

Смешивание Подписанной и Безопасности Приложения и Апплета Обеспечения Кода Без знака

Java Богатое Руководство по Интернет-приложениям > Безопасность> Смешивание Подписанной и Безопасности Приложения и Апплета Обеспечения Кода Без знака

Следующие темы затрагиваются:

Краткий обзор

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

Снимок экрана Смешанного Диалогового окна Предупреждения Кода

Щелчок Больше информации... соединяется, переводит следующую панель в рабочее состояние:

Снимок экрана Большего количества информационной Панели

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

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

Отметьте: Если какие-либо понятия неясны, такой как, как изменить файл манифеста, или как подписать файл фляги, или как использовать конфигурационный файл развертывания, см. для получения дополнительной информации для полезных ссылок.

Смешанные Опции Защиты Кода для Пользователей

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

Примечание версии: Чтобы использовать в своих интересах эти усовершенствования в защите, пользователи должны установить Java SE или Java для Бизнеса 6 Обновлений 19 выпусков (или позже) и использовать Плагин Java, который включается по умолчанию. Чтобы использовать более ранний JRE с Плагином Java, Вы должны установить Java для Бизнеса 5.0 Обновлений 24 выпуска (или позже) или Java для Бизнеса 1.4.2_26 выпуск (или позже), чтобы включить смешанному усовершенствованию в защите кода для тех семейств выпуска.

Развертывание Подписанных Приложений и Апплетов Надежно Без Смешанного Предупреждения Кода

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

Два атрибута декларации JAR доступны для развертывания подписанных приложений и апплетов. Диалоговое окно предупреждения не выводится на экран, когда один из этих явных атрибутов включается.

Разработчики и deployers должны проверить, что их подписанная Сеть Java Запускает приложения и апплеты, чтобы определить, смешивают ли они подписанный и код без знака. Если пользователи этих приложений и апплетов могут непреднамеренно загрузить эти приложения, и апплеты от веб-сайтов жулика, развертываясь или повторно развертываясь с одним из следующих атрибутов нужно рассмотреть. Существующие подписанные фляги должны быть оставлены после добавления одного из этих явных атрибутов. Отметьте: исходный код классов и ресурсов не требуется для того, чтобы уйти в отставку с явными записями.

Trusted-Only Атрибут

Для приложений и апплетов, которые не требуют компонентов без знака, Trusted-Only атрибут должен использоваться. Никакое диалоговое окно предупреждения не будет выведено на экран и приложение или апплет, который загружается, файл фляги, содержащий этот атрибут, не будет загружать недоверяемых классов или ресурсов. Этот атрибут препятствует тому, чтобы подписанное приложение или апплет повторно ставились целью с компонентами без знака. Можно определить Trusted-Only: истина в файле манифеста. Например:

Manifest-Version: 1.0
Trusted-Only: true
Created-By: 1.6.0-internal (Sun Microsystems Inc.)

Все классы и ресурсы в приложении или апплете должны быть подписаны и доверяться.

Trusted-Library Атрибут

Для приложений и апплетов, которые разрабатываются, чтобы позволить компоненты без знака, Trusted-Library атрибут должен использоваться. Никакое диалоговое окно предупреждения не будет выведено на экран и приложение, или апплет может загрузить файлы фляги, содержащие недоверяемые классы или ресурсы. Этот атрибут предотвращает подписанные компоненты в приложении или апплете от того, чтобы быть повторно ставившимся целью с компонентами без знака. Можно определить Trusted-Library: true в файле манифеста. Например:

Manifest-Version: 1.0
Trusted-Library: true
Created-By: 1.6.0-internal (Sun Microsystems Inc.)

Все классы и ресурсы в файле фляги, содержащем этот явный атрибут, должны быть подписаны и доверяться.

В смешанном приложении кода или апплете, все подписанные классы и ресурсы должны быть включены в файлы фляги, которые содержат Trusted-Library атрибут.

Все фляги доверяемой библиотеки загружаются в отдельный выделенный загрузчик class, который уникален для экземпляра апплета или приложения. Это Trusted-Library загрузчик является теперь родителем нормальной Сети, Запускаются или апплет загрузчик class. Для назад совместимости с исходным порядком поиска оба загрузчика сотрудничают, чтобы реализовать общий путь class. Непротиворечивый с предшествующими выпусками, файлы фляги лениво загружаются и открываются как необходимый найти требуемые классы и ресурсы.

Код в файле фляги, который должен быть отмечен с Trusted-Library явный атрибут, возможно, должен быть изменен немного, если он использует вызовы, которые являются зависимым загрузчиком class, таким как единственная версия параметра Class.forName(), Class.getResource(), и Class.getResourceAsStream(), некоторые разновидности java.util.ResourceBundle.getBundle(), и любые другие методы, которые работают относительно загрузчика определения их непосредственной вызывающей стороны. Изменения только должны быть произведены, если требуемый class или ресурс могли бы быть найдены в файле фляги, который не является a Trusted-Library (и поэтому загружается нормальной Сетью, Запускаются или апплет загрузчик class).

Код в a Trusted-Library может искать нормальный загрузчик, вызывая Thread.currentThread().getContextClassLoader(). Отметьте, однако, что есть редкие обстоятельства в который getContextClassLoader() может возвратиться null. Например, это может произойти, когда сборщик "мусора" использует системный поток JRE, чтобы вызвать Object.finalize() метод недостижимого экземпляра.

Если Вы должны преобразовать class в Class.getResource() или Class.getResourceAsStream() к их ClassLoader эквиваленты, не забудьте корректировать строковый параметр как описано документацией для тех двух методов. Если исходное имя ресурса началось '/', тогда это было абсолютное имя и продвижение '/' просто потребности, которые будут удалены. Иначе, определите, если экземпляр class, который был целью getResource вызов находится в именованном пакете. Если это - массив, следует сначала определить базовый компонентный тип массива. Вызвать Class.getName() на class или компоненте вводят экземпляр. Если имя class содержит кого-либо '.' символы, именно в именованном пакете должны будут предварительно ожидаться к исходному имени ресурса. Определите имя пакета, удаляя любые символы после, и включая, запаздывание '.' символ. Затем, замените любого остающегося '.' символы с '/' символы. Наконец, добавьте запаздывание '/' и добавьте исходную строку имени ресурса. Эту новую строку можно теперь передать к ClassLoader версия getResource() или getResourceAsStream() методы.

Обычно, забота должна быть проявлена, чтобы гарантировать, что код в доверяемой библиотеке пишется осторожным и безопасным способом и иначе совместимый с тем, чтобы быть загруженным в отдельном экземпляре загрузчика class от любых остающихся фляг, которые являются частью приложения и загружаются нормальным загрузчиком.

Смешанный FAQ Кода

Для получения дополнительной информации

Oracle и/или его филиалы Авторское право © 1993, 2012, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами