Comments 67
Всегда возникал вопрос по безопасности. Кто мешает другим приложениям воспользоваться теми же прокси и наподписывать, что Бога на душу положит?
например, то, что для того чтобы что-то подписать нужно знать пароль, да и токен должен быть вставлен
Безопасность зависит от реализации.
Ломали мы это дело. В памяти браузера после ввода ПИНа он сохранялся в памяти. Вызывая второй раз метод sign() и + заюзав параметр silent получилось, что вторая подпись пошла без шума и запроса пинов.
Второе, если не предусмотрен механизм блокирования и/или обязательного использования диалогового окна, то PIN можно тихо «брутить» используя JavaScript. Особенно если ПИН числовой и от 4 символов 8)
Классический активИкс — «проблемен» с точки зрения ИБ. Лучше избегать этого решения, по возможности.
Апплет — плох тем, что тащит за собой джава машину, дырявую и ненадежную, а еще многие БК перестают работать, если обновить Java.
Может я параноик)
Ломали мы это дело. В памяти браузера после ввода ПИНа он сохранялся в памяти. Вызывая второй раз метод sign() и + заюзав параметр silent получилось, что вторая подпись пошла без шума и запроса пинов.
Второе, если не предусмотрен механизм блокирования и/или обязательного использования диалогового окна, то PIN можно тихо «брутить» используя JavaScript. Особенно если ПИН числовой и от 4 символов 8)
Классический активИкс — «проблемен» с точки зрения ИБ. Лучше избегать этого решения, по возможности.
Апплет — плох тем, что тащит за собой джава машину, дырявую и ненадежную, а еще многие БК перестают работать, если обновить Java.
Может я параноик)
С тем, что все зависит от реализации, полностью согласен.
Но вообще параметр silent влияет лишь на то, будет ли показано диалоговое окно для ввода пароля перед подписыванием или нет, соответственно если silent==true, то разработчик сам должен где-то взять этот пароль и подставить при подписании и да, если разработчику вдруг вздумается хранить этот пароль в файловой системе (я утрирую), то да, это потенциальный источник уязвимости.
По хорошему, надо каждый при действии, которое связано с подписью, спрашивать у пользователя пароль, но, к сожалению, не все пользователи такие параноики в этом вопросе (а зря?), им гораздо приятнее один раз ввести пароль и на текущую сессию забыть о нем.
Насчет JRE не сказал бы, что она дырявая и ненадежная, если дыры и появляются, они тут же закрываются, да и объективно серьезные уязвимости появляются не так часто (в сравнении с другими системами).
Но вообще параметр silent влияет лишь на то, будет ли показано диалоговое окно для ввода пароля перед подписыванием или нет, соответственно если silent==true, то разработчик сам должен где-то взять этот пароль и подставить при подписании и да, если разработчику вдруг вздумается хранить этот пароль в файловой системе (я утрирую), то да, это потенциальный источник уязвимости.
По хорошему, надо каждый при действии, которое связано с подписью, спрашивать у пользователя пароль, но, к сожалению, не все пользователи такие параноики в этом вопросе (а зря?), им гораздо приятнее один раз ввести пароль и на текущую сессию забыть о нем.
Насчет JRE не сказал бы, что она дырявая и ненадежная, если дыры и появляются, они тут же закрываются, да и объективно серьезные уязвимости появляются не так часто (в сравнении с другими системами).
Java основной источник проблем в этом году. ~60% пробива именно с Джава Эксплойтов.
+ не все сразу ставят патчи.
+ как я уже говорил, обновление Java иногда не поддерживается производителем апплета, такое было и не раз и именно с модулями для работы с ЭЦП 8)
+ не все сразу ставят патчи.
+ как я уже говорил, обновление Java иногда не поддерживается производителем апплета, такое было и не раз и именно с модулями для работы с ЭЦП 8)
Про 60% ничего не слышал.
А то, что кто-то не сразу ставит патчи, даже когда их об это предупреждают, это их проблемы, согласны?
А то, что кто-то не сразу ставит патчи, даже когда их об это предупреждают, это их проблемы, согласны?
И? где здесь сказано о том, что «Java основной источник проблем в этом году. ~60% пробива именно с Джава Эксплойтов.»
Поймите правильно, я не говорю о том, что в JRE нет уязвимостей, но чтобы 60% всех дыр принадлежало ей, а где же Windows?))
Ну на скрине показано, что 97% пробива благодоря Java Rhino эксплойту. конкретно с этого сплойт-пака. Вот более свежий скрин:
В сумме опять же Java обходи Acrobat в пробиве.
Windows нету. Последние угрозы от MS были в Duqu. И то, использовались при целевых атаках на АСУ ТП таргеты. Для заражения простых пользователей инета юзают сплойты для Java, Adobe Reader, Adobe Flash — это основные клиенты.
В сумме опять же Java обходи Acrobat в пробиве.
Windows нету. Последние угрозы от MS были в Duqu. И то, использовались при целевых атаках на АСУ ТП таргеты. Для заражения простых пользователей инета юзают сплойты для Java, Adobe Reader, Adobe Flash — это основные клиенты.
Java Rhino — движок JavaScript с открытым исходным кодом. И причем тут java? Давайте теперь скажем, что 99% приложений с уязвимостями используют на С\С++ и поэтому нужно выбросить эти языки программирования?
This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of ___Oracle Java___. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.
The specific flaw exists within the way Java handles Rhino Javascript errors. ___The built-in javascript engine in Java___ fails to perform sufficient sanitation on javascript error objects. The effect is that untrusted code can run in privileged context. This can result in remote code execution under the context of the current user. © ZDI про этот эксплойт. Ошибка в конкретной реализации, в Oracle Java.Язык программирования не причем, тут речь шла о том, что модно было эксплуатировать уязвимости в Oracle Java, так как все интересные дырки находились именно там.
Не 60% дыр, а 60% пробива живых эксплойтов, что важнее 8)
Это немного другая статистика. Антивирусная. То есть тут тупо детекты Каспера. Тут выходит что Stuxnet LNK эксплойт — самая ЧАСТО встречаемая и детектируемая Каспером уязвимость (причем локальная, как правило). Я же приводил стату с сплойт-паков, то есть «реальные» пробивы и установку трояна по интернетам. Или вы думаете, что кибер-преступники специально выбирают «плохие» эксплойты? Они выбирают то, что работает и что легко сделать.
Если так интересно мнение антивирусных экспертов, то:
habrahabr.ru/company/eset/blog/141365/
Тут ESET говорит, что Java сплойты в тренде 8)
Но мы так долго можем, просто я думаю, что Java это не самое безопасное ПО и с обновлением тоже бывают проблемы. Когда пишешь свой Плагин к браузеру, ты хотя бы контролируешь безопасность, а не надеешься на Oracle.
Если так интересно мнение антивирусных экспертов, то:
habrahabr.ru/company/eset/blog/141365/
Тут ESET говорит, что Java сплойты в тренде 8)
Но мы так долго можем, просто я думаю, что Java это не самое безопасное ПО и с обновлением тоже бывают проблемы. Когда пишешь свой Плагин к браузеру, ты хотя бы контролируешь безопасность, а не надеешься на Oracle.
Да, мы можем долго говорить о том, безопасна ли Java, в принципе с таким же успехом долго можно было говорить о .net или об уязвимостях в самих веб-приложениях. Проблемы есть и о них разработчик, безусловно, должен знать.
Java часто используется для ЭЦП не потому, что она самая-самая безопасная, здесь есть другие плюсы.
А что касается, лучше самому написать, то практика показывает, что именно в таких решениях чаще всего бывает много критичных уязвимостей, да и устраняют их не так оперативно, как Microsoft, Oracle, Google и тд…
Сойдемся на том, что нужно ставить обновления, которые устраняют проблемы с безопасностью (о какой бы среде мы не говорили) и быть немного параноиком)
Java часто используется для ЭЦП не потому, что она самая-самая безопасная, здесь есть другие плюсы.
А что касается, лучше самому написать, то практика показывает, что именно в таких решениях чаще всего бывает много критичных уязвимостей, да и устраняют их не так оперативно, как Microsoft, Oracle, Google и тд…
Сойдемся на том, что нужно ставить обновления, которые устраняют проблемы с безопасностью (о какой бы среде мы не говорили) и быть немного параноиком)
Конечно, не ставишь апдейт — сам виноват)
Но я так же добавил про случаи, когда апдейт поставить было не возможно, так как переставало работать ДБО 8)
Но я так же добавил про случаи, когда апдейт поставить было не возможно, так как переставало работать ДБО 8)
Проблему «улова» PIN-кода и несанкционированной подписи при состоянии залогинен успешно решают продвинутые токены — pinpadы
UFO just landed and posted this here
Буквально на днях столкнулся с настройкой IE для ЭЦП. Считая себя опытным юзером в настройке IE, во время настройки пришлось поматериться, при этом осознавая, что мне далеко до опытного юзера.)))
Благо пока с разработкой не сталкивался.
Благо пока с разработкой не сталкивался.
IE и его настройка для того, чтобы заработало ЭЦП мне до сих пор иногда снится после 2.5 лет работы в поддержке брокерской конторы, где ЭЦП использовалась для подписи отчетов клиентами. Фраза «Зайдите в меню Сервис-Свойства обозревателя-Вкладка безопасность..» была самой популярной в процессе работы, хотя мы поддерживали и кучу другого куда как более сложного софта.
Я сейчас пишу кроссбаузерный плагин с помощью www.firebreath.org
Рекомендую посмотреть Рутокен Web www.rutokenweb.ru/
Рекомендую посмотреть Рутокен Web www.rutokenweb.ru/
Не хочу казаться совсем недалеким человеком, но есть вопрос к людям, понимающим в крипто. Зачем подписывать запросы, если установлено соединение TLS, а пользователь идентифицируется (логины-пароли, sms и прочее)?
Вполне логичный вопрос. TLS/SSL для обмена ключами и проверки их подлинности использует алгоритмы RSA, Diffie-Hellman, DSA — все это здорово работает, но вот проблема: в наших странах эти алгоритмы не имеют никакой юридической силы (хотя в России вроде как RSA уже разрешен, поправьте, если не так) и следовательно не могут быть использованы.
Аналогичная ситуация с алгоритмами шифрования.
Аналогичная ситуация с алгоритмами шифрования.
UFO just landed and posted this here
Вполне законно, если установлен криптопровайдер CSP, который реализует ГОСТы и «встраивается» условно говоря, в IE. Например, КриптоПро CSP.
При использовании решений аля sTunnel список браузеров расширяется.
При использовании решений аля sTunnel список браузеров расширяется.
Это законно и вы можете использовать их сколько угодно, другое дело, что из-за того, что там используются по умолчанию алгоритмы, которые не соответствуют ГОСТам, вы не сможете в суде доказать, что, скажем, подпись действительна.
TLS — это транспорт, а в теме речь идет об ЭЦП. Это уже юридически значимый документооборот, а не просто шифрование канала. С дампом сниффера в суд вряд ли пойдешь доказывать, что клиент банка подписал платежку))
А почему не сделать так, как делает webmoney classic? Пишем клиентское ПО на той же java, делаем ее слушать какой-то порт >1024(чтоб рут не требовался) на 127.0.0.1, а дальше из браузера ссылки подставляем.
Ничто не мешает) в данном случае вовсе необязательно использовать java.
Меня, кстати, тоже поражает, почему никто в этой проблемной области до сих пор не додумался до межсайтовых запросов… И не надо никаких костылей вообще.
UFO just landed and posted this here
Реализовывали как wpf-контрол. IE-only, зато при прямых руках работает без админских прав и танцев с бубном вокруг настроек браузера.
Интересно, а никто не пробовал делать подпись через Flash Player?
А техническим это вообще возможно? Ведь удаленные swf вроде как не имеют доступа к локальным ресурсам.
Я эту технологию не знаю, вот и интересуюсь
В теории это можно делать через Silverlight и Adobe AIR. И там, и там необходимо подписывать приложение, чтобы оно имело доступ к нативному коду.
Насколько я знаю, в Silverlight только приложения, которые работают вне браузера, могут претендовать на дополнительные привилегии. В 5-ой версии кажется появилась возможность давать повышенные привилегии приложениям, работающими в окне браузера, но через большую, извините, опу.
Насчет подписывания flash никогда не слышал, интересно, есть ли такая возможность.
Насчет подписывания flash никогда не слышал, интересно, есть ли такая возможность.
можно делать через Silverlight и Adobe AIR
И чем это будет принципиально лучше того же CAPICOM через ActiveX?
Вполне возможно. Надо, всего лишь, что б сервер выдал соответствующий ответ на запрос о кросдоменной политике безопасности.
Эх, знакомая проблема. Сколько было часов потрачено на решение. Итог: работа с ЭЦП через апплет. Работает на всех браузерах. В приципе особых проблем пока замечено не было, даже далекие от комьютеров пользователи успешно справляются с накладыванием подписи.
Единственное более-менее верное решение — реализовать все криптоалгоритмы на javascript'е — требует невероятных усилий, а в некоторых случаях сталкивается с запретом на законодательном уровне
Единственное более-менее верное решение — реализовать все криптоалгоритмы на javascript'е — требует невероятных усилий, а в некоторых случаях сталкивается с запретом на законодательном уровне
реализовать все криптоалгоритмы на javascript'е
Алгоритмы вы, допустим, реализуете, а что делать непосредственно с процессом подписи? Доверять закрытый ключ каким-то внешним скриптам?
Если вы доверяете серверу и скрипты приехали по HTTPS, то доверять им ключ не существенно небезопаснее, чем доверять ключ ActiveX.
Не каким-то, а вашим, и здесь абсолютно нет никакой разницы заставляете вы доверять пользователя вашим скриптам, или java апплету, или ActiveX или плагину или чему-то еще, если разработчик захочет, он получит ваш пароль, я не рассматриваю здесь моральную и другие стороны вопроса. Для пользователя здесь только одна защита — держать сам токен всегда при себе.
Мы как-то реализовывали обмен между веб-клиентом и локально установленным приложением через реализацию в приложении примитивного веб-сервера и обращению к нему из клиента через JSONP. Вполне рабочая схема, позволяет избавиться от апплета. Еще один неплохой вариант на перспективу — Silverlight. Неплохая кроссплатформенность, инфраструктурные решения для X.509 в .NET есть, реализации большинства алгоритмов также.
Но если у вас не установлена JRE, ничего не будет.
По сравнению со всеми прочими способами это, пожалуй, наименьшая проблема.
Да, чтобы все работало, сам апплет должен быть подписан.
Как вы мыслите использование неподписанных апплетов в столь критичной области?
Верификация апплетов — это не панацея. Просто потому, что процедура в той же java реализована так, что скорее всего многие юзеры нажмут «Доверяю» по умолчанию.
Проблему верификации надо решать, на мой взгляд, на уровне верификации сервера, с которого приехал апплет, то есть в рамках HTTPS.
Проблему верификации надо решать, на мой взгляд, на уровне верификации сервера, с которого приехал апплет, то есть в рамках HTTPS.
Вопрос не в том, чтобы кто-то мыслил или не мыслил о подписании апплета в какой бы там ни было области, вопрос скорее технический, если ваш апплет подписан не будет, он просто не получит доступа к тем локальным ресурсам, которые вам необходимы для реализации ЭЦП, вот и весь вопрос.
СКЗИ должно обеспечивать библиотеками для работы с OCSP/TSP и все прочие ИОК вызовы делать на своей стороне. Если давать разработчикам низкоуровневые функции, ничего не выйдет кроме багов. Встречал случаи, где даже корневые не проверялись нормально. PKI он такой PKI…
Совершенно согласен, и очень часто из-за этого происходят такие досадные случаи, когда в вполне серьезных системах подпись проверяется… как бы так сказать, по наличию, о, есть подпись — отлично, считаем ее валидной, я не говорю уже о том, как часто не проверяется, что сертификат наш уже давно в СОС-ах лежит и тд. и тп… И все эти вопросы возлагаются на разработчика, проблемам удивляться не приходится.
Тоже вставали перед такой проблемой. Написали свой велосипед с клиентским приложением (не хотелось связываться с java) + ActiveX для пользователей IE
Sign up to leave a comment.
ЭЦП в браузере: проблемы, решения, личный опыт