Tooprogram.ru

Компьютерный справочник
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Java предупреждение системы безопасности

Как отключить Java» предупреждение системы безопасности » всплывающее окно?

есть ли способ отключить это всплывающее окно безопасности Java? Я использую только сайты в своей интрасети, и каждая страница содержит более 40 апплетов, которые генерируют новый идентификатор при каждой загрузке. Из-за этого, каждый раз, когда страница посещается он требует, чтобы нажать кнопку «Выполнить» 40+ раз.

OS: Windows 7

браузер: IE 10

вот мое решение:

  1. Открыть Internet Explorer
  2. нажмите на Сервис и выберите Свойства обозревателя
  3. нажать на вкладку Безопасность и нажмите кнопку «Другой»
  4. в разделе «Разное » измените» отображать смешанное содержимое», чтобы включить.

7 ответов

установка этой опции для отключения проверки удалит это всплывающее окно. Да, это риск для безопасности, но я уверен, что отключен был уровень безопасности по умолчанию предыдущих версий Java. Я уверен, что всплывающее окно обеспечивает дополнительную безопасность, но в среде где каждый поставщик выпускает свои собственные сумасшедшие веб-приложения и обновления мало и далеко друг от друга, это больше хлопот, чем безопасность. К сожалению, этот параметр управляется файлом под профиль каждого пользователя. Конкретно C:UsersusernameAppData Locallow каталогСолнцеЯваразвертыванияразвертывания.свойства. Я не могу подумайте о том, как от верхней части моей головы, чтобы подтолкнуть эту настройку через группу политика. Если кто-то приходит вверх с решением, то пожалуйста вывесьте его в Примечание. До тех пор мы будем придерживаться Java 6 Update 19 для наша окружающая среда.

Я использую java 7 обновление 17. Что вы можете сделать, это установить флажок «Не показывать это снова для этого приложения» (флажок на изображении, которое вы предоставили). Вы также можете попробовать изменить настройки в Панель Управления Java но я не уверен, будет ли это работать: в Панели Управления Java на вкладке Безопасность измените уровень безопасности с высокого на средний или низкий, а затем перейдите на вкладку Advance и установите флажок «скрыть предупреждение и запустить с защитой» или если он не работает затем выберите «Отключить проверку».

текстовый документ в этой папке по имени развертывания.свойства c:windowssunJavadeploymentdeployment.свойства

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

этот файл будет изменить значение по умолчанию для каждого пользователя на компьютере, даже если у них уже есть развертывания.файл свойств в папке appdata. Вы можете убедиться, что настройки вступают в силу, когда вы откройте Панель управления java 32, так как она считывает настройки.

вот некоторые из вещей, которые мы вкладываем в наши развертывания.файл свойств.

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

обратите внимание, что в пути требуются дополнительные косые черты. Двоеточия являются зарезервированными символами, а обратная косая черта является escape-символом.

Java предупреждение системы безопасности

Что нужно делать при появлении предупреждения системы безопасности Java?

В Java 7 Update 21 реализованы изменения режима работы подключаемого модуля Java, позволяющие пользователю принимать решения на основе более полной информации перед запуском апплета Java в браузере. Перед запуском содержимого Java в браузере отображается запрос на разрешение запуска. Для пользователей, разработчиков и системных администраторов, которым требуется дополнительная техническая информация, используйте ссылки, указанные в конце этой статьи.

Уровни риска
Представленные сообщения зависят от различных факторов риска, таких как использование предыдущих версий Java или запуск кода апплетов, не подписанного в доверенном центре сертификации. В приложениях с более низким уровнем риска отображается простое информационное сообщение. В таких случаях вы можете отказаться от получения в будущем подобных сообщений для приложений от данного издателя.

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

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

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

» Дополнительная информация об изменениях, относящихся к подписанному коду

Приложение Java с сертификатом, выпущенным доверенным центром сертификации

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

На что нужно обратить внимание:

  • Имя издателя: отображается
  • Отображаемые значки: логотип Java или логотип поставщика и синий информационный щит


Диалоговое окно может отличаться в зависимости от способа развертывания приложения.
» Дополнительная информация о других диалоговых окнах доверенного подписанного сертификата

Необходимые действия:

  • Проверьте информацию об имени, издателе и расположении, отображаемую в диалоговом окне. Если информация полностью или частично не совпадает, рекомендуется нажать кнопку Отмена.
Сообщение, отображаемое в диалоговом окне, будет различаться, в зависимости от того, запрашивает ли приложение следующее:
Неограниченный доступ (Привилегированный)Приложение будет запущено с неограниченным доступом, что может подвергнуть компьютер и личные данные пользователя риску. Выполняйте это приложение только в том случае, если вы доверяете расположению и издателю.
Ограниченный доступ (Песочница)Приложение будет запущено с ограниченным доступом, для того, чтобы обеспечить защиту для компьютера и личных данных пользователя.

Приложение Java без сертификата (неподписанное)

Начиная с Java 7 (обновление 51) приложения, у которых нет сертификата (т. е. неподписанные приложения) или информации об имени и издателе, по умолчанию блокируются. Выполнение таких приложений потенциально небезопасно и представляет высокий уровень риска.

На что нужно обратить внимание:

  • Заголовок диалогового окна: Приложение заблокировано или Приложение Java заблокировано (Java 8)
  • Имя издателя: издатель не указан
  • Заголовок сообщения: Приложение заблокировано настройками безопасности или Приложение заблокировано настройками безопасности Java (Java 8)
  • Сообщение: Ваши настройки безопасности заблокировали выполнение недоверенного приложения
    В целях обеспечения безопасности выполняемые приложения теперь должны соответствовать требованиям уровней безопасности «Высокий» или «Очень высокий» либо входить в список сайтов-исключений (для версий 8u20 и выше).

Настоятельно рекомендуется не выполнять такие приложения. Однако если вы понимаете степень риска и все равно желаете выполнить данное приложение, вы можете добавить URL-адрес этого приложения в список Exception Site List на вкладке «Security» (Безопасность) панели управления Java. Если добавить в данный список URL-адрес приложения, оно будет выполняться после появления нескольких предупреждений безопасности.
» Как управлять списком сайтов-исключений и настраивать его?

Приложение Java с сертификатом с истекшим сроком действия, выпущенным доверенным центром сертификации

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

На что нужно обратить внимание:

  • Заголовок диалогового окна: Приложение заблокировано или Приложение Java заблокировано (Java 8)
  • Заголовок сообщения: Приложение заблокировано настройками безопасности или Приложение заблокировано настройками безопасности Java (Java 8)
  • Предупреждение: Ваши настройки безопасности заблокировали выполнение приложения с истекшим или еще недействительным сертификатом
    В целях обеспечения безопасности выполняемые приложения теперь должны соответствовать требованиям уровней безопасности «Высокий» или «Очень высокий» либо входить в список сайтов-исключений (для версий 8u20 и выше).

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

Настоятельно рекомендуется не выполнять такие приложения. Однако если вы понимаете степень риска и все равно желаете выполнить данное приложение, вы можете добавить URL-адрес этого приложения в список Exception Site List на вкладке «Security» (Безопасность) панели управления Java. Если добавить в данный список URL-адрес приложения, оно будет выполняться после появления нескольких предупреждений безопасности.
» Как управлять списком сайтов-исключений и настраивать его?

Читать еще:  Сайт для проверки ссылок на вирусы
Сообщение, отображаемое в диалоговом окне, будет различаться, в зависимости от того, запрашивает ли приложение следующее:
Неограниченный доступ (Привилегированный)Приложение будет запущено с неограниченным доступом, что может подвергнуть компьютер и личные данные пользователя риску. Предоставленная информация не является надежной или известной, поэтому рекомендуется не запускать это приложение за исключением случаев, когда его источник знаком пользователю
Ограниченный доступ (Песочница)Приложение будет запущено с ограниченным доступом, для того, чтобы обеспечить защиту для компьютера и личных данных пользователя.

Приложение Java с сертификатом, выпущенным неудостоверенным источником

Начиная с Java 7 (обновление 51) приложения с самоподписанными сертификатами по умолчанию блокируются. Использование приложений этого типа представляет самый высокий уровень угрозы безопасности, так как издатель не определен, а приложение может получить доступ к личным данным на вашем компьютере.

Отображение на экране:

  • Заголовок диалогового окна: Приложение заблокировано или Приложение Java заблокировано (Java 8)
  • Имя издателя: издатель не указан
  • Заголовок сообщения: Приложение заблокировано настройками безопасности или Приложение заблокировано настройками безопасности Java (Java 8)
  • Сообщение: Ваши настройки безопасности заблокировали выполнение самоподписанного приложения
    В целях обеспечения безопасности выполняемые приложения теперь должны соответствовать требованиям уровней безопасности «Высокий» или «Очень высокий» либо входить в список сайтов-исключений (для версий 8u20 и выше).

Настоятельно рекомендуется не выполнять такие приложения. Однако если вы понимаете степень риска и все равно желаете выполнить данное приложение, вы можете добавить URL-адрес этого приложения в список Exception Site List на вкладке «Security» (Безопасность) панели управления Java. Если добавить в данный список URL-адрес приложения, оно будет выполняться после появления нескольких предупреждений безопасности.
» Как управлять списком сайтов-исключений и настраивать его?

Проверка действия отзыва для приложений Java

Начиная с версии Java 7u25, перед попыткой запуска любого приложения Java подпись сертификата будет проверяться на соответствие выдавшему его центру сертификации с помощью списков отзыва сертификатов (CRL) и протокола Online Certificate Status Protocol (OCSP). Таким образом проверяется, не был ли используемый для подписи приложения сертификат отозван выдавшим его центром сертификации.

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

На что нужно обратить внимание:
Проверка действия отзыва может возвращать разные сообщения на основе проверки:

  • Сертификат отозван
  • Не удалось проверить сертификат
  • Невозможно установить соединение с центром сертификации

Сертификат отозван. Приложение выполнено не будет.

Это диалоговое окно отображается при запуске приложения с сертификатом, который был отозван центром сертификации (CA). Этот сценарий представляет собой самый высокий уровень риска. Приложение не будет выполнено, так как его источник может быть вредоносным.

Не удалось проверить сертификат. Приложение выполнено не будет.

Это диалоговое окно отображается при запуске приложения с сертификатом, который не может быть проверен центром сертификации (CA). Оно отображается, если на панели управления Java для уровня безопасности было задано значение ‘Очень высокий’ и сертификат не может быть проверен.

Невозможно установить соединение с центром сертификации

Это диалоговое окно отображается, если возникла ошибка сети и отсутствует доступ к центру сертификации (CA) для проверки сертификата. В данном случае запуск приложения обычно является безопасным, так как действия ограничены, но все равно может представлять собой умеренный уровень риска. Мы рекомендуем нажать кнопку ‘Отмена’, если вам не знаком издатель посещаемого сайта.

Безопасность в Java и не только

Что такое информационная безопасность? Это состояние защищенности информации, при котором обеспечиваются её конфиденциальность, доступность и целостность.

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

На мой взгляд, невозможно оценить безопасность отдельно взятой технологии или языка программирования без привязки к конкретному способу реализации, т. е. без конкретного готового программного продукта на языке, у которого есть детальное ТЗ с описанием архитектуры и функционала. Но и этого тоже будет мало, так как необходимо оценивать состояние защищенности готовой информационной системы со своей специфичной архитектурой, набором компонентов, бизнес-процессами, информацией и, наконец, людьми. Приведу пример с постройкой дома. У нас есть материалы (песок, цемент, щебень, кирпич и т. д.) и инструменты (ведро, лопата, шпатель и т. п.). Оценить исключительно по используемым материалам/инструментам качество и надежность готового дома мы не сможем: сколько он простоит, будут ли в нем трещины, будет ли в нем холодно или тихо. Нужно выбрать проект дома, технологии строительства и бригаду мастеров. И только после завершения строительства мы сможем провести измерения соответствия проекту, ГОСТу, СНиПам, проверить измерения по теплозащите, шуму, нагрузкам, провести анализ качества цемента и ответить на большинство вопросов. Но на главный вопрос «сколько он простоит?» у нас не будет точного ответа, так как мы не знаем всех условий эксплуатации дома и всех факторов, которые будут воздействовать на протяжении всего времени.

Как обеспечить безопасность в Java

Возьмем к примеру Java. Это объектно-ориентированный язык программирования; программы, написанные на Java, транслируются в байт-код Java, выполняемый виртуальной машиной Java (JVM) — программой, обрабатывающей байтовый код и передающей инструкции оборудованию как интерпретатор. Достоинством подобного способа выполнения программ является полная независимость байт-кода от операционной системы и оборудования, что позволяет выполнять Java-приложения на любом устройстве, для которого существует соответствующая виртуальная машина.

«Универсальный язык» звучит красиво, но самая распространённая проблема — это одновременно и обратная сторона медали — утечка памяти в JVM, что приводит к переполнению памяти и сбоям. В связи с этой проблемой не исключены уязвимости, ведь основной постулат надежности — чем проще, тем лучше. В данном же случае собирается такой сложный пирог из обеспечения совместимости большого количества платформ и ОС, что практически невозможно отслеживать и закрывать все найденные в них уязвимости и оперативно их устранять. У той же Microsoft уязвимости могут быть найдены и исправлены спустя и это если не брать в расчёт оставленные намеренно или по ошибке недекларированные возможности.

Из моей практики: когда программисты добавляют новый функционал, который связан с уже реализованным, или исправляют старый функционал, то в 15% случаях они ломают ранее работающий продукт. И если при этом не проводят полное тестирование — на выходе имеем продукт с новым функционалом, но с частично не работающим старым. Также существуют различия написания кода для разных платформ, версий ОС, ПО. В связи с этим можно себе представить, насколько тяжело поддерживать язык программирования Javа и JVM, не говоря уже про вопросы безопасности.

На текущий момент выпущен Java Development Kit 10, который предлагает нам штатные механизмы обеспечения безопасности, выпущенные еще для Java SE 8 и описанные в Security Documentation. В десятой версии не добавилось ничего нового.

Отмечу, что у Oracle существует ресурсный центр безопасности Java. В целом компания разделяет безопасность Java на четыре основных раздела:

А) разработчики должны:

— следить и использовать все последние обновления среды разработки и безопасности;

— использовать программы контроля корректности кода (например, Checker Framework);

— следить и использовать все рекомендации и изменения, связанные с хотфиксами и обновлениями версией среды разработки.

Б) системные администраторы должны:

— следить и использовать все последние обновления для Java и необходимые компоненты для работы продукта (в т. ч. ОС, библиотеки, фреймворки, и т. д.);

— использовать правила развертывания Java, описанные здесь и здесь;

— использовать надёжную метку времени.

В) конечные пользователи должны:

— всегда использовать последнюю оригинальную версию Java;

Г) профессионалам в области безопасности необходимо:

Читать еще:  Как отключить защиту protect 2020

— использовать расширенные инструменты управления и повышения безопасности (например, Advanced Management Console);

— контролировать своевременную установку всех обновлений безопасности;

Важно, чтобы все следовали и выполняли правила и требования безопасности. Достичь состояния безопасности на адекватном уровне можно только сообща и применяя все доступные меры (технические, организационные). Как показывает моя практика, в 60% организаций у ИТ- и ИБ-служб все нормально с безопасностью, а также с пользователями, которые используют корпоративные устройства и подключены к единому домену. А вот самыми неконтролируемыми в этой области являются разработчики, тимлиды, архитекторы.

Разработка ПО и вопросы безопасности

Если взять шире, то основные причины возникновения проблем безопасности в приложениях при разработке ПО следующие:

А) Отсутствие понимания терминологии безопасности в целом, не говоря о специфических знаниях и применяемых решениях.

Как правило, у разработчиков безопасность в лучшем случае ассоциируется со следующими вещами: управление и журналирование доступа и парольная защита, реже — защита соединения на уровне https (использование механизмов шифрования, которые доступны из коробки по умолчанию). Т. е. формально они будут использовать методы обеспечения безопасности, которые по факту останутся формальными, «для галочки», без учета требований и нюансов:

— Для паролей: обычно используются значения по умолчанию и не настраиваются дополнительно длина, стойкость, частота смены, неповторяемость, количество попыток. Довольно часто эти параметры нельзя донастроить, так как они не были включены в скоуп-задачу по разработке ПО, что приводит к необходимости дописывать код.

— По управлению и журналированию доступа: в лучшем случае разработчикам описали группы или роли пользователей и объекты доступа, которые должны быть доступны в ПО. В худшем — разработчики сами «поделили» разделы и объекты на необходимые пользователям и администраторам. В первом случае получаем систему, которую можно гибко настроить, но требуется потратить значительное количество времени на настройку и согласование прав. Во втором — формальную систему разграничения доступа. Кроме того, разработчикам надо понимать, какую именно информацию и в каком объёме необходимо журналировать. Однако зачастую им эту информацию не предоставляют, что приводит к недостаточной детализации журналов для разбора инцидентов или понимания того, что происходит в ПО. Или же к избыточному хранению логов и большого объёма информации, что накладывает существенные ограничения на возможность хранения информации в течение необходимого периода времени (например, один-три года) или возникает необходимость закупки дополнительных хранилищ информации. При избыточной записи информации возникают дополнительные проблемы со скоростью анализа и разбора инцидентов и быстротой поиска нужной информации. Избыточность также может потребовать дополнительного финансирования на расширение штата, закупку SIEM-систем с настройкой уникальных правил обработки информации или вести к рискам, связанным с неактуальностью информации. При этом тратится слишком много времени на анализ и обработку информации.

— Защита каналов связи — не менее существенный момент, особенно для платежных и банковских систем, где помимо разглашения персональных и личных данных возможны финансовые потери. Чаще всего бывает, что о защите каналов и среды передачи информации не думают, а если и думают, то используют настройки «по умолчанию», например, TLS/SSL. Но там ведь тоже есть свои особенности по выбору версии протокола (TLS 1.1, 1.2, 1.3 или SSL v1-3), алгоритма шифрования (RC4, IDEA, Triple DES, SEED, Camellia или AES), длины ключа. Иногда выбирается, например, правильный протокол TLS 1.2, с шифрованием по AES, длиной ключа 256 бит, но забывается про возможность выбора адреса по порту 443 для HTTPS и или порт для HTTP, вместо блокировки порта, в результате чего появляется возможность получать доступ по незащищенному каналу. Или, например, поднимают инфраструктуру на виртуальных машинах и совсем не думают о необходимости закрыть сетевой доступ между виртуальными машинами.

Б) Вторая проблема связана с бизнесом, так как он вкладывает деньги в конкретный специальный функционал, который не учитывает блоки безопасности.

К сожалению, бизнес не всегда понимает, зачем ему тратить ресурсы на блоки безопасности, если от них нет функциональной пользы, денег больше продукт не принесёт, а есть только вероятные риски, которые могут и не сработать. Бизнес чаще понимает необходимость вкладываться в безопасность, когда инцидент ИБ уже произошел.

К сожалению, в этом виноват не только бизнес, но и его окружение, которое:

— также не понимает в безопасности;

— пожалело бюджет на специалистов по ИБ (не нанимаются вообще или нанимаются узкоспециализированные специалисты, или нанимается один человек, отвечающий за все);

— не смогло аргументировано донести необходимость в безопасности и правильно обосновать текущие риски (репутационные, финансовые, временны́е).

В) Проблема с коммуникацией в компании или отсутствие оной.

Это тот случай, когда бизнес и его окружение понимают необходимость и важность ИБ. Они выделили бюджеты, наняли соответствующих специалистов, но возникают сложности в коммуникации между бизнес-подразделениями и службами ИБ/ИТ, разработчиками.

Г) Недостаточная осведомленность простых пользователей компании в вопросах ИБ.

Предположим, что есть все необходимые подразделения, специалисты, технические и организационные меры. Но пользователи упираются и не хотят работать по правилам. Очень частая ситуация, и решать ее также необходимо комплексно, так как люди не понимают, зачем им лишняя работа по соблюдению вопросов ИБ (проверять файлы антивирусом, запоминать сложные пароли, знать и соблюдать политики и бизнес-процессы и т. д.). Нужно периодически устраивать мастер-классы, рассказывать на бытовом уровне, что такое ИБ, какие есть проблемы и решения, доводить глобальные цели и задачи ИБ, их и влияние на бизнес, мотивировать.

Д) Нехватка архитекторов ИБ — не всегда в разработке ПО участвуют специалисты по ИБ, и программисты сами думают о безопасности архитектуры и применении написанных и готовых шаблонов безопасности (Security patterns).

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

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

Автор статьи — эксперт-аналитик по ИБ.

Подписывание Java апплета и некоторые тонкости java security

Постановка задачи:

В качестве WYSIWYG XML редактора в нашем приложении используется java applet Oxygen Author Component. При загрузке этого апплета на клиенте Java не должна выкидывать никаких пугающих варнингов о небезопасном коде, а спокойно и тихо загружать себе апплет, не напрягая пользователя и не заставляя брать на себя тяжелую ответственность. У нас ведь солидное приложение как никак.

Пролог

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

Как работает апплет на пальцах

Браузер при обнаружении тэга в HTML странице передает управление загрузке апплета соответствующему java-плагину, который, в свою очередь передает управление JRE установленному на клиентской машине. Есть два способа загрузки апплета (под апплетом понимается некое java приложение, представляющее из себя набор jar-ок, где есть main jar с Main class реализующим класс Applet):

  • в тэге Applet перечесляются jar файлы апплета, которые нужно загрузить и откуда их грузить (codebase)
  • с помощью jnlp файла, в котором указывается эта информация, а также много других опций и аргументов

В нашем случае мы используем jnlp. Преимуществом jnlp подхода помимо прочих является то, что при изменении каких-то параметров загрузки апплета (например, codebase) не нужно менять HTML или JavaScript код, ответственный за загрузку апплета. Достаточно просто поменять jnlp. Замена codebase (codebase — это url адрес указывающий на то где лежат jar-ки апплета) является даволно неприятной проблемой, так как нужно указывать абсолютный URL, а это значит, что в зависимости от того на каком сервере запущен апплет, такой и должен быть codebase. На локальной машине это один адрес, на QA стенде другой, на продакшене третий, поэтому при сборке приложения нужно явно указывать Context Path, то есть абсолютный адрес web-приложения, на котором оно будет работать.
Использование jnlp файла решает эту проблему тем, что есть специальный сервлет, суть работы которого — динамически, на лету, менять codebase на текущий при загрузке jnlp файла клиентской явой.

Читать еще:  Защита в режиме реального времени отключить
Поехали

Итак, загрузка апплета начинается с загрузки jnlp файла, в котором кроме списка нужных jar файлов и их codebase указываются также аргументы java (это очень важный момент, ниже узнаете почему), с которыми эта java должна стартовать на клиентской машине. Java начинает загружать jar-ки и проверять их на безопасность. Тут вступает в силу java security механизм, который начинает проверку загружаемой жарки, прежде чем из нее будут загружены классы. Этот механизм давольно сложный и многогранный: настройка общего уровня безопасности при загрузке апплетов и java security policy на клиенте (permission grants), параметры безопасности в манифестах самих jar, проверка верификация цифровой подписи jar и тд. Не хочу углублятся и буду затрагивать только те аспекты, которые важны в описываемой задаче.

Для справки: подписанние апплета подразумевает подписание jar-фалов. Подписание jar — это выполнение java-команды signjar, в результате которой в jar-ке появляется информация о ключе, которым подписывали в зашифрованном виде, а также каждому ресурсу упакованному jar ставится в соответствие нейкий зашифрованный этим ключом код, содержащи в себе информацию о контенте данного ресурса. Таким, образом, если вы попытаетесь изменить подписанную жарку, подкинув например туда какой-нибудь класс, или изменив старый, то такая жарка станет невалидной и она не пройдет проверку на security и не будет загружена.

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

или загружен с одним красивым и непугающим сообщением, которое можно не повторять в дальнейшем нажав соответствующую галочку. Вот тут мы подобрались к, собственно, задаче. На момент решения описываемой задачи наш Oxygen апплет был самоподписанным. То есть подпись была, но фэйковая — ключи были сгенерены нами же при помочи утилиты keytool.
Естественно, при загрузке такого апплета, java вбрасывала фекалии в вентелятор и ругалась матом, хоть и загружала апплет в конечном счете. Но нам нужно было от этих сообщения избавится, поэтому нам нужен был сертификат от доверенного центра сертификации (Trusted Certifictae Authority).

Итак нам нужен сертификат от доверенного центра. Как его получить? Легко, но удовольствие не дешевое. Сертификат сроком на год будет стоить порядка 500 американских. Мы воспользовались услугами центра www.verisign.com. Нужно создать keystore со своим альясом и другой информацией о паблишере (при помощи утилиты keytool) и сформировать специальный request (и конечно, заплатить). В ответ CA присылает ключи. Наш прислал аж 3 штуки: Code Signing certificate, intermediate CA certificate и certificate in pkcs7 format. Для JKS типа сертификата нам понадобятся intermediate и Code Signing certificate. Сначала в созданый ранее keystore добавляется intermediate certificate, а затем основной Code Signing certificate. Полученный keystore и будет использован для подписания jar-ок.

Если ваши жарки ранее были подписаны (а в моем случае были подписаны, точнее самоподписаны), то прежде чем подписывать их заново, нужно сначала удалить старые подписи. Если вы это не сделаете, то при загрузке апплета java захлебнется на первой же жарке и пошлет вас куда подальше. Удалить подпись можно, например, руками — удалить файлы .RSA (или .DSA) и .SF из папки META-INF, а также поудалять все Digest подписи ресурсов из файла манифеста.
Чуть не забыл: перед подписывании jar в манифест нужно добавить security attributes:

Начиная с 51 апдейта 7 явы все jar-ки не содержащие security attributes автоматически будут блокироваться.
А вот и ант скриптик для этого:

Важно: вам понадобится antcontrib для возможности использование foreach в данном скрипте.

Итак, чистим жарки, добавляем в манифесты нужные атрибуты, подписываем, запускаем и… Опять видим варнинг!

Что опять? Оказывается, что подписывать нужно не только жарки, но и jnlp файл. А как его подписать? А так. Кому лень читать: jnlp файл кидается в вашу main jar в дирикторию JNLP-INF и название файла должно быть именно такое: APPLICATION.JNLP. Не вопрос, добавляем в наш ant скрипт, билдящий main jar и подписывающий jar-ки, незамысловатый код который копирует наш исходный jnlp в подписанный jnlp.

Отцы сразу разберутся, но я все же поясню, на всякий случай, что происходит в этом антовском таргете. В первой части все ясно — создаем дирикторию classes и компилируем туда код нашего апплета. Обратите внимание, что при компиляции в класспас добавляется папочка lib, в которой лежит куча jar-ок, нужных апплету и их всех нужно подписывать. Далее там же создается папка JNLP-INF и туда копируется наш исходный
author-component-dita.jnlp.
Далее мы упаковываем все это в jar (это и есть наш main jar) и кидаем его в ту же папку lib рядом с остальными jar-ками.
Получается что сейчас у нас есть 2 jnlp файла: исходный author-component-dita.jnlp и APPLICATION.JNLP упакованный в jar. Это меня немного смущает, ну ладно. Запускаю апплет — error!

Что на этот раз? Оказывается, что эти jnlp файлы не совпадают, а должны. Исходный jnlp используется для загрузки апплета, а упакованный — для проверки подписи и они не должны отличатся. Но почему они отличаются, они же копии? И тут вспоминаем наш чудный сервлет (JnlpDownloadServlet ), который используется для облегчения деплоя вашего веб приложения — я уже упоминал об этом выше. С помощью него можно не писать в jnlp конкретный codebase (например, localhost:8888/oxygen-editor/), а использовать переменную $$CODEBASE , а сервлет на рантайме сам изменяет jnlp подставляя в нее нужные значения переменных. Вот почему загружаемый jnlp не совпадает с подписанным. Что же делать? Деплоить для разных адресов сервера разные варки? Это не наш путь. Все просто: нужно использовать APPLICATION-TEMPLATE.JNLP вместо APPLICATION.JNLP. Использование шаблона APPLICATION-TEMPLATE.JNLP отличается тем, что он может отличастся от исходного jnlp, если вместо конкретных значений параметров указывать «*», например, codebase=»*». Видоизменим наш антовский build.xml:

Итак, неужели это все и я наконец увижу при загрузке апплета долгожданное user-friendly сообщение с синим щитом о том, что апплет доверенный, надежный и не вызывает подозрений? Не веря в свое счастье, дрожащими руками запускаю приложание, загружаю апплет и…

Ура! Свершилось! Я увидел наконец это сообщение с синим щитом! И разбрызгивая слюни радости я нажимаю галочку «Всегда доверять этому паблишеру», оно закрывается, начинает грузится апплет и… тут появляется это:

Что за . Стремительно седея, начинаю лихорадочно втыкать в код — что же там такого несекьюрного? В общем, я убил еще 2 дня, чтобы найти вот эту строчку в jnlp файле:

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

Вот полный список запрещенных аргументов:

Спасибо за внимание, надеюсь эта статья будет полезной.

Ссылка на основную публикацию
Adblock
detector