LINUX.ORG.RU

Как зафиксировать версию веб-приложения?

 , ,


0

2

Думаю сделать сервис, который будет с помощью JS шифровать данные. Сервер их будет получать зашифрованными и расшифровать не может, ключ у пользователя. Исходники JS будут доступны для изучения.

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

С обычном софтом такая проблема решается отключением автообновлений, проверкой контрольных сумм скачанных бинарников. Но «веб-приложение» штука гибкая и в части безопасности такая гибкость только вредит.

В целом ничего не мешает считать хеш от HTML-страницы и всех загруженных JavaScript-файлов и если он не совпал с последним посещением, то предупреждать пользователя. Можно использовать более сложную систему верификации, но суть такая. Естественно это делать должен плагин для браузера (в браузере вроде таких стандартов нет).

Вопрос такой — есть ли какой-нибудь стандартный плагин для таких целей? Может быть есть другой способ решить эту задачу? Собственно задача в том, чтобы пользователи обоснованно доверяли такому веб-приложению. Как решают эту проблему доверия другие веб-приложения, осуществляющие шифрование на стороне клиента?

★★★★★

Как зафиксировать версию веб-приложения?

да никак это не решается программно, можно найти всегда обходной путь

доверяют обычно брендам, сервисам, а не тому что там на сервере установлено

umren ★★★★★ ()

Нужно не пользоваться JS и веб-приложениями, а писать нативный софт

Harald ★★★★★ ()

это была прикольная плюшка для NoScript/AdBlock - отключать скрипты вайтлиста, если они изменились с момента включения.

зы. может оно там и есть

dib2 ★★★★★ ()
Ответ на: комментарий от proud_anon

Для прояснения — я не делаю хостинг файлов, но сути это не меняет. Есть данные, с которыми работает пользователь, которые хранятся в облаке, но облако про них ничего не знает.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

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

Dantix ★★ ()

Есть тупой способ идентификации машины по конфигурации железа машины (серийников hdd и тп.) Дурацкий конечно, но действенный. Использует в таможенных декларантах и банковских клиентах на foxpro.

hbars ★★★★★ ()
Ответ на: комментарий от Legioner

Есть данные, с которыми работает пользователь, которые хранятся в облаке, но облако про них ничего не знает.

Проблема в том, что если пользователю действительно нужно шифрование, он не будет доверять твоему веб-приложению, он свои данные у себя отредактирует, а если и будет хранить на чужих серверах, то уже зашифрованными. Если пользователю не нужно шифрование или нужно только честное слово, что оно есть, то не надо ничего фиксировать, просто пообещай, что не будешь пароль воровать.

proud_anon ★★★★★ ()
Последнее исправление: proud_anon (всего исправлений: 1)
Ответ на: комментарий от proud_anon

Проблема в том, что если пользователю действительно нужно шифрование, он не будет доверять твоему веб-приложению, он свои данные у себя отредактирует, а если и будет хранить на чужих серверах, то уже зашифрованными. Если пользователю не нужно шифрование или нужно только честное слово, что оно есть, то не надо ничего фиксировать, просто пообещай, что не будешь пароль воровать.

Почему ты так считаешь? Пользователь же не в уме будет шифровать. Будет запускать софт. openssl или gpg или что-нибудь ещё. Чем он хуже софта в браузере?

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Будет запускать софт. openssl или gpg или что-нибудь ещё. Чем он хуже софта в браузере?

Тем, что, как ты и сказал, софт в браузере гораздо сложнее «зафиксировать», чем нормальный софт. И хотя ты собрался решать эту проблему, во-первых, проще использовать софт, в котором её просто нет (то есть не браузерный), а во-вторых, если ты сейчас и изобретёшь способ, то пройдут годы, прежде чем ему будут в достаточной степени доверять безопасники. Готовых решений я лично не знаю.

Тем более, что основной плюс софта в браузере — автоматическое и прозрачное обновление, а ты его собрался отключить. Если тебе просто нужна среда с HTML + CSS + Javascript, может, взять какой-нибудь Chromium Embedded Framework?

Или речь идёт о реально долгосрочных перспективах и «разработать собственный сложный плагин для браузера» — это в принципе нормальное решение?

proud_anon ★★★★★ ()
Ответ на: комментарий от Legioner

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

deep-purple ★★★★★ ()
Ответ на: комментарий от proud_anon

Тем более, что основной плюс софта в браузере — автоматическое и прозрачное обновление, а ты его собрался отключить.

Основной плюс браузера я считаю в скорости доступа. Установка приложения это в лучшем случае минута, если оно есть в репозитории и 2-5 минут на оффтопик платформах. Открытие веб-приложения это несколько секунд максимум.

Обновление я отключать не собираюсь, это глупо. Ты же не отключаешь обновления openssl. Я хочу сделать так, чтобы пользователь мог понять тот факт, что приложение обновилось, перейти по URL-у, почитать описание обновления, сверить чексуммы. Теоретически можно сделать поддержку версионности и возможность использовать старую версию. Но это всё будет работать только при условии, что пользователь контролирует свой браузер и тот код, который в нём выполняется.

За наводку на NoScript спасибо, может и вправду у них есть что-нибудь на эту тему.

Если тебе просто нужна среда с HTML + CSS + Javascript, может, взять какой-нибудь Chromium Embedded Framework?

Нет, без браузера весь смысл теряется.

Или речь идёт о реально долгосрочных перспективах и «разработать собственный сложный плагин для браузера» — это в принципе нормальное решение?

Тут скорее «разработать собственный плагин для всех популярных браузеров» :) Надеюсь до этого не дойдёт.

Legioner ★★★★★ ()

https://clipperz.is/security_privacy/security_code_review/ вот похожий проект описывает похожую проблему.

Они решили её просто. Они дают пользователю один HTML файл без внешних зависимостей и публикуют контрольную сумму на сайте. Пользователь может скачать index.html с помощью CURL-а и проверить контрольную сумму, используя обычные инструменты. Кроме того (вроде бы) можно открыть index.html с диска и работать.

В принципе решение понятное, хотя и далеко от идеала. Проект старый, раз ничего лучше не советуют, видимо ничего лучше и нет.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Ну так в первый раз когда нету хешсумм, то пусть кладет свой ядерный жс-скрипт в кеш/сторадж, его и юзает для всех последующих запросов. Или - писать аддон, в который вшиты эти ядерные либы, ну тогда уже и не жс можно.

deep-purple ★★★★★ ()

Есть такая возможность. Greasemonkey называется.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Dantix

Кстати, да. Простое решение. Все равно у всех есть либо apache, либо nginx.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Legioner

Кроме того (вроде бы) можно открыть index.html с диска и работать.

Тогда при разработке этого index.html нужно будет на каждом шаге думать, что скажет система безопасности браузера по поводу обращений из локального файла к источникам в интернете.

proud_anon ★★★★★ ()
Ответ на: комментарий от feofan

Имхо, это и есть самое надежное решение. Расширение тоже может автообновиться

apt-get тоже может автообновиться :)

Legioner ★★★★★ ()
Ответ на: комментарий от proud_anon

Тогда при разработке этого index.html нужно будет на каждом шаге думать, что скажет система безопасности браузера по поводу обращений из локального файла к источникам в интернете.

Ну да, его нужно запускать через какой-нибудь веб-сервер на localhost-е. Несложно в любом случае.

Legioner ★★★★★ ()

Давно была спецификация на «подписанные скрипты» от Netscape

Проблема в MITM-атаках. Ничто не помешает подсунуть/подменить загружаемый скрипт.

Раньше можно было решать эту проблему джава-апплетом, но джавка сама решето. Запускать апплеты небезопасно по дефолту...

Как вариант, частичного решения - попросить посчитать sha-512 хэш js-кода и сравнить с оригиналом, при этом предусмотреть работу скрипта в offline mode.

anonymous ()
Ответ на: комментарий от Legioner

Ну да, его нужно запускать через какой-нибудь веб-сервер на localhost-е.

Основной плюс браузера я считаю в скорости доступа.

proud_anon ★★★★★ ()
Последнее исправление: proud_anon (всего исправлений: 1)

просто скачать с сервера file.js,

проверяя хэши и контрольные суммы, типа как stage от генту распространяется...

anonymous ()
Ответ на: комментарий от proud_anon

Есть параноики. Они могут себе усложнять жизнь. Есть обычные пользователи. Они используют что есть. Но они знают про то, что есть параноики, которые в случае чего обнаружат проблемы. И что они сами теоретически могут всё проверить. И им этого знания хватает, чтобы доверять софту. По крайней мере оснований не доверять у них нет. Все возможности перепроверить у них есть. Пользоваться этими возможностями или нет, это уже дело каждого. Лучше, конечно, когда есть удобный способ пользоваться безопасно, но и так пойдёт. Естественно self-hosting не будет являться рекомендуемым способом использования веб-приложения. Но поддерживаемым.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

Есть параноики. Они могут себе усложнять жизнь. Есть обычные пользователи. Они используют что есть.

  1. Делаешь API
  2. Параноики пишут для него свой софт
  3. Пользователи пользуются тем, что дают
  4. ???
  5. PROFIT!
edigaryev ★★★★★ ()
Ответ на: комментарий от Legioner

Репам дистрибутива я все же больше доверяю

feofan ★★★★★ ()

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

AndreyKl ★★★★★ ()

Шифруй файлы на стороне клиента с помощью этого расширения. А потом просто отдавай их на сервер. Правда идея не новая, такое есть над дропбоксом и гугл диском.

nikita-b ()
Ответ на: комментарий от Legioner

ну как бы это ограничение модели. будет-не будет это детали какие-то не важные. Ситуация в том что если человек доверяет твоему сайту и вводит в него данные то нет никаких механизмов чтобы не позволить этим данным попасть на сервер. Только если не вводить их совсем.

AndreyKl ★★★★★ ()
Ответ на: комментарий от AndreyKl

Ситуация в том что если человек доверяет твоему сайту и вводит в него данные то нет никаких механизмов чтобы не позволить этим данным попасть на сервер. Только если не вводить их совсем.

Человек не доверяет сайту просто так. Человек доверяет сайту, потому что он видел его исходный код и там нет отсылки пароля. Или человек надеется на то, что раз исходный код открыт и проект достаточно популярен, то уж отправка пароля-то точно привлекла чьё-нибудь внимание. Из этого важный вывод — человек доверяет конкретному исходному коду, а не сайту в принципе. И ему важно верить, что у него есть возможность проверить тот факт, что у него в браузере работает именно тот исходный код, который опубликован на сайте, а не какой-либо иной.

Legioner ★★★★★ ()

исходник выложить в публичное место (github)

там же хэши и контрольные суммы

при доступе предложить проверить, дополнительно делать автоматом, но с возможностью верификации

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.