Есть ли жизнь после отказа популярных браузеров от поддержки архитектуры NPAPI
Задачи строгой двухфакторной аутентификации и усиленной электронной подписи традиционно решаются с использованием средств криптографической защиты информации, выполненных в виде токенов. Для усиленной защиты от киберпреступников при работе пользователя в потенциально уязвимой среде дополнительно используются токены и Trust Screen-устройства. 
В связи с выявленными уязвимостями и ограничениями архитектуры NPAPI разработчики браузеров стали отказываться от поддержки этой архитектуры в пользу собственных решений. Так, Google Chrome предложил использовать технологию Native Messaging, а Mozillа Firefox технологию WebExtensions. Яндекс.Браузер также анонсировал отказ от NPAPI. Microsoft анонсировал создание собственной платформы разработки расширений для браузера Microsoft Edge. Apple же, несмотря на все уязвимости NPAPI, пока не предложил никаких альтернативных технологий расширения для браузера Safari, оставив пользователей Mac OS X потенциально уязвимыми.
В итоге перед разработчиками веб-приложений возникла необходимость адаптировать приложения под «зоопарк» различных технологий, используемых различными браузерами. Такая ситуация усложнила задачу мультибраузерной поддержки токенов для реализации функций безопасности, увеличила затраты разработчиков на встраивание и поддержку таких устройств, создала большое число потенциальных точек отказа и стала причиной возникновения проблем с обратной совместимостью. В частности, архитектура NPAPI поддерживает как синхронные, так и асинхронные методы для работы с токенами. Технология Native Messaging — только асинхронные.
Встал вопрос –, а существует ли альтернативный подход, который позволил бы избавиться от «зоопарка» различных технологий, обеспечил бы поддержку токенов во всех популярных браузерах и позволил бы выпустить решения, максимально совместимые с предыдущими, которые использовали NPAPI. Данный момент был очень важен, так как многие технологические партнёры «Аладдин Р.Д.» использовали в своих веб-приложениях решение JC-WebClient 2.4, работающее на основе NPAPI-плагинов, и поэтому для нас было важно максимально облегчить партнёрам процесс миграции на новую версию JC-WebClient. В идеале хотелось бы сразу поддержать ещё и браузер Microsoft Edge в Microsoft Windows 10 так, чтобы получилась примерно такая картина:
В качестве альтернативной технологии, единой для всех браузеров, рассмотрели технологию локального прокси-сервера.
Такая архитектура позволяет обеспечить поддержку токенов для всех популярных браузеров, однако имеет определённые недостатки. В частности:
После анализа вариантов решений и выполнения НИРов по данной теме решили разработать приложение на основе технологии локального веб-сервера. Основное отличие такой архитектуры от технологии локального прокси-сервера заключается в том, что локальный веб-сервер не вмешивается в процесс передачи прикладного трафика от браузера до удалённого сервера. Браузер обращается к локальному веб-серверу только для доступа к функциям токена и/или Trust Screen-устройства. Пользователь же при работе с электронным сервисом по-прежнему видит в адресной строке своего браузера корректный URL одной из страниц веб-приложения.
Разработанный прототип для платформы Microsoft Windows доказал, что такая технология работает. Однако первая версия прототипа имела существенное ограничение — обращение к локальному веб-серверу шло только по HTТP, что не позволяло работать веб-приложению по HTTPS с удалённым веб-сервером из-за ограничений браузеров. Мы разработали вторую версию прототипа, реализовав в локальном веб-сервере поддержку TLS для возможности установления браузером соединения как с локальным, так и с удалённым веб-сервером по HTTPS.
Вторая версия прототипа успешно заработала во всех популярных браузерах, включая Microsoft Edge, для которого Microsoft до сих пор не предоставил возможности разработки расширений. На основе второй версии прототипа мы разработали новую версию решения JC-WebClient 3.0, обеспечив поддержку всех популярных браузеров.
Основные компоненты JC-WebClient 3.0:
Выбранная технология локального веб-сервера позволила обеспечить в JC-WebClient 3.0 поддержку как синхронных, так и асинхронных методов для работы с токенами. Ещё одним плюсом явилось то, что разработчики веб-сервисов, работавшие ранее через NPAPI, не потеряли возможность сохранять сессию работы с токеном при переходе со страницы на страницу своего приложения в рамках одной вкладки браузера. Эти два обстоятельства позволили максимально облегчить процесс миграции с версии JC-WebClient 2.4 на версию 3.0 для технологических партнёров. Для перехода на новую версию достаточно добавить несколько строк одинакового кода на каждой веб-странице, работающей с токеном, при этом не требуется переделывать логику графического интерфейса.
Разделение контекстов между различными вкладками браузера позволило обеспечить защиту от вредоносных скриптов, пытающихся получить доступ к токену из вкладки, отличной от той, в которой работает веб-приложение.
В типовом сценарии дистрибутив JC-WebClient 3.0 скачивается со страницы веб-сервиса и устанавливается на компьютер пользователя один раз, и, затем, локальный веб-сервер из комплекта JC-WebClient 3.0 автоматически запускается сразу после установки. Работа локального веб-сервера происходит исключительно в фоновом режиме. Он потребляет минимум ресурсов и не имеет никаких элементов управления. Так же легко осуществляется и его обновление при выходе новой версии.
В качестве средства строгой двухфакторной аутентификации и электронной подписи JC-WebClient 3.0 использует USB-токены/смарт-карты JaCarta и eToken с аппаратно реализованными российскими криптоалгоритмами. В их числе — JaCarta ГОСТ, JaCarta PKI/ГОСТ, eToken ГОСТ. В качестве доверенного Trust Screen-устройства — Антифрод-терминал, собственный продукт компании «Аладдин Р.Д.».
Версия JC-WebClient 3.0 поддерживает платформу Microsoft Windows, начиная от Microsoft Windows XP до Microsoft Windows 10. В ближайшее время запланирован выпуск версии 3.1, которая будет поддерживать Mac OS X и Linux. Следите за нашими новостями.
Браузеры по умолчанию не предоставляют коду веб-страниц доступ к токенам и Trust Screen-устройствам. Для реализации такого доступа требуется разработка специальных расширений (плагинов) для браузеров или использование иных технологий. Также возможно создание Java-апплетов и локальных прокси-серверов.
Расширения для браузеров, как правило, разрабатывались с помощью архитектуры NPAPI (Netscape Plugin Application Programming Interface). Java-апплеты также работали через NPAPI. Для Microsoft Internet Explorer, как правило, разрабатывался ActiveX-компонент.
Конец эпохи NPAPI
В связи с выявленными уязвимостями и ограничениями архитектуры NPAPI разработчики браузеров стали отказываться от поддержки этой архитектуры в пользу собственных решений. Так, Google Chrome предложил использовать технологию Native Messaging, а Mozillа Firefox технологию WebExtensions. Яндекс.Браузер также анонсировал отказ от NPAPI. Microsoft анонсировал создание собственной платформы разработки расширений для браузера Microsoft Edge. Apple же, несмотря на все уязвимости NPAPI, пока не предложил никаких альтернативных технологий расширения для браузера Safari, оставив пользователей Mac OS X потенциально уязвимыми.
В итоге перед разработчиками веб-приложений возникла необходимость адаптировать приложения под «зоопарк» различных технологий, используемых различными браузерами. Такая ситуация усложнила задачу мультибраузерной поддержки токенов для реализации функций безопасности, увеличила затраты разработчиков на встраивание и поддержку таких устройств, создала большое число потенциальных точек отказа и стала причиной возникновения проблем с обратной совместимостью. В частности, архитектура NPAPI поддерживает как синхронные, так и асинхронные методы для работы с токенами. Технология Native Messaging — только асинхронные.
Встал вопрос –, а существует ли альтернативный подход, который позволил бы избавиться от «зоопарка» различных технологий, обеспечил бы поддержку токенов во всех популярных браузерах и позволил бы выпустить решения, максимально совместимые с предыдущими, которые использовали NPAPI. Данный момент был очень важен, так как многие технологические партнёры «Аладдин Р.Д.» использовали в своих веб-приложениях решение JC-WebClient 2.4, работающее на основе NPAPI-плагинов, и поэтому для нас было важно максимально облегчить партнёрам процесс миграции на новую версию JC-WebClient. В идеале хотелось бы сразу поддержать ещё и браузер Microsoft Edge в Microsoft Windows 10 так, чтобы получилась примерно такая картина:
Локальный прокси-сервер
В качестве альтернативной технологии, единой для всех браузеров, рассмотрели технологию локального прокси-сервера.
Такая архитектура позволяет обеспечить поддержку токенов для всех популярных браузеров, однако имеет определённые недостатки. В частности:
- при работе через локальный прокси-сервер пользователь видит в адресной строке браузера не реальный URL веб-страницы на удалённом сервере, а что-то наподобие 127.0.0.1:12345, что делает работу пользователя с таким сервисом не совсем удобной;
- весь прикладной трафик между браузером и удалённым сервером перенаправляется на локальный прокси-сервер, что делает локальный прокси-сервер узким местом всей системы;
- работа с каждым отдельным веб-приложением требует отдельной конфигурации локального прокси-сервера на клиентской стороне.
В связи с перечисленными недостатками такая архитектура была признана нами не самой оптимальной. Мы продолжили исследования дальше.
Локальный веб-сервер
После анализа вариантов решений и выполнения НИРов по данной теме решили разработать приложение на основе технологии локального веб-сервера. Основное отличие такой архитектуры от технологии локального прокси-сервера заключается в том, что локальный веб-сервер не вмешивается в процесс передачи прикладного трафика от браузера до удалённого сервера. Браузер обращается к локальному веб-серверу только для доступа к функциям токена и/или Trust Screen-устройства. Пользователь же при работе с электронным сервисом по-прежнему видит в адресной строке своего браузера корректный URL одной из страниц веб-приложения.
Разработанный прототип для платформы Microsoft Windows доказал, что такая технология работает. Однако первая версия прототипа имела существенное ограничение — обращение к локальному веб-серверу шло только по HTТP, что не позволяло работать веб-приложению по HTTPS с удалённым веб-сервером из-за ограничений браузеров. Мы разработали вторую версию прототипа, реализовав в локальном веб-сервере поддержку TLS для возможности установления браузером соединения как с локальным, так и с удалённым веб-сервером по HTTPS.
Вторая версия прототипа успешно заработала во всех популярных браузерах, включая Microsoft Edge, для которого Microsoft до сих пор не предоставил возможности разработки расширений. На основе второй версии прототипа мы разработали новую версию решения JC-WebClient 3.0, обеспечив поддержку всех популярных браузеров.
Основные компоненты JC-WebClient 3.0:
- Локальный веб-сервер
- Обеспечивает взаимодействие между веб-страницей и токеном/Trust Screen-устройством по протоколу HTTPS
- Обеспечивает разделение PC/SC контекстов для различных вкладок браузера
- Обеспечивает взаимодействие между веб-страницей и токеном/Trust Screen-устройством по протоколу HTTPS
- Клиентский скрипт JCWebClient.js
- Предоставляет веб-страницам JavaScript API для работы с методами JC-WebClient
- Загружается на веб-страницу с локального веб-сервера
- При вызове из контекста страницы веб-приложения методов объектов, реализованных в файле JCWebClient.js, управление передаётся на локальный веб-сервер и, далее, к токену
- Предоставляет веб-страницам JavaScript API для работы с методами JC-WebClient
- Сервис мониторинга, выполненный в виде службы ОС
- Запускает локальный веб-сервер при загрузке ОС
- Контролирует целостность локального веб-сервера
- Перезапускает локальный веб-сервер в случае нештатных ситуаций/сбоев в ОС
- Запускает локальный веб-сервер при загрузке ОС
Преимущества
Выбранная технология локального веб-сервера позволила обеспечить в JC-WebClient 3.0 поддержку как синхронных, так и асинхронных методов для работы с токенами. Ещё одним плюсом явилось то, что разработчики веб-сервисов, работавшие ранее через NPAPI, не потеряли возможность сохранять сессию работы с токеном при переходе со страницы на страницу своего приложения в рамках одной вкладки браузера. Эти два обстоятельства позволили максимально облегчить процесс миграции с версии JC-WebClient 2.4 на версию 3.0 для технологических партнёров. Для перехода на новую версию достаточно добавить несколько строк одинакового кода на каждой веб-странице, работающей с токеном, при этом не требуется переделывать логику графического интерфейса.
Разделение контекстов между различными вкладками браузера позволило обеспечить защиту от вредоносных скриптов, пытающихся получить доступ к токену из вкладки, отличной от той, в которой работает веб-приложение.
Простота использования
В типовом сценарии дистрибутив JC-WebClient 3.0 скачивается со страницы веб-сервиса и устанавливается на компьютер пользователя один раз, и, затем, локальный веб-сервер из комплекта JC-WebClient 3.0 автоматически запускается сразу после установки. Работа локального веб-сервера происходит исключительно в фоновом режиме. Он потребляет минимум ресурсов и не имеет никаких элементов управления. Так же легко осуществляется и его обновление при выходе новой версии.
Поддерживаемые аппаратные устройства
В качестве средства строгой двухфакторной аутентификации и электронной подписи JC-WebClient 3.0 использует USB-токены/смарт-карты JaCarta и eToken с аппаратно реализованными российскими криптоалгоритмами. В их числе — JaCarta ГОСТ, JaCarta PKI/ГОСТ, eToken ГОСТ. В качестве доверенного Trust Screen-устройства — Антифрод-терминал, собственный продукт компании «Аладдин Р.Д.».
Поддерживаемые операционные системы
Версия JC-WebClient 3.0 поддерживает платформу Microsoft Windows, начиная от Microsoft Windows XP до Microsoft Windows 10. В ближайшее время запланирован выпуск версии 3.1, которая будет поддерживать Mac OS X и Linux. Следите за нашими новостями.
Комментарии (4)
datacompboy
2 августа 2016 в 13:10
+1↑
↓
А что на счет HTTPS cертификата? Вы его для 127.0.0.1 поставляете вместе с ключом?
Evengard
2 августа 2016 в 13:47
+1↑
↓
А в чём проблема сделать домен localhost.mydomainname.com с A записью = 127.0.0.1, и получить сертификат на этот самый localhost.mydomainname.com?
Akuma
2 августа 2016 в 14:37
0↑
↓
А так можно?Всмысле, не разу не пробовал делать A запись на 127.0.0.1
-
datacompboy
2 августа 2016 в 14:47
0↑
↓
Да, можно. И таких вагон уже в интернете, например http://readme.localtest.me/ — даже с сертификатом.вопрос в другом — что мешает вирусу запустить сервис на другом локальном порту, и продолжать выглядеть как белый и пушистый, проксируя, например, запросы реальному локалхостовому?
Порта в SSL сертификате нет, браузеры его не проверяют…
