iBublik Oct 31 2011 at 11:56

Кроссбраузерный запуск «злобного» кода на клиенте

4 min

14K

Контур corporate blog

+38

Comments 50

IamKarlson Oct 31 2011 at 12:41

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

d3sire Oct 31 2011 at 12:48

49% IE, ужас…

iBublik Oct 31 2011 at 12:51

Немалую роль в этом играло то, что раньше подписывать отчеты можно было только из IE

raptor Oct 31 2011 at 12:59

Судя по цифрам все же 59% — 49% это только ie8+

iBublik Oct 31 2011 at 13:01

Нет, это в цифрах ошибка. 49% — это весь IE. Сейчас исправлю.

aleks_raiden Oct 31 2011 at 14:26

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

iBublik Oct 31 2011 at 14:32

А можно ссылку?

kip Oct 31 2011 at 15:04

Битрикс в Управлении Сайтов 11 такое сделал для шифрования пароля без необходимости использовать SSL.

aleks_raiden Oct 31 2011 at 15:12

www9.atwiki.jp/kurushima/pub/jsrsa/
www.hanewin.net/encrypt/rsa/rsa.htm
www-cs-students.stanford.edu/~tjw/jsbn/
ddev.ru/271/php-rsa-encoding-decoding-and-js-decoding-and-encoding-rsa/

aisek Oct 31 2011 at 15:26

Примерно такую — можно. Но нам необходимо было реализовывать ГОСТ-овскую криптографию, так что на чистом js все равно не получится.

EugeneSukhov Oct 31 2011 at 21:31

Думаю, сложности нет. habrahabr.ru/blogs/web_security/123372/ — пример реализации ЭЦП по ГОСТ на js.
Но, видимо, ограничения вызваны еще и требованиями к сертифицированной криптографии?

aisek Nov 1 2011 at 06:52

Дак дело не только в реализации. Нужно ведь еще и закрытый ключ пользователя получить

neuotq Oct 31 2011 at 13:33

Гм… вообще для этих цеелй используют java аплеты.
Хотя я всё лелею мысль о подписи без них и тем более без приблуд что у вас.

iBublik Oct 31 2011 at 14:24

Java-апплеты мы как-то не рассматривали. Дело в том, что нам не хотелось иметь никаких внешних зависимостей. А java установлена далеко не у всех, например у 20% наших пользователей нет java-плагина в браузере.
А мысль о подписи без костылей мы тоже нежно лелеим.

neuotq Oct 31 2011 at 14:27

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

EugeneSukhov Oct 31 2011 at 21:38

Зависимость все равно есть, в данном случае от вашей программы. Почему не стали использовать плагин? Актив реализовал всю необходимую криптографию в кросплатформенном и кроссбраузерном плагине. Работает везде, админ прав не требует. Использует сертифицированное ФСБ аппаратное СКЗИ Рутокен ЭЦП.

aisek Nov 1 2011 at 06:54

Я лично не слышал об этом плагине, надо будет посмотреть, насколько он удобен нам.

EugeneSukhov Nov 1 2011 at 07:52

rutokenweb.ru

aisek Nov 1 2011 at 08:07

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

EugeneSukhov Nov 1 2011 at 10:04

То есть ваше решение просто прослойка для обращение к установленному криптопровайдеру? Да уж, внешних зависимостей почти нет :)

EugeneSukhov Nov 1 2011 at 10:11

Немножко поясню. В решении Рутокен Web имеется реализация базового криптографического функционала. В качестве носителя могут использоваться токены Рутокен ЭЦП и Рутокен Web. Решение независимо, не требует установки криптопровайдеров или других дополнительных компонент. Однако оно не заменяет криптопровайдер, оно может служить для решения конкретных задач. В качестве примера на rutokenweb.ru реализован защищенный механизм аутентификации.

yaremko Nov 1 2011 at 10:50

А есть надежда, что докрутите до варианта который можно для подписи отчетов использовать?

EugeneSukhov Nov 1 2011 at 11:11

Механизм подписи так же реализован.

yaremko Nov 1 2011 at 11:12

А почему нельзя рутокен веб для подписи отчетов использовать? Без установки СКЗИ

EugeneSukhov Nov 1 2011 at 11:27

Использовать можно. Видимо, Эврика работает с клиентами у которых уже по наследству от Контур-Экстерн установлено какое-либо СКЗИ.

yaremko Nov 1 2011 at 11:32

Посмотрите хабрапочту плиз

iBublik Nov 1 2011 at 12:46

Все верно. Мы в первую очередь рассчитываем на тех наших клиентов, у котрых уже установлен Контур-Экстерн и как следствие стоит Крипто-Про

aisek Nov 1 2011 at 14:21

Ну дело не только в СКЗИ. Все-таки у нас есть и клиенты, которые не пользуются Рутокеном. Но было бы очень интересно, если бы вы рассказали поподробнее, как использовать Рутокен ЭЦП для подписи отчетов.

EugeneSukhov Nov 1 2011 at 16:50

см. почту.

grokinn Oct 31 2011 at 15:11

а сейчас только зарплатный сервис работает по этой схеме, или уже весь контур можно под любыми браузерами запускать?

aisek Oct 31 2011 at 15:23

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

ComodoHacker Oct 31 2011 at 16:38

То есть теперь можно обратиться по http к вашей прокладке и подписать что угодно? Или участие пользователя в момент обращения к закрытому ключу все же необходимо?

aisek Oct 31 2011 at 20:23

Нет, прокладка принимает вызовы только с адреса 127.0.0.1. Так что обратиться можно только из js-кода.

EugeneSukhov Oct 31 2011 at 21:33

Что мешает вызвать тот же метод, что реализован у вас на сайте при посещении другого ресурса?

aisek Nov 1 2011 at 06:55

Ну origin при запросе, разумеется, проверяется.

ComodoHacker Oct 31 2011 at 22:39

Я понял, имел в виду обращение какого-нибудь трояна и т.п.

Так участие пользователя требуется или нет?

И еще вопрос. Этим ключом имеет смысл подписывать только ваши отчеты, или его можно еще как-то использовать?

aisek Nov 1 2011 at 06:58

Троян и так может обратиться напрямую к реестру, CryptoApi и т.п. зачем ему обращаться к нашему сервису?

Нет, не требуется. Ради этого все и затевалось.

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

ComodoHacker Nov 1 2011 at 20:10

> зачем ему обращаться к нашему сервису?

Например, чтобы подписать что-то без ведома пользователя.

aisek Nov 2 2011 at 06:51

Дак он и так это может сделать. Что ему мешает вызвать соответствующий метод CryptoApi?

ComodoHacker Nov 3 2011 at 00:16

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

Eureka Oct 31 2011 at 20:45

А Webmoney Keeper не по этому же принципу работает? Там вроде также висит локальный сервер в виде кипера к которому идет обращение из браузера. Вроде во всех браузерах работает. Не смотрели его реализацию до разработки своего решения?

iBublik Nov 1 2011 at 08:17

Возможно по этому же :) Нет, реализацию его не смотрели. Реализовать локальный веб-сервер — это не проблема. Тем более, что нам и реализовать пришлось ВООБЩЕ не работу с криптографией (100500 разных методов). Как Данил написал в статье, у нас уже есть экстерновская активиксина, которая все умеет. Мы написали только проксирование вызовов ее COM-объектов с javascript-а. Поэтому разбираться пришлось только с кроссдоменными вызовами, и тут уж смотрели все что есть.

Eureka Nov 1 2011 at 08:40

Реализовать локальный веб-сервер — это не проблема

Это понятно. Я имел ввиду реализацию запуска «злобного» в браузере. Просто в статье вы пишете о нескольких безуспешных попытках использования тех или иных подходов: CORS, FLASH, JSONP… Возможно, подглядев за работой того же WM Keeper, вы сократили бы свое время.
Но это вовсе не упрек! Лишь пояснение своего комментария.
За статью вам спасибо, и статья как раз получилась полной и интересной благодаря обзору нескольких подходов.