Статті та публікації

1. Кінець епохи NPAPI
2. Локальний проксі-сервер
3. Локальний веб-сервер
4. переваги
5. Простота використання
6. Підтримувані апаратні пристрої
7. Операційні системи

Інтернет-портал habrahabr.ru, серпень, 2016
Стаття Андрія Петрова, керівника департаменту розробки і тестування, і Миколи Афанасьєва, менеджера з розвитку продуктів компанії "Аладдін Р.Д."

Завдання суворої двофакторної аутентифікації і посиленою електронного підпису традиційно вирішуються з використанням засобів криптографічного захисту інформації, виконаних у вигляді токенов. Для посиленого захисту від кіберзлочинців при роботі користувача в потенційно вразливою середовищі додатково використовуються маркери і Trust Screen-пристрої.

Браузери за замовчуванням не пропонують коду веб-сторінок доступ до токені і 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 веб-сторінки на віддаленому сервері, а щось на зразок http://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 контекстів для різних вкладок браузера
• Клієнтський скрипт JCWebClient.js
  • Надає веб-сторінок JavaScript API для роботи з методами JC-WebClient
  • Завантажується на веб-сторінку з локального веб-сервера
  • Коли Ви телефонуєте з контексту сторінки веб-додатки методів об'єктів, реалізованих у файлі JCWebClient.js, управління передається на локальний веб-сервер і, далі, до токені
• Сервіс моніторингу, виконаний у вигляді служби ОС
  • Запускає локальний веб-сервер при завантаженні ОС
  • Контролює цілісність локального веб-сервера
  • Перезапускає локальний веб-сервер в разі нештатних ситуацій / збоїв в ОС

переваги

Обрана технологія локального веб-сервера дозволила забезпечити в 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. Слідкуйте за нашими новинами.