Система может ставиться и локально в сети банка и предоставляться как сервис (как cloudflare)
Кстати для организаций с локальными системами типа CRM это отличная защита от взлома своими же сотрудниками. Нулевая задержка сети ведь и браузер и сервер в одном здании.
Да рендерер нужен был только для канваса. Но headless браузер нужен, ведь клики надо имитировать. Интересно можно ли вебкит использовать в таком ключе из коробки или нужно долго допиливать
>А как тогда это будет синхронизироваться? то есть один запрос упал, подвис и т.п.
Упал/подвис врядли, вебсокет все же. Про реализацию не могу точно описать тк ее еще нет — можно отсылать полную строку например на onblur/onchange. Вопрос решаемый.
> Ну это тоже добавляет проблему доверия
Почему, если SC сервер является частью инфраструктуры то он вполне достоверно проксирует полученные данные, ему можно верить. Сам он читает его из реального айпи пользователя и передает bank.com уже в хедере.
>Просто по требованиям pci dss нельзя слать эти данные обратно и есть если я ввел номер карты или не дай бог cvv2 вы не можете его отправить обратно в не маскированном (номер, например VISA *6680) или ни в каком виде (для cvv).
Те нельзя через вебсокет послать дифф когда юзер печатает CC? Ок, можно сделать костыль для полей CC и не слать их назад.
>В случае банка я через такую получу доступ на выполнение кода на сервере банка.
Каждая сессия это отдельная виртуализация на сервере SC, не на сервере где сам bank.com. Они могут быть физически рядом для уменьшения network latency, но общаться будут только через HTTP. И чтобы использовать баг в вебките сначала нужно найти способ вставить свой код, те interface based XSS.
В каком плане получить доступ к серверу? Каждый сервер создается только для сессии и сразу уничтожается. Если имеется ввиду получить доступ к выполнению кода JS (XSS) то да, понять чей код будет нельзя и он сможет обойти защиту для большинства векторов (кроме тех что не выполнимы в JS, например heartbleed). Если доступ вообще к экосистеме securecanvas то это глобальный MITM всех загружаемых сайтов. Оно, конечно, плохо — но Cloudflare уже давно находится в этой позиции и контролирует кучу сайтов, и это никого не пугает.
В идеале securecanvas должен использовать минимум библиотек и кода, тк от него требуется создание инстансов, работа с вебсокетами и браузерами, те обычному apache/nginx там нечего делать. Меньше кода дает все же меньше поверхность атаки.
А можно реалистичные сценарии, на основе интерфейса? Понятно что есть еще javascript: ссылки, но большинство XSS/SQLi зависят именно от набора '"<>. Цель технологии защита от изменений запросов и сложных 0day, а не от того что кто то *очевидный* юзер инпут не может проверить.
Я не удержался от использования «абсолютно безопасный» как маркетинговой удочки. В глобальном смысле конечно таких нет. А если менее строго судить то даже OWASPовский damn insecure app станет намного безопасней. И «может спасти только от некоторых типов атак» наоборот — только некоторые типы атак (связанные с интерфейсом) не может предотвратить. Атаки типа фишинга/доса, как сказано выше, я не учитывал
> Все равно задержки будут адовые, любой символ который я ввожу прежде чем быть отображен должен быть обработан webkit'ом возможно даже на другой стороне нашего шарика
Как раз в версии с DOM он будет показан сразу на экране, потом пошлется в облако и к тому времени как вы нажмете Submit форма в облаке будет так же заполнена. Насчет изменений инпута — сделать простенький костыль чтобы не мерцало. Например если на сервер ушли нажатия 1 2 3 обновлять форму только после получения ответа на последний посланный ивент.
Вообще есть еще третий вариант, посмотрите на securecanvas.com (я не стал его переводить) — абсолютно никаких задержек, запускается браузер-близнец и каждый запрос вайтлистится на лету.
> например врятли вы будете передавать события перемещения мыши
Почему нет? Раз в 0.5 секунд послать текущую позицию. Хедеры проксируются, айпи отдельным хедером можно добавить.
>И еще — получается по сети будут гоняться данные карты в обе стороны, на сервер чтобы обработать и с сервера чтобы отобразить, и это еще нужно будет сертифицировать.
Можно давать банкам ставить и на своих серверах, тогда сертифицировать не нужно будет, все останется под их контролем.
Про сложность согласен, про точки отказа и иллюзию безопасности нет. Разве такая защита от кучи 0day не стоит свеч?
node.js же как то на сервере используется? По сути тот же JS, только еще рендеринг добавить. Оценку дать не могу, тк она станет ясна только если взяться за это серьезно и все посчитать. Можно взять что то более легкое чем вебкит, хешкеш считать, капчу показывать. Для сильно нагруженных сайтов пожалуй не имеет смысла, на первом этапе. Но прогресс не стоит на месте.
Есть функция чтобы отключить ввод '"<> защитит от XSS и SQLi. Придется чем то жертвовать. Но иметь SQLi в пользов. вводе это просто неприлично дырявый вебсайт. Это не серебренная пуля, но на порядок лучше любого WAF тк основано на whitelist подходе.
> Где будет это «абсолютно» при атаке на ошибки в подключаемых библиотеках
приведите пример этих ошибок
Смотря что считать атакой. Например фишинг — это атака? Как защититься от фишинга банку если он не может банить чужие домены? Поэтому я имел ввиду атаки которые хотя бы теоретически можно предотвратить без искусственного интеллекта.
Статическая страница это не веб приложение, мы говорим о защите серверной части и данных что там хранятся. К слову даже на github pages можно найти XSS/DOM XSS. А в securecanvas намного менее вероятно, ведь урл заменять нельзя.
и в чем же ужас временного счета? Что временный что реальный расположены по одному адресу. Это как если к вам в дом пришел конверт вместо «Для жителя 23 квартиры» «для того кто заселяется в 23 квартиру». Такую минимальную ошибку просто обязаны решать банки. Или вы думали это было на их усмотрение взять и забрать ваши деньги просто так? :)
А подход изучается в мелочах а не в базовых вещах, тк все банки то работают одинаково. Этот как многие заметили блондинко-ориентированный (розовый сайт, повсюду котики даже в договорах). Не хочу сказать что он плохой но немного не то что ожидается от швейцарского банка :)
Выглядит плохо != плохо работает. Можете показать конкретные вещи которые плохо оптимизированы в этом компиляторе? Делающие Кофе существенно медленнее?
Эм окей, позвольте аналогию, можно создать веб2.0 календарик для наркомана «когда колоться а когда лучше нет» но мистер наркоман не уделит ему большого внимания. Проблема, bottle neck, находится вовсе не в способе репорта коррупции. Эти репорты никого не волнуют же.
Потому что, ешкин кот, ГОСУДАРСТВО это гниль по определению. Шайка людей захватившая народ, отнимающая у него деньги и штампующая законы. Программисты, админы и другие ребята это в первую очередь профессии, а чиновник это вор утверждающий что у него благие намерения.
опыт — CIM очень мутный банк. Рекомендую держаться от него подальше, менеджеры медленные, вопросы решаются долго, инструкций подробных не предоставляют.
Кстати для организаций с локальными системами типа CRM это отличная защита от взлома своими же сотрудниками. Нулевая задержка сети ведь и браузер и сервер в одном здании.
Упал/подвис врядли, вебсокет все же. Про реализацию не могу точно описать тк ее еще нет — можно отсылать полную строку например на onblur/onchange. Вопрос решаемый.
> Ну это тоже добавляет проблему доверия
Почему, если SC сервер является частью инфраструктуры то он вполне достоверно проксирует полученные данные, ему можно верить. Сам он читает его из реального айпи пользователя и передает bank.com уже в хедере.
>Просто по требованиям pci dss нельзя слать эти данные обратно и есть если я ввел номер карты или не дай бог cvv2 вы не можете его отправить обратно в не маскированном (номер, например VISA *6680) или ни в каком виде (для cvv).
Те нельзя через вебсокет послать дифф когда юзер печатает CC? Ок, можно сделать костыль для полей CC и не слать их назад.
>В случае банка я через такую получу доступ на выполнение кода на сервере банка.
Каждая сессия это отдельная виртуализация на сервере SC, не на сервере где сам bank.com. Они могут быть физически рядом для уменьшения network latency, но общаться будут только через HTTP. И чтобы использовать баг в вебките сначала нужно найти способ вставить свой код, те interface based XSS.
В идеале securecanvas должен использовать минимум библиотек и кода, тк от него требуется создание инстансов, работа с вебсокетами и браузерами, те обычному apache/nginx там нечего делать. Меньше кода дает все же меньше поверхность атаки.
Как раз в версии с DOM он будет показан сразу на экране, потом пошлется в облако и к тому времени как вы нажмете Submit форма в облаке будет так же заполнена. Насчет изменений инпута — сделать простенький костыль чтобы не мерцало. Например если на сервер ушли нажатия 1 2 3 обновлять форму только после получения ответа на последний посланный ивент.
Вообще есть еще третий вариант, посмотрите на securecanvas.com (я не стал его переводить) — абсолютно никаких задержек, запускается браузер-близнец и каждый запрос вайтлистится на лету.
> например врятли вы будете передавать события перемещения мыши
Почему нет? Раз в 0.5 секунд послать текущую позицию. Хедеры проксируются, айпи отдельным хедером можно добавить.
>И еще — получается по сети будут гоняться данные карты в обе стороны, на сервер чтобы обработать и с сервера чтобы отобразить, и это еще нужно будет сертифицировать.
Можно давать банкам ставить и на своих серверах, тогда сертифицировать не нужно будет, все останется под их контролем.
Про сложность согласен, про точки отказа и иллюзию безопасности нет. Разве такая защита от кучи 0day не стоит свеч?
> Где будет это «абсолютно» при атаке на ошибки в подключаемых библиотеках
приведите пример этих ошибок
Статическая страница это не веб приложение, мы говорим о защите серверной части и данных что там хранятся. К слову даже на github pages можно найти XSS/DOM XSS. А в securecanvas намного менее вероятно, ведь урл заменять нельзя.
А подход изучается в мелочах а не в базовых вещах, тк все банки то работают одинаково. Этот как многие заметили блондинко-ориентированный (розовый сайт, повсюду котики даже в договорах). Не хочу сказать что он плохой но немного не то что ожидается от швейцарского банка :)