Comments 88
С одной стороны, в заголовке пишете слово «абсолютно», с другой стороны в самом тексте же пишете «Единственное от чего SecureCanvas защитить не может». Абсолютной защиты не бывает. Как минимум есть ещё вариант угона доменного имени и подмена скриптов своими. Примерно тот же уровень безопасности с ходу дают GitHub pages — они просто отдают статическую HTML страницу. Там нечего ломать. Сложные же сайты (банки) часто и без дополнительной webkit-прослойки тормозят…
Смотря что считать атакой. Например фишинг — это атака? Как защититься от фишинга банку если он не может банить чужие домены? Поэтому я имел ввиду атаки которые хотя бы теоретически можно предотвратить без искусственного интеллекта.
Статическая страница это не веб приложение, мы говорим о защите серверной части и данных что там хранятся. К слову даже на github pages можно найти XSS/DOM XSS. А в securecanvas намного менее вероятно, ведь урл заменять нельзя.
Статическая страница это не веб приложение, мы говорим о защите серверной части и данных что там хранятся. К слову даже на github pages можно найти XSS/DOM XSS. А в securecanvas намного менее вероятно, ведь урл заменять нельзя.
Где будет это «абсолютно» при SQL инъекции при некорректной обработке пользовательского ввода? Где будет это «абсолютно» при атаке на ошибки в подключаемых библиотеках. Серебряной пули не существует!
Есть функция чтобы отключить ввод '"<> защитит от XSS и SQLi. Придется чем то жертвовать. Но иметь SQLi в пользов. вводе это просто неприлично дырявый вебсайт. Это не серебренная пуля, но на порядок лучше любого WAF тк основано на whitelist подходе.
> Где будет это «абсолютно» при атаке на ошибки в подключаемых библиотеках
приведите пример этих ошибок
> Где будет это «абсолютно» при атаке на ошибки в подключаемых библиотеках
приведите пример этих ошибок
SQLi можно провести без использования кавычек, ровно как и XSS вектор не обязательно будет содержать символы <>.
А можно реалистичные сценарии, на основе интерфейса? Понятно что есть еще javascript: ссылки, но большинство XSS/SQLi зависят именно от набора '"<>. Цель технологии защита от изменений запросов и сложных 0day, а не от того что кто то *очевидный* юзер инпут не может проверить.
Есть запрос:
Вместо ??? ставим «100500 UNION SELECT username, password FROM users», получаем:
Кавычки не понадобились.
SELECT title, body FROM posts WHERE id = ???;Вместо ??? ставим «100500 UNION SELECT username, password FROM users», получаем:
SELECT title, body FROM posts WHERE id = 100500 UNION SELECT username, password FROM users;Кавычки не понадобились.
Как этот запрос связан с интерфейсом? В инпуты не вводят id, в инпуты вводят текстовые атрибуты.
Да какая разница? Пускай это будет не ID, а год публикации поста. Что это меняет?
SELECT title, body FROM posts WHERE year = 100500 UNION SELECT username, password FROM users;Это уже более вероятно, но незначительно редко (да и кто вручную ставит год публикации). Обычно используют кавычки или ORM. Куда чаще SQLi закрадывается в скрытый тэг, дропдаун или сортировку, с чем мы и боремся. Вот пример rails-sqli.org/ — там от интерфейса ничего не зависит.
Все равно задержки будут адовые, любой символ который я ввожу прежде чем быть отображен должен быть обработан webkit'ом возможно даже на другой стороне нашего шарика, а потом мне должны придти изменения dom (в каком виде кстати? тотже ввод значения не меняет dom а меняет свойство)
Взаимодействие с пользователем будет ограничено (например врятли вы будете передавать события перемещения мыши), банку нужно будет еще как-то данные об айпи и т.п. пользователя передавать, языке и т.п.
Ну и накладные расходы на запущенные вебкиты — для крупного процессинга это тысячи одновременных сессий вебкита
И еще — получается по сети будут гоняться данные карты в обе стороны, на сервер чтобы обработать и с сервера чтобы отобразить, и это еще нужно будет сертифицировать.
В общем это добавляет сложности, точек отказа, а также возможно иллюзию безопасности, так что я бы поставил "-"
Взаимодействие с пользователем будет ограничено (например врятли вы будете передавать события перемещения мыши), банку нужно будет еще как-то данные об айпи и т.п. пользователя передавать, языке и т.п.
Ну и накладные расходы на запущенные вебкиты — для крупного процессинга это тысячи одновременных сессий вебкита
И еще — получается по сети будут гоняться данные карты в обе стороны, на сервер чтобы обработать и с сервера чтобы отобразить, и это еще нужно будет сертифицировать.
В общем это добавляет сложности, точек отказа, а также возможно иллюзию безопасности, так что я бы поставил "-"
> Все равно задержки будут адовые, любой символ который я ввожу прежде чем быть отображен должен быть обработан webkit'ом возможно даже на другой стороне нашего шарика
Как раз в версии с DOM он будет показан сразу на экране, потом пошлется в облако и к тому времени как вы нажмете Submit форма в облаке будет так же заполнена. Насчет изменений инпута — сделать простенький костыль чтобы не мерцало. Например если на сервер ушли нажатия 1 2 3 обновлять форму только после получения ответа на последний посланный ивент.
Вообще есть еще третий вариант, посмотрите на securecanvas.com (я не стал его переводить) — абсолютно никаких задержек, запускается браузер-близнец и каждый запрос вайтлистится на лету.
> например врятли вы будете передавать события перемещения мыши
Почему нет? Раз в 0.5 секунд послать текущую позицию. Хедеры проксируются, айпи отдельным хедером можно добавить.
>И еще — получается по сети будут гоняться данные карты в обе стороны, на сервер чтобы обработать и с сервера чтобы отобразить, и это еще нужно будет сертифицировать.
Можно давать банкам ставить и на своих серверах, тогда сертифицировать не нужно будет, все останется под их контролем.
Про сложность согласен, про точки отказа и иллюзию безопасности нет. Разве такая защита от кучи 0day не стоит свеч?
Как раз в версии с DOM он будет показан сразу на экране, потом пошлется в облако и к тому времени как вы нажмете Submit форма в облаке будет так же заполнена. Насчет изменений инпута — сделать простенький костыль чтобы не мерцало. Например если на сервер ушли нажатия 1 2 3 обновлять форму только после получения ответа на последний посланный ивент.
Вообще есть еще третий вариант, посмотрите на securecanvas.com (я не стал его переводить) — абсолютно никаких задержек, запускается браузер-близнец и каждый запрос вайтлистится на лету.
> например врятли вы будете передавать события перемещения мыши
Почему нет? Раз в 0.5 секунд послать текущую позицию. Хедеры проксируются, айпи отдельным хедером можно добавить.
>И еще — получается по сети будут гоняться данные карты в обе стороны, на сервер чтобы обработать и с сервера чтобы отобразить, и это еще нужно будет сертифицировать.
Можно давать банкам ставить и на своих серверах, тогда сертифицировать не нужно будет, все останется под их контролем.
Про сложность согласен, про точки отказа и иллюзию безопасности нет. Разве такая защита от кучи 0day не стоит свеч?
Как раз в версии с DOM он будет показан сразу на экране
А как тогда это будет синхронизироваться? то есть один запрос упал, подвис и т.п.
Хедеры проксируются
Ну это тоже добавляет проблему доверия — так как в tcp данным об айпи более менее верить можно, а вот кто именно и как указал хедер непонятно, ну и нужно будет доработать антифрод чтобы он верил тогда этим заголовкам.
Можно давать банкам ставить и на своих серверах, тогда сертифицировать не нужно будет, все останется под их контролем.
Я в принципе и имел ввиду это, просто если вы сам софт не сертифицируете то банкам придется делать это в рамках конкретной инсталяции с нуля.
Просто по требованиям pci dss нельзя слать эти данные обратно и есть если я ввел номер карты или не дай бог cvv2 вы не можете его отправить обратно в не маскированном (номер, например VISA *6680) или ни в каком виде (для cvv).
Про сложность согласен, про точки отказа и иллюзию безопасности нет. Разве такая защита от кучи 0day не стоит свеч?
Это доп. компонента, поэтому это доп. точка отказа.
Разве в webkit не существует уязвимостей или 0day? В случае банка я через такую получу доступ на выполнение кода на сервере банка.
>А как тогда это будет синхронизироваться? то есть один запрос упал, подвис и т.п.
Упал/подвис врядли, вебсокет все же. Про реализацию не могу точно описать тк ее еще нет — можно отсылать полную строку например на onblur/onchange. Вопрос решаемый.
> Ну это тоже добавляет проблему доверия
Почему, если SC сервер является частью инфраструктуры то он вполне достоверно проксирует полученные данные, ему можно верить. Сам он читает его из реального айпи пользователя и передает bank.com уже в хедере.
>Просто по требованиям pci dss нельзя слать эти данные обратно и есть если я ввел номер карты или не дай бог cvv2 вы не можете его отправить обратно в не маскированном (номер, например VISA *6680) или ни в каком виде (для cvv).
Те нельзя через вебсокет послать дифф когда юзер печатает CC? Ок, можно сделать костыль для полей CC и не слать их назад.
>В случае банка я через такую получу доступ на выполнение кода на сервере банка.
Каждая сессия это отдельная виртуализация на сервере SC, не на сервере где сам bank.com. Они могут быть физически рядом для уменьшения network latency, но общаться будут только через HTTP. И чтобы использовать баг в вебките сначала нужно найти способ вставить свой код, те interface based XSS.
Упал/подвис врядли, вебсокет все же. Про реализацию не могу точно описать тк ее еще нет — можно отсылать полную строку например на onblur/onchange. Вопрос решаемый.
> Ну это тоже добавляет проблему доверия
Почему, если SC сервер является частью инфраструктуры то он вполне достоверно проксирует полученные данные, ему можно верить. Сам он читает его из реального айпи пользователя и передает bank.com уже в хедере.
>Просто по требованиям pci dss нельзя слать эти данные обратно и есть если я ввел номер карты или не дай бог cvv2 вы не можете его отправить обратно в не маскированном (номер, например VISA *6680) или ни в каком виде (для cvv).
Те нельзя через вебсокет послать дифф когда юзер печатает CC? Ок, можно сделать костыль для полей CC и не слать их назад.
>В случае банка я через такую получу доступ на выполнение кода на сервере банка.
Каждая сессия это отдельная виртуализация на сервере SC, не на сервере где сам bank.com. Они могут быть физически рядом для уменьшения network latency, но общаться будут только через HTTP. И чтобы использовать баг в вебките сначала нужно найти способ вставить свой код, те interface based XSS.
«это как сайт внутри АТМ, под защитным экраном»
Больше похоже на видео-трансляцию с АТМ подключающейся к сайту )
Не увидел у вас в статье оценок необходимой вычислительной мощности, но то что её потребуется много — очевидно.
Сразу напрашивается уязвимость к DDoS, с которым в вашей схеме будет очень трудно бороться.
node.js же как то на сервере используется? По сути тот же JS, только еще рендеринг добавить. Оценку дать не могу, тк она станет ясна только если взяться за это серьезно и все посчитать. Можно взять что то более легкое чем вебкит, хешкеш считать, капчу показывать. Для сильно нагруженных сайтов пожалуй не имеет смысла, на первом этапе. Но прогресс не стоит на месте.
Вам вообще на сервере «браузер» и рендерер не нужны, только DOM, с которого diff-ы шлются. И DOM тоже очень упрощённый, так как можно смело игнорировать стили, не пересчитывать размеры элементов и т. п.
Абсолютно безопасных сайтов не существует. Даже голый html-сайт можно поломать, например найдя уязвимость на сервере.
А здесь такой огромный костыль, который может спасти только от некоторых типов атак.
А здесь такой огромный костыль, который может спасти только от некоторых типов атак.
Я не удержался от использования «абсолютно безопасный» как маркетинговой удочки. В глобальном смысле конечно таких нет. А если менее строго судить то даже OWASPовский damn insecure app станет намного безопасней. И «может спасти только от некоторых типов атак» наоборот — только некоторые типы атак (связанные с интерфейсом) не может предотвратить. Атаки типа фишинга/доса, как сказано выше, я не учитывал
UFO just landed and posted this here
Я правильно понимаю, что если получить доступ к SecureCanvas серверу, то дальше всё будет аналогично первой картинке, когда взаимодействие ведётся непосредственно из браузера? Т.е. фактически вводится ещё один элемент с неизвестным уровнем безопасности?
В каком плане получить доступ к серверу? Каждый сервер создается только для сессии и сразу уничтожается. Если имеется ввиду получить доступ к выполнению кода JS (XSS) то да, понять чей код будет нельзя и он сможет обойти защиту для большинства векторов (кроме тех что не выполнимы в JS, например heartbleed). Если доступ вообще к экосистеме securecanvas то это глобальный MITM всех загружаемых сайтов. Оно, конечно, плохо — но Cloudflare уже давно находится в этой позиции и контролирует кучу сайтов, и это никого не пугает.
В идеале securecanvas должен использовать минимум библиотек и кода, тк от него требуется создание инстансов, работа с вебсокетами и браузерами, те обычному apache/nginx там нечего делать. Меньше кода дает все же меньше поверхность атаки.
В идеале securecanvas должен использовать минимум библиотек и кода, тк от него требуется создание инстансов, работа с вебсокетами и браузерами, те обычному apache/nginx там нечего делать. Меньше кода дает все же меньше поверхность атаки.
Мало того неизвестным, так еще и все клики и нажатия клавиш (включая ввод паролей) передаются третьей стороне. Отличная перспектива — кейлоггер by design.
«сайт грузится в виртуальном и дешевом инстансе webkit в облаке» — а почему этот инстанс не поднять в виртуалке локально? Монетизация не та?
А, это защита сервера от пользователя. То есть по сути отказ от протокола HTTP в пользу своего протокола, условно назовем его diff-DOM. То есть от подмены клиента, подделывающего diff-DOM это не спасет. А в таком случае не понятно, чем HTTP не угодил.
[клиент]-/diff-dom/-[неуязвимый преобразователь из diff-dom в http]-/http/-[уязвимый бэкенд]
Не очень понятно, чем это лучше
[клиент]-/http/-[неуязвимый фронтэнд]-/http/-[уязвимый бэкенд]
[клиент]-/diff-dom/-[неуязвимый преобразователь из diff-dom в http]-/http/-[уязвимый бэкенд]
Не очень понятно, чем это лучше
[клиент]-/http/-[неуязвимый фронтэнд]-/http/-[уязвимый бэкенд]
Лучше тем, что прячется вся JS-логика и весь обмен доп. данными с сервером. Очень сложно выстроить атаку, имея только возможность кликать по элементам. Но да, mitm, подменяющий DOM-фреймы и получающий логины-пароли всё ещё возможен.
MITM внутри secure websocket? В этом случае в diff можно и JS произвольный засунуть, но реалистична ли эта атака.
Ну то есть мы возвращаемся к старой доброй концепции «логика на сервере, который возвращает статику и общается через тег form», а суть заключается в том, что клиент-серверный протокол слишком беден, чтобы сотворить зло. Если sql-инъекцию реально забить в поля формы (имя пользователя:user; drop database users), то это не поможет.
Только вместо http с его полной отдачей html мы возвращаем дифф между новым состоянием страницы и старым, а на сервере место php для рендера используется какой-нибудь angular.js в виде еще одной прослойки. Сурово.
Не понятна цель, если цель писать банк-клиенты, почему не ограничиться статикой без ajax-красивостей, тогда узкое место будет там же — в параметрах принимаемых форм.
Только вместо http с его полной отдачей html мы возвращаем дифф между новым состоянием страницы и старым, а на сервере место php для рендера используется какой-нибудь angular.js в виде еще одной прослойки. Сурово.
Не понятна цель, если цель писать банк-клиенты, почему не ограничиться статикой без ajax-красивостей, тогда узкое место будет там же — в параметрах принимаемых форм.
>Не понятна цель, если цель писать банк-клиенты, почему не ограничиться статикой без ajax-красивостей, тогда узкое место будет там же — в параметрах принимаемых форм.
цель защититься от уязвимостей по типу Shellshock или Rails RCE что была два года назад. Это баги фреймворка, и даже при системе основанной на формах фреймворк открыт для кучи атак. Ну а разрабатывать без фреймворка еще хуже выйдет.
цель защититься от уязвимостей по типу Shellshock или Rails RCE что была два года назад. Это баги фреймворка, и даже при системе основанной на формах фреймворк открыт для кучи атак. Ну а разрабатывать без фреймворка еще хуже выйдет.
Что значит подмена клиента подделывающего diff-DOM?
Неуязвимый фронтенд это что? Передача кликов по HTTP будет слишком медленной, поэтому кроме вебсокета ничего не рассматривается. Ну и задача чтобы работало из-коробки.
Неуязвимый фронтенд это что? Передача кликов по HTTP будет слишком медленной, поэтому кроме вебсокета ничего не рассматривается. Ну и задача чтобы работало из-коробки.
Система может ставиться и локально в сети банка и предоставляться как сервис (как cloudflare)
Кстати для организаций с локальными системами типа CRM это отличная защита от взлома своими же сотрудниками. Нулевая задержка сети ведь и браузер и сервер в одном здании.
Кстати для организаций с локальными системами типа CRM это отличная защита от взлома своими же сотрудниками. Нулевая задержка сети ведь и браузер и сервер в одном здании.
Делал похожую штуку, только с другой целью: защита пользователя от сайта. Программа представляет собой веб-прокси, написанный на Wt, в котором крутится вебкит в Qt. Сайт переводится в картинку PNG и в таком виде отправляется в настоящий браузер. События мыши и клавиатуры с клиента летят на сервер и переводятся в события Qt. Есть кнопочка для отображения безопасных частей страницы в виде текста (чтобы можно было скопировать).
Если зашить фиксированный URL и немного доработать, то будет как раз то, о чем вы говорите. Предупреждаю, что это прототип. Более дешевым решением вашей задачи является белый список паттернов запросов, который можно построить и применить при помощи nginx и naxsi.
Если зашить фиксированный URL и немного доработать, то будет как раз то, о чем вы говорите. Предупреждаю, что это прототип. Более дешевым решением вашей задачи является белый список паттернов запросов, который можно построить и применить при помощи nginx и naxsi.
Штуку посмотрю, но картинки в PNG не катят из за качества.
А как построить по настоящему умный белый список? Он ведь изменяется постоянно. Посмотрите 3 вариант на securecanvas.com — там как раз белый список запросов с помощью браузера-близнеца.
А как построить по настоящему умный белый список? Он ведь изменяется постоянно. Посмотрите 3 вариант на securecanvas.com — там как раз белый список запросов с помощью браузера-близнеца.
Качество картинки конечно не идеальное, но если не вглядываться, то и не заметишь, это всё-таки не JPEG :)
Можно доработать подход с чисткой HTML и сделать DOM-диффы, которыми и общаться с клиентом. Впрочем, если вы защищаете сайт, а не пользователя, то можно не чистить HTML, а просто брать диффы.
Можно доработать подход с чисткой HTML и сделать DOM-диффы, которыми и общаться с клиентом. Впрочем, если вы защищаете сайт, а не пользователя, то можно не чистить HTML, а просто брать диффы.
А как построить по настоящему умный белый список? Он ведь изменяется постоянно.Добавили на сайт новую функциональность, протестировали, параллельно автоматически дополнили правила белого списка.
Под умным списком я подразумеваю юзер с id=1 не может загрузить /private_data/2 а только /private_data/1. Или то что юзер не может поставить другой контент тайп. Такие вещи невозможно предугадать, а более гибкий список пропустит кучу векторов.
Это уже будет не умный список, а искусственный интеллект. Правила naxsi помогают отрезать принципиально отличающиеся запросы, например эксплойты к веб-приложению. А правило о том, что юзеры не могут смотреть приватные данные друг друга, должны составлять люди (разработчики веб-приложения и конфигурации веб-сервера или тестировщики), а не роботы, я так думаю.
А как бороться с тем, что отображение шрифтов на клиенте и сервере разное?
>Но эта идея обречена на провал — качество картинки сильно ухудшается, шрифты смазываются и задержка сети пользователям сильно не понравится
Можно передавать команды рендеру а-ля X. Думаю, в webkit можно вытащить протокол уже непосредственно отрисовки примитивов. То есть порезать webkit на клиент и сервер не на уровне DOM, а на уровне плоской канвы, кэшируя изображения и прочее. Порезать webkit должно быть попроще, мне кажется.
Можно передавать команды рендеру а-ля X. Думаю, в webkit можно вытащить протокол уже непосредственно отрисовки примитивов. То есть порезать webkit на клиент и сервер не на уровне DOM, а на уровне плоской канвы, кэшируя изображения и прочее. Порезать webkit должно быть попроще, мне кажется.
$ GDK_BACKEND=broadway epiphany http://habrahabr.ru/post/248761/Открываем 127.0.0.1:8080 и радуемся.
(epiphany-browser:xxxx): Gdk-ERROR **: Unsupported GDK backend: broadway
Trace/breakpoint trap
Trace/breakpoint trap
Какой версии у вас GTK? Собран ли он с опцией
--enable-broadway-backend?GTK 3.4.2-7. Дебиан стабильный.
Не знаю, как проверить, был ли он собран с опцией --enable-broadway-backend. В папке debian/ пакета с исходниками broadway не упоминается, поэтому думаю, что не было этой опции.
Не знаю, как проверить, был ли он собран с опцией --enable-broadway-backend. В папке debian/ пакета с исходниками broadway не упоминается, поэтому думаю, что не было этой опции.
В Debian'е, как я понимаю, обещают эту штуку начиная с 3.9.14-1, но в stable последний 3.4.2-7. Можете попробовать взять его из testing, там сейчас лежит 3.14.5-1. Либо пересобрать свой 3.4.2, хотя не знаю, насколько это на дебиане реально…
Надо ковырять сам вебкит, чтобы понять, как удобнее. По сути у вас задача разрезать вебкит на клиент и сервер.
На сервере ТОЧНО выполняется js. На клиенте ТОЧНО выводится картинка и собираются команды клавиатуры и мышки.
А дальше начинаются частности по выбору толщины клиента и сервера. Если передавать картинку прямоугольниками — получается VNC и тончайший клиент, если передавать DOM — получается ваша вторая идея и самый толстый клиент. А можно отсоединить рендер от собственно тела браузера с помощью remote procedure call. То есть там где есть команда «вывести текст по координатам» ее можно заменить на «вывести текст по координатам удаленно» и так для каждого примитива рисования. Где-то тут github.com/WebKit/webkit/tree/master/Source/WebCore/rendering непосредственные вызовы графического API должны быть заменены на протокольные команды. Из-за того, что передаваемые данные уменьшатся по сравнению с VNC, будет работать шустрее, но при этом не потребуется реализовывать сложную систему модификации DOM, по сути имея 2 браузера и сложный протокол.
То есть команды протокола — «вывести текст по координатам x,y», «вывести изображение N по координатам x,y» и т. п. Картинка, например, шлется один раз уже в нужном масштабе и кэшируется.
На сервере ТОЧНО выполняется js. На клиенте ТОЧНО выводится картинка и собираются команды клавиатуры и мышки.
А дальше начинаются частности по выбору толщины клиента и сервера. Если передавать картинку прямоугольниками — получается VNC и тончайший клиент, если передавать DOM — получается ваша вторая идея и самый толстый клиент. А можно отсоединить рендер от собственно тела браузера с помощью remote procedure call. То есть там где есть команда «вывести текст по координатам» ее можно заменить на «вывести текст по координатам удаленно» и так для каждого примитива рисования. Где-то тут github.com/WebKit/webkit/tree/master/Source/WebCore/rendering непосредственные вызовы графического API должны быть заменены на протокольные команды. Из-за того, что передаваемые данные уменьшатся по сравнению с VNC, будет работать шустрее, но при этом не потребуется реализовывать сложную систему модификации DOM, по сути имея 2 браузера и сложный протокол.
То есть команды протокола — «вывести текст по координатам x,y», «вывести изображение N по координатам x,y» и т. п. Картинка, например, шлется один раз уже в нужном масштабе и кэшируется.
А быстро ли получится эти команды в js выполнять? То что вебкит делится на две части верно сказано.
Какие команды в js? Из сервера идет поток «рисуй прямоугольник тут, выводи текст здесь, сюда картинка», с клиента — «кликнул сюда, напечатал на клавиатуре то-то». А на сервере уже js крутится точно так же, как крутился бы в браузере. Для банковских интерфейсов должно шустро бегать.
По прототипам — создаешь прототип и идешь к инвестору уже на нормальный проект, а потом уже к банкам. Просто под идею никто денег не даст — желателен прототип и команда. Прототип того что я говорю реально сделать быстро (надо посмотреть в сторону браузеров на xwindows, может дело вообще еще проще), насчет DOM неуверен.
По прототипам — создаешь прототип и идешь к инвестору уже на нормальный проект, а потом уже к банкам. Просто под идею никто денег не даст — желателен прототип и команда. Прототип того что я говорю реально сделать быстро (надо посмотреть в сторону браузеров на xwindows, может дело вообще еще проще), насчет DOM неуверен.
Мне кажется сложные навороты с облаком для этого не нужны. Нужен фреймворк, на подобии meteor, который все, что есть внутри window.document обернет в ws-общение. Тогда логика полностью останется на сервере, а клиент всего лишь будет вызывать нужные функции с нужными аргументами. Если метеор уже не делает этого.
Это делает привязку к платформе. А задача сделать штуку не нуждающуюся в конфигурации.
Так у тебя ровно та же привязка к платформе. Ты хочешь сделать облако, в котором JS будет взаимодействовать с бэкендом.
Ну и API к JS можно представить на любом языке. Я предлагаю document перенести на сервер
Ну и API к JS можно представить на любом языке. Я предлагаю document перенести на сервер
>осталось решить вопрос с … инвестициями — нам они очень нужны
В этом проблема очень большого количества перспективных стартаперов: вам не нужны инвестиции, чтобы начать делать стартап. Минимальный прототип почти любого стартапа собирается на коленке за пару месяцев, если работать только над ним. Это можно делать даже без отрыва от работы (отпуск + отпуск за свой счёт + праздники), была бы цель и желание. Человек от бизнеса, да, вам будет крайне полезен для упрощения получения фидбека и тестовых внедрений, но даже оно не обязательно. Пора уже взрослеть: вы сами уже ответственны за своё будущее, а не родители/инвесторы.
Инвестиции на этапе непроверенного прототипа — зло, ввиду обязанностей перед инвесторами вынуждающее вас не делать, например, pivot там, где близкая ниша может оказаться гораздо более перспективной.
Альтернативный вариант, если вы говорите, что вы не стартапер, а крутой специалист, и вам будет интересно делать такой проект за зарплату. Это будет гораздо честнее, и повысит шансы на старт проекта.
В этом проблема очень большого количества перспективных стартаперов: вам не нужны инвестиции, чтобы начать делать стартап. Минимальный прототип почти любого стартапа собирается на коленке за пару месяцев, если работать только над ним. Это можно делать даже без отрыва от работы (отпуск + отпуск за свой счёт + праздники), была бы цель и желание. Человек от бизнеса, да, вам будет крайне полезен для упрощения получения фидбека и тестовых внедрений, но даже оно не обязательно. Пора уже взрослеть: вы сами уже ответственны за своё будущее, а не родители/инвесторы.
Инвестиции на этапе непроверенного прототипа — зло, ввиду обязанностей перед инвесторами вынуждающее вас не делать, например, pivot там, где близкая ниша может оказаться гораздо более перспективной.
Альтернативный вариант, если вы говорите, что вы не стартапер, а крутой специалист, и вам будет интересно делать такой проект за зарплату. Это будет гораздо честнее, и повысит шансы на старт проекта.
Прототип запилить самому не проблема. Но 1 — как продать это банка, 2 — банкам нужна красивая штука а не кривой прототип чтобы они захотели использовать.
Посмотрите на шейп там ссылка есть. Я эту технологию за вечер написал на rack middleware, но 66 млн там совсем на другое выделены. Да и деньги нужны на крутого спеца вебкита. Я в веб секурити понимаю и знаю что нужно сделать а не как.
Посмотрите на шейп там ссылка есть. Я эту технологию за вечер написал на rack middleware, но 66 млн там совсем на другое выделены. Да и деньги нужны на крутого спеца вебкита. Я в веб секурити понимаю и знаю что нужно сделать а не как.
«Красивая штука» — не более чем способ презентации. Банкам, как и любому бизнесу, нужно решение проблем. Людям, принимающим решения, нужно решение проблем в их понимании. Прототип вполне может этим быть — всё зависит от презентации и того, кто её смотрит. Специалист по вебкиту нужен, чтобы сделать идеально, что совершенно не обязательно для принятия решения о внедрении.
Кстати, я бы на вашем месте начал не с банков, а с агрегаторов платежей и им подобных.
Кстати, я бы на вашем месте начал не с банков, а с агрегаторов платежей и им подобных.
XWindow изобретаете?
Вы тут напомнили тех редисок что отключают ПКМ и копирование текста в браузере используя JS. От этого только еще больше хочется этот самый текст скопировать и в сырцы заглянуть.
В вашем случае такой сайт будет просто жутко неудобен для пользования и в результатах поиска у ПС он по всей видимости вообще будет отсутствовать. Если же разрешать ПС ходить на сайт прямо, то скоро пользователи будут читать ваш сайт из кэша ПС.
В вашем случае такой сайт будет просто жутко неудобен для пользования и в результатах поиска у ПС он по всей видимости вообще будет отсутствовать. Если же разрешать ПС ходить на сайт прямо, то скоро пользователи будут читать ваш сайт из кэша ПС.
Жду следующей статьи под названием: «Браузер-в-браузере-в-браузере сделает сайт намного безопасней»
Блин, ну у вас и проблемы, ребятки.
Атаки на стороне клиента, не отказываясь от DOM, вы избежать не сможете.
Да и не факт, что в вашем клиенте дыры не вскроются внезапно.
Атаки на стороне клиента, не отказываясь от DOM, вы избежать не сможете.
Да и не факт, что в вашем клиенте дыры не вскроются внезапно.
UFO just landed and posted this here
Во первых сервис можно поставить на своем сервере, во вторых cloudflare так и работает.
И что, где написано что они не могут читать трафик между сайтом и сервером? Любой WAF SaaS так работает и больше никак
вот картинка:
blog.cloudflare.com/content/images/2014/Sep/illustration-keyless-ssl-explained-01.png
получается что разница только в том что они не хранят приватный ключ, для этого используется специальный key server который дешифровывает для них сообщения на этапе рукопожатия, содержимое запросов как я понял они после этого видят
blog.cloudflare.com/content/images/2014/Sep/illustration-keyless-ssl-explained-01.png
получается что разница только в том что они не хранят приватный ключ, для этого используется специальный key server который дешифровывает для них сообщения на этапе рукопожатия, содержимое запросов как я понял они после этого видят
Непонятна суть затеи.
Защитить это сможет компьютер пользователя. Не его учетные данные.
Та-же, хранимая XSS отработает в любом случае и заберёт все нужные ей данные.
CSRF тоже отработает.
То-есть защита будет работать для пользователя только от атак компромитирующих его систему через уязвимости в браузере и опутствующих приложениях.
Хотя подозреваю что в неких случаях могут быть скомпрометированны облачная система и пользовательская одновременно. Или же пользовательская в обход облака…
Защитить это сможет компьютер пользователя. Не его учетные данные.
Та-же, хранимая XSS отработает в любом случае и заберёт все нужные ей данные.
CSRF тоже отработает.
То-есть защита будет работать для пользователя только от атак компромитирующих его систему через уязвимости в браузере и опутствующих приложениях.
Хотя подозреваю что в неких случаях могут быть скомпрометированны облачная система и пользовательская одновременно. Или же пользовательская в обход облака…
Суть затеи — в том, чтобы не дать хакеру посмотреть на HTTP-запросы. Хотя выше уже написали, что точно так же можно подделывать и запросы по внутреннему протоколу, так что польза от такой защиты сомнительна.
> что точно так же можно подделывать и запросы по внутреннему протоколу
Ну и как же подделать запросы которые представляют из себя «двинуть мышь» и «напечатать букву»?
Ну и как же подделать запросы которые представляют из себя «двинуть мышь» и «напечатать букву»?
>Та-же, хранимая XSS отработает в любом случае и заберёт все нужные ей данные.
если только XSS через интерфейс
>CSRF тоже отработает.
CSRF не сработает, нельзя загрузить чужой урл или делать пост запросы.
Пользователя никто тут не защищает, защищают сервер сайд.
если только XSS через интерфейс
>CSRF тоже отработает.
CSRF не сработает, нельзя загрузить чужой урл или делать пост запросы.
Пользователя никто тут не защищает, защищают сервер сайд.
Sign up to leave a comment.
Браузер-в-браузере сделает сайт намного безопасней