Браузеры по умолчанию не предоставляют коду веб-страниц доступ к токенам и 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. Следите за нашими новостями.
Комментарии (66)
crackpot
02.08.2016 16:36-1А не означает ли это, что скомпрометированный компьютер в корпоративной сети потенциально будет иметь доступ к локальному веб-серверу на других компьютерах сети? Есть ли в локальном веб-сервере проверки на то, откуда пришел запрос?
Или ответственность за это перекладывается на админов?mayorovp
02.08.2016 17:08+2Такая проверка есть на уровне ОС. Если слушать адрес 127.0.0.1 — то с других компьютеров доступа не будет. И если авторы сего решения — не полные идиоты, то они так и сделали.
xapienz
02.08.2016 17:07+2У корейских интернет-банков похожая система используется. На компьютер ставится софтина, несущая с собой локальный приватный сертификат и работающая как локальный веб/прокси-сервер для определённого набора реквестов.
При открытии банка html-страничка приходит в браузере напрямую через обычный SSL, а вот запросы на операции идут через запущенное приложение, которое занимается криптованным общением с сервером.
В подробности не вникал, но выглядит очень похоже :)
amarao
02.08.2016 18:18Интересно, а нативного стандартизированного доступа браузеры не предоставляют? Я видел (как минимум в винде) штатную поддержку смарт-карт.
Во, я погуглил, нашёл ссылку: https://github.com/ubinity/webpcsc-firebreath
(весь топик: http://stackoverflow.com/questions/15807038/architectures-to-access-smart-card-from-a-generic-browser-or-how-to-bridge-the)pavd2000
02.08.2016 18:38firebreath (по ссылке) — это фреймворк для написания NPAPI плагинов, которые перестают поддерживаться браузерами
Tatikoma
02.08.2016 18:38Видел аналогичное решение при запуске Lineage II с сайта наших прекрасных дистрибьюторов в РФ.
Т.е. натурально, — заходим на сайт, нажимаем «играть» — запускается игра на компьютере. Там только с тем лишь отличием, что использовался для этого WebSocket (что выглядит более логичным, нежели ajax). Разумеется там тоже был TLS.
Самое интересное там было, что подключиться к серверу можно было только с определенного сайта. Т.е. открываю консоль разработчика и ввожу команду открытия соединения — если открыт «правильный» сайт — подключается, неправильный — не подключается. Я подумал что это работает через SNI и не стал разбираться.
GamePad64
03.08.2016 15:54Браузер при подключении к WebSocket-серверу передаёт заголовок «Origin» c доменом. WebSocket сервер просто отклоняет все соединения, у которых поле Origin неправильное.
Andropolon
02.08.2016 21:20А что насчет брандмауэра Windows и всяких фаерволов?
Они же по умолчанию могут блокировать такие подключения.
Будете писать инструкции под зоопарк антивирусов?
Alexufo
02.08.2016 23:36Не наю, локалхост на локалхост ниче не блокируется, вроде как) Китайщина 360 total secutiry, NOD Security ничего не замечают.
Andropolon
04.08.2016 20:181) не понял, почему localhost на localhost? Я где буду работать с вашим WebClient?
Наверняка ведь на сайте https://www.my-site.ru?
И тут возникает ряд проблем:
— с https на http некоторые браузеры (например, IE) не дают сходу заходить (а если и дают — то теряют referrer)
— некоторые браузеры (например, IE и Opera) могут блокировать localhost, т.к. он не в зоне Интернета, а Интранета
— фаерволы типа Касперского и DrWeb тоже будут блокировать (видимо, вы так настроили свой ESET NOD32)
— если же купить свой https сертификат на localhost, то еще одна проблема — антивирусы по умолчанию сканируют https, подменяя сертификат — и я не уверен, что тут они корректно подменят
2) учитывая первый пункт, как вы отличаете хороших от плохих?
Например, я сделаю свой http://www.cool-jc-web-site.ru, на котором буду у всех посетителей пытаться дергать WebClient и воровать все по-максимуму
Как вы понимаете, кто к вам пришел? Если по Referrer, то перечитайте 1 пункт + Referrer несложно подделать в Ajax-запросахAlexufo
04.08.2016 23:42Наверняка ведь на сайте https://www.my-site.ru?
не важно какой сайт, если вы предполагаете работу с локальным сервером у пользователя все аякс запросы с сайта https://www.my-site.ru будут направлены локалхост.
— с https на http некоторые браузеры (например, IE) не дают сходу заходить (а если и дают — то теряют referrer)
Да, с https нельзя делать запрос на http из за смешанного содержимого. Решается сертификатами самоподписными.
— фаерволы типа Касперского и DrWeb тоже будут блокировать (видимо, вы так настроили свой ESET NOD32)
может мы про разное говорим.
если же купить свой https сертификат на localhost, то еще одна проблема — антивирусы по умолчанию сканируют https, подменяя сертификат — и я не уверен, что тут они корректно подменят
купить на локалхост невозможно. Только самоподписный. То что они там подменяют, меня не интересует потому что либо они ломают все https сайты вместе с локальным сервером, либо ничего не ломают.
Например, я сделаю свой http://www.cool-jc-web-site.ru, на котором буду у всех посетителей пытаться дергать WebClient и воровать все по-максимуму
Проверять сертификат на сервере при рукопожатии?Andropolon
05.08.2016 07:51-1Да, с https нельзя делать запрос на http из за смешанного содержимого. Решается сертификатами самоподписными.
«Решается»? Браузер же будет дико ругаться на такой сертификат… И если в IE проблему еще можно обойти через msxml2.ServerXMLHTTP ( у него есть метод setOption(), позволяющий игнорировать разные ошибки сертификата), то в других браузерах — нет.
А если делать простой http:// — то это откровенная дыра — существует куча вирусов-сниферов на основе HTTP-Analyzer и Fiddler (если кто-то не верит — могу показать ответ Касперского на вопрос «почему вы считаете HTTP-Analyzer „not-a-virus“ и что это такое?)
купить на локалхост невозможно. Только самоподписный
Можно, и выше было описано, как именно — сделать https://localhost.my-site.ru, только вот нужно его в hosts прописать, а есть такие антивирусы — DrWeb и Avira — которые любят блочить и/или возвращать старый hosts
То что они там подменяют, меня не интересует потому что либо они ломают все https сайты вместе с локальным сервером, либо ничего не ломают.
Нет, опять не согласен. Мы (с вами) живем в стране на букву Р (если я не ошибся), в которой широко распространен в узких кругах алгоритм ГОСТ — и вот он точно не будет работать, т.к. антивирусы не могут поддержать ГОСТ опять же из-за законов (и не могут его не сканировать, т.к. криворукие).
Это я только один пример бага антивирусов привел. Нет гарантии, что это будет работать.
Получается, что ваше решение протестировано только на http://?
И это в эру, когда крупные компании начинают переходить на HTTP/2?Alexufo
05.08.2016 11:51Браузер же будет дико ругаться на такой сертификат…
Сделайте сертификат удостоверяющего центра, положите его в хранилище корневых центров, подпишите им самозаверенный и ничего нигде не ругается и не должно.
Можно, и выше было описано, как именно — сделать https://localhost.my-site.ru,
Домен https://localhost.my-site.ru не имеет к домену localhost никого отношения. Купить сертификат на localhost нельзя, раньше было можно. С самозаверенными сертификатами нет никаких проблем в работе. Игры с hosts не нужны.
антивирусы не могут поддержать ГОСТ опять же из-за законов
Это проблема вашего антивируса, что он вам не показывает сайты каким то там гостовым сертификатом потому что он не может подменить сертификат.
Получается, что ваше решение протестировано только на http://?
Что значит протестировано?) Вы используете рабочее решение никем не запрещаемое. И какая разница какой протокол, делайте на каком угодно.Andropolon
06.08.2016 10:02Сделайте сертификат удостоверяющего центра, положите его в хранилище корневых центров, подпишите им самозаверенный и ничего нигде не ругается и не должно.
Получается примерно так:
— сделать самоподписанный корневой
— сделать для него инсталлятор (абоненты ведь не руками будут это ставить, на дворе 21 век)
— сделать инструкцию для доменных админов, которые запрещают абы как менять хранилище корневых
— разгребать тонну звонков и писем по этому поводу
Чем это проще, чем плагины для браузеров?
Домен https://localhost.my-site.ru не имеет к домену localhost никого отношения
Может иметь, и это было описано в комментариях выше.
Но почему-то вы упускаете из виду очевидное решение этой проблемы:
— на DNS-сервере для домена my-site.ru делаем запись localhost.my-site.ru = 127.0.0.1
— тогда и файл hosts менять не придется
Это проблема вашего антивируса, что он вам не показывает сайты каким то там гостовым сертификатом потому что он не может подменить сертификат.
Это проблема Касперского, DrWeb, ESET NOD32, Avast, Outpost, ZoneAlarm. Короче, где-то 40% рынка.
Что значит протестировано?)
Коммерческое решение должно быть проверено на разных ОС и браузерах, с разными (популярными) антивирусами и программами, а не только с ESET NOD32.
Пока что вся статья выглядит скорее как гипотеза, работающая с ограниченном числе сценариев.
И какая разница какой протокол, делайте на каком угодно
Разница, наверное, в том, что вы — производитель защищенных носителей с конфиденциальной информацией на борту. Странно слышать от вас такие слова. Телохранитель должен проважать босса до квартиры, а не до подъезда, ибо даже в подъезде (localhost) может всякое случиться (кейлоггеры, снифферы и т.д.)Alexufo
06.08.2016 12:32Получается примерно так:
— сделать самоподписанный корневой
— сделать для него инсталлятор (абоненты ведь не руками будут это ставить, на дворе 21 век)
— сделать инструкцию для доменных админов, которые запрещают абы как менять хранилище корневых
— разгребать тонну звонков и писем по этому поводу
Сертификаты делаются один раз производителем дома. Ставятся незаметно для пользователя при первом запуске приложения за 1 сек копированием и привязкой к ip.
Чем это проще, чем плагины для браузеров?
Что проще, поддерживать зоопарк браузеров кроссплатформенно, или одну кроссплатформенную утилиту?
Ответ для любого разработчика очевиден.
Но почему-то вы упускаете из виду очевидное решение этой проблемы:
— на DNS-сервере для домена my-site.ru делаем запись localhost.my-site.ru = 127.0.0.1
— тогда и файл hosts менять не придется
Как я вам и писал
Сообщество безопасности Интернета прекращает действие имен интранета и IP-адресов в качестве основных доменных имен или альтернативных имен субъектов (SAN) в сертификатах SSL. Это решение распространяется на всю отрасль, а не только на нашу компанию.
https://ru.godaddy.com/help/prekrashenie-dejstviya-imen-intraneta-i-ip-adresov-v-ssl-6935
Можно подумать кто-то бы говорил о проблеме расширений для браузеров если бы они работали как надо. Разговор с того и начался что они везде постоянно глючат из за своих велосипедов, у кого с activeX (маки и убунты плачут) у кого долбанные ява аплеты.
Это проблема Касперского, DrWeb, ESET NOD32, Avast, Outpost, ZoneAlarm. Короче, где-то 40% рынка.
Стоит нод и вебер. первый раз слышу о проблеме что они насильно ломают какие-то сайты потому что в россии такие законы а они насильно мстят пользоваелю.
Разница, наверное, в том, что вы — производитель защищенных носителей с конфиденциальной информацией на борту.
Я не имею к производителю отношения. К тому же, не понимаю в чем проблема обвинений, когда весь интернет построен на http где всякое может случиться даже в подъездеAlexufo
06.08.2016 12:43с 1 октября 2016 г. центры сертификации (ЦС) должны отзывать сертификаты SSL, в которых используются имена интранета или IP-адреса.
это для любителей привязывать локальные ip к поддоменам.Andropolon
06.08.2016 22:16Это не противоречит.
К примеру, я покупаю сертификат на *.my-site.ru и делаю поддомен localhost.my-site.ruAlexufo
06.08.2016 23:13и если вы пропишите в нем локальный ip браузер забракует его при первой проверке. Должен, по крайней мере.
Andropolon
06.08.2016 22:30-1Сертификаты делаются один раз производителем дома. Ставятся незаметно для пользователя при первом запуске приложения за 1 сек копированием и привязкой к ip
Если делать публичный сервис, то все равно столкнешься с доменными администраторами абонентов, которые запретили установку корневых сертификатов своим абонентам.
Но ладно, проблему, видимо, можно решить за счет поддомена localhost.my-site.ru
Что проще, поддерживать зоопарк браузеров кроссплатформенно, или одну кроссплатформенную утилиту?
Нет, не очевиден.
Ответ для любого разработчика очевиден
Какая любимая фраза тех.поддержки? «Не работает? Попробуйте в другом браузере!»
С плагинами это работает безотказно. С вашим локальным сервером, видимо, если и не работает, то сразу везде.
А потом начальник тех.поддержки начинает капать на мозги тимлиду команды разработки.
Или еще того хуже — идет в финансовому директору и показывает отчет о расходах на ТП.
Я не имею к производителю отношения
Пост в блоге компании «Алладин Р.Д.»
В начале и в конце статьи я не вижу предупреждений, что статья написана человеком, не имеющим отношения к компании.
Видимо, поэтому и подумал.
К тому же, не понимаю в чем проблема обвинений, когда весь интернет построен на http где всякое может случиться даже в подъезде
Наверное, потому, что далеко не весь Интернет пользуется продуктами компании Алладин Р.Д.
Если я правильно понимаю, если речь идет о JC WebClient — значит автоматически и о токенах.
Очень надеюсь, что почти 100% сайтов, работающих с токенами, работают по https://
Стоит нод и вебер. первый раз слышу о проблеме что они насильно ломают какие-то сайты потому что в россии такие законы а они насильно мстят пользоваелю.
Я общался с DrWeb лично, и с Аваст по почте.
Первые сказали, что о проблеме знают, но не хотят лезть туда, где правит ФСБ (тем более, что у них есть сертификация своего антивируса в России, которой они дорожат)
Вторые полгода что-то пытались делать, потом сказали, что у них есть более приоритетные задачи, чем починить пару десятков сайтов у пары сотен своих пользователейAlexufo
06.08.2016 23:45Если делать публичный сервис, то все равно столкнешься с доменными администраторами абонентов, которые запретили установку корневых сертификатов своим абонентам.
Но каким-то образом умудрившихся установить дрова на токены без прав админисратора. А в сертификате значит вся засада будет. Сертификат по факту нафиг не нужен, просто с https сайта не сделать http запрос. В хроме можно но каждый раз нужно кнопку жать на «разрешить», вобще не удобно. А сами запросы делайте обшифрованные какие угодно если так хочется без этих сертификатов.
Какая любимая фраза тех.поддержки? «Не работает? Попробуйте в другом браузере!»
Ну так потому что рабочая фраза. Только в случае с плагинами этого сделать невозможно.
С плагинами это работает безотказно
особенно когда он только для IE, а для лисы, хрома, и столько же для мака и линукса. Итого ~ 9 зверей каждый со своими причудами.
Ни один браузер кроме IE не позволяет удобно соединять железо с сайтом через расширения. Все это костыльное, непроизводительное и не приятное постоянно текучее в разработке и поддержке дело. В лисе есть js-ctypes через него подключали сканер отпечатков прямо на веб страницу. Причем так мало инфы, если бы не стаковерфлоу уй бы сделали. И все равно тупило. В хроме хуже всего даже не брались. Еще ява апплеты живы в инетбанкинге. Жесть просто. Если бы взяли только js-ctypes и только лису для банкинга, по мне было бы куда лучше, чем все это явааплетные дырищи и игнорируемые мако и убунтоводы.
Или еще того хуже — идет в финансовому директору и показывает отчет о расходах на ТП.
Я не работаю в такой компании и продукт у нас для своих. Но то что за два дня человек сделал основу на шарпе того, что делал месяц в разработке расширения для листы говорит о многом. О скорости отладки раширений вообще отдельная песня. Сайт просто общается аяксом с железом, что еще нужно ?))
Сейчас же не важно чем пользуется пользователь, хоть хромом, хоть амиро браузером. Вообще не важно и это очень удобно.
у пары сотен своих пользователей
а говорили о слезах 40% рынка.Andropolon
07.08.2016 00:44Но каким-то образом умудрившихся установить дрова на токены без прав админисратора. А в сертификате значит вся засада будет.
Я сам встречался с такими админами — их ответ: «мы права не урезаем, нам просто самим так удобнее распространять свои корневые сертификаты по домену, ну а то что они при этом перестают ставиться у самих абонентов — мы не в курсе»
Ну так потому что рабочая фраза. Только в случае с плагинами этого сделать невозможно.
Возможно. У одного абонента с ломаной виндой плагин работает в одном браузере, у другого с пиратской сборкой — в другом.
В каком-то смысле оба абонента довольны.
В лисе есть js-ctypes через него подключали сканер отпечатков прямо на веб страницу
А я правильно понял, что код для сканера одинаковый для всех ОС? Windows, Linux, MacOS? Серьезно? Там же под Windows только 2 разных варианта…
В лисе есть js-ctypes через него подключали сканер отпечатков прямо на веб страницу. Причем так мало инфы, если бы не стаковерфлоу уй бы сделали. И все равно тупило
Там весь затык в MFC и ATL. Если писать на чистом Си — все работает относительно быстро.
Хотя где теперь найдешь таких программистов…
а говорили о слезах 40% рынка
У меня и у авторов антивируса разное понятие рынка… и разные масштабы…Alexufo
07.08.2016 01:09Админы разные бывают. Да, в расширении можно избежать админских прав. Но цену этого не знаю… все равно накатывают дрова на железо требующее админские права.
У одного абонента с ломаной виндой плагин работает в одном браузере, у другого с пиратской сборкой — в другом. В каком-то смысле оба абонента довольны.
А как для разработчика, он один раз пишет js для обмена с токеном код. Один раз на все платформы. И только сервер точится под платформу.
Ну конечно с плагином для связи сканера нужно писать кросплатформенно если такая есть задача. Нет, у нас винда была. Пихали поток картинок в браузер с SDK чтобы оператор на сайте сделал стоп в нужном прижиме пальца. И все время не покидало чувство а нафига тут расширение)) все равно dll ка пишется для связи. И просадок FPS был в два раза. На чистом си… ха… мы не те специалисты)) А когда узнали что поток интерфейса лисы работает в том что что и плагин… и когда лиса висит пока сканер не отдаст… это был бы капец без стаковерфлоу. Причем хрен где это написано с примерами.
Alexufo
05.08.2016 00:12Как вы понимаете, кто к вам пришел?
origin подделать незя через js. А он всегда при кроссдомене передается.
https://habrahabr.ru/company/aladdinrd/blog/306920/?reply_to=9734538#comment_9731340Andropolon
05.08.2016 07:39Есть гипотеза, что в IE можно подделать то ли через msxml2.XMLHTTP.6.0, то ли через msxml2.ServerXMLHTTP.6.0
Alexufo
05.08.2016 12:02Есть гиптоеза что Referer при аяксе можно было подделать только 00-ые.
Andropolon
06.08.2016 09:52-1Дак Referrer или Origin?
Referrer — да, нельзя подменить, но при запросах с https:// на http:// он пропадает, что накладывает ограничение на использование вашего API
Origin — поменять можно, работает хоть в IE6, хоть в IE11, через объект Msxml2.ServerXMLHTTP можно выставить любой origin и скачать файл с любого стороннего веб-сайта. Таким образом, пользователи IE потенциально уязвимы в вашем случае.
Что могу порекомендовать — для IE оставить вариант с ActiveX, а для остальных браузеров сделать вариант с locahost
Раньше ведь вы поддерживали 2 варианта — ActiveX и NPAPI.Alexufo
06.08.2016 12:07-1По стандрату Origin невозможно изменить программно.
Andropolon
06.08.2016 22:021) если бы все работало по стандарту — я бы, наверное, тут не писал :-)
2) думаю, что хакера, который будет использовать эту уязвимость, такой ответ не остановит :-)Alexufo
06.08.2016 23:51хакера должны пруфы приводить.
Andropolon
07.08.2016 00:46Накидал по-быстренькому:
http://andrew-ch.narod.ru/cors.htm
Походу M$ таки движется к закрытию своих дырок — на последней сборке IE11 уже по умолчанию не работает — приходится сайт добавлять в надежные узлы.
Но почему-то мне кажется, что в прошлом году я проверял — и работало без этого.Alexufo
07.08.2016 00:57у меня и в надежные не добавляет. Говорит не https(
статься 10 года. Вроде бы как… должно было работать как CORS появился нормальный
https://blogs.msdn.microsoft.com/ieinternals/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds/Andropolon
07.08.2016 01:02Чтоб добавить http, надо снять галочку «Для всех сайтов требуется https:» в том же окне, где добавляете сайт.
Потом, после теста, удалить сайт и вернуть галку
P.S. XDomainRequest — это другое, здесь был баг именно в самом ActiveX, слабо относящемся к IE
Alexufo
02.08.2016 23:22У нас утилита — локальный сервер на https://localhost:5000. Общение аяксом. Отдает в браузер сканы со сканера, как получает новые в папке, так и посылает с браузера на термопринтер этикетки.
Только в Лисе нужно подтвердить сертификат, так как у нее свое хранилище. В остальных браузерах все на ура сразу.
Alexufo
02.08.2016 23:35+1На самом деле для всех кто мучался с токенами инет банков пришло большое благо, отлаживать локальные вебсервера на ошибку разработчикам КУДА проще чем все эти недоплагины к браузерам. Плюс независимость от браузера, наконец-то. Плюс кроссплатформенность на фронтэнде. Куча проблем, помоему, решается.
ivlis
02.08.2016 23:52-1Вместо некоторого, но всё же ограниченного круга браузеров теперь вам нужно поддерживать 9000 разных операционных систем и архитектур. Отличное решение, что же тут скажешь.
Jaromir
03.08.2016 10:32Поставить всю эту байду с ключами и ПО на сервер. Сотрудникам пробросить локальный прокси на нужный порт (через интернет в том числе). Если такая схема работает, то shut up and take my money
dkameleon
03.08.2016 10:32Вебмани Кипер абсолютно аналогичным образом подписывает запросы при платежах и авторизациях.
Может с десяток лет, может даже больше.
yarphen
03.08.2016 19:44при работе через локальный прокси-сервер пользователь видит в адресной строке браузера не реальный URL веб-страницы на удалённом сервере, а что-то наподобие 127.0.0.1:12345
Локальный прокси на то и прокси, чтоб физически находиться на локальном адресе, который прописывается в настройках, а для доступа использовать оригинальный адрес удаленного сервера, но никак не адрес локалхоста. Поведение, указанное в цитате, относится к локальному веб-серверу.
methlab
04.08.2016 09:00Заявленные минусы решения на основе прокси сервера 1 и 3 — глупость, вы, видимо, в принципе с технологией не разобрались.
В целом, согласен, что решение на базе локального веб-сервера адекватнее.
Andropolon
04.08.2016 20:22Поздравляю, вы изобрели велосипед: https://habrahabr.ru/company/skbkontur/blog/131552/
P.S. насколько мне известно, СКБ Контур отказался от этой технологии несколько лет назад и перешел на плагины под каждый браузер
https://help.kontur.ru/plugin/Alexufo
05.08.2016 00:00и программа и плагины. Любят пользователей то как.
Andropolon
05.08.2016 07:54Попробовал поставить в разных браузерах. Вроде даже что-то работает. И даже антивирус не сругнулся. Может быть, на самом деле любят?
Saffron
05.08.2016 09:59Первый раз слышу про уязвимости NPAPI. Можно дать пруфов?
sav1812
05.08.2016 10:10Вот, например: http://www.pcworld.com/article/2049309/chrome-will-block-npapi-plugins-over-stability-security-concerns.html
А вообще — поиск по словам «NPAPI vulnerabilinies»…Vizakenjack
06.12.2016 15:37У ДОУ был бот тимса, они его купили за относительно небольшие деньги.
sav1812
05.08.2016 11:34Ну, если это, судя по всему, вопрос веры, то я — пас. :)
Мне кажется, будь у Вас действительно желание найти эту информация — давно бы уже нашли самостоятельно, как это сделал я по указанным выше ключевым словам. Ссылок выдаёт достаточно много, есть что почитать. Было бы желание…Saffron
05.08.2016 12:48Кто предоставляет информацию, тот предоставляет и пруфы. Опять же, неужели так сложно поделиться ссылкой, если вы и в самом деле нашли информацию. Я прошёл по первым семи ссылкам выдачи гугла и кроме означенного пресс-релиза никакой информации не нашёл. А пресс-релиз от разработчиков хрома постулирует наличие уязвимостей, но не предоставляет ни одной для ознакомления.
LSD
08.08.2016 16:47Для локального веб сервера HTTPS нужен не только сертификат, но и еще и приватный ключ от этого сертификата.
Вы его открыто храните в системе и не паритесь?Saffron
09.08.2016 03:58+1Вы открыто храните бинарник браузера в системе и не паритесь? А ведь подменив браузер, можно добиться ещё большего, чем просто подменив сертификат.
LSD
09.08.2016 12:47-1Подмененный бинарник опасен только для этой системы. А украденный сертификат, позволяет атаковать удаленную систему.
1. Спуфим DNS и подменяем localhost.server.com с 127.0.0.1, на IP нашего сервера.
2. Приватный ключ к сертификату у нас уже есть, поднимаем свой сервер и может пытаться атаковать браузер клиента.Saffron
09.08.2016 13:49+1Это локальный прокси. Применяется к своему компу. Чужой комп не будет иметь ваших корневых сертификатов в списке доверенных
LSD
09.08.2016 13:57-11. Это не прокси, это веб сервер.
2. Корневой сертификат будет на любом компьютере на котором используется данное ПО. Т.е. если это банк клиент, то у всех клиентов банка.
Разработчики скромно умолчали, что надо будет делать клиентам которые используют данный ключ, чтобы добавить сертификат. И откуда возьмется сам веб сервер, как будет запускаться и т.д…mayorovp
09.08.2016 15:51Если по уму делать, то корневой сертификат на каждом компе — свой (генерируется при установке).
LSD
09.08.2016 16:27-1Это костыли.
По уму, получается сертификат на server.com с правом подписи на поддомены. Генерируются ключ+сертификат на localhost.server.com и загружается на токен (лучше на каждый токен свой, но можно и один на все, тогда право подписи не нужно). Сам токен реализует вебвервер. Никаких левых сертификатов в truststore, ключ никак не извлечь из системы.
datacompboy
А что на счет HTTPS cертификата? Вы его для 127.0.0.1 поставляете вместе с ключом?
Evengard
А в чём проблема сделать домен localhost.mydomainname.com с A записью = 127.0.0.1, и получить сертификат на этот самый localhost.mydomainname.com?
Akuma
А так можно?
Всмысле, не разу не пробовал делать A запись на 127.0.0.1
datacompboy
Да, можно. И таких вагон уже в интернете, например http://readme.localtest.me/ — даже с сертификатом.
вопрос в другом — что мешает вирусу запустить сервис на другом локальном порту, и продолжать выглядеть как белый и пушистый, проксируя, например, запросы реальному локалхостовому?
Порта в SSL сертификате нет, браузеры его не проверяют…
Evengard
А толку-то. Приложение-то обращается к конкретному порту, забинденному легитимным сервером. Никто вручную не переходит на localhost:xxx, оно вызывается js-приложением. Теоретически можно и его подменить, но так теоретически можно вовсе троян полноценный поставить или ещё что похуже. Сертификаты тут уже не помогут, если враг уже имеет доступ к устройству.
Alexufo
Когда вирус в системе, ему уже ничего не мешает. Даже выпускать сертификаты) Правда только не для лисы. У нее свое хранилище сертификатов.
mayorovp
… в которое тоже можно засунуть свой сертификат, если целенаправленно заняться этим вопросом.
Alexufo
Элементарно. Выдаете самозаверенный и авторизирующего центра, помещаете в хранилища, биньдите на порт локалхоста, все шито крыто. Правда первый раз хорошенько нужно повозюкаться, чтобы разобраться как все это работает.