Как защитить данные веб-приложения?

Question

[Георгий Н]

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

Как от этого можно защититься?

Различные ключи, коды, шифрование - это ведь все передается/генерируется/хранится - можно сказать в открытом виде - javascript ведь. А значит не подходят? Какие есть еще варианты?

Answer 1

[Алексей Уколов]

Ни-ка-ких.

Всё, что отдаётся клиенту и там обрабатывается можно вскрыть, подсмотреть, отреверсинжинирить.

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

Если для реализации полноценного аналога нужно месяц, то никто в здравом уме заниматься этим не будет - проще заплатить, чем костылить и потом поддерживать.

Есть отдельная категория пользователей, которые упрутся, потратят на разработку эквивалент абонентской платы за несколько лет, но сделают своё. Или просто сделают какой-то очень ограниченный набор функционала, нужный именно им.
С первыми вы ничего поделать не сможете, это неадекватные люди, не ваша аудитория.
А вот если есть вероятность появления большого количества вторых, значит, вам нужно для них сделать тариф "Нищеброд" и они будут платить вам, вместо своих программистов.

Comments

[Георгий Н]

Я так же примерно думаю. Но как же хотелось услышать другой ответ :-)
Впрочем, я еще надеюсь... А вдруг все же мы что-то упускаем.

[Алексей Уколов]

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

[Георгий Н]

Алексей Уколов: Видимо, да. Но все же хотелось бы не голый маркетинг, а подкрепленный некоторыми техническими моментами. Опыт показывает, что если что-то можно украсть, то оно будет украдено.

[Алексей Уколов]

Как я уже написал, со 100% вероятностью вы ничего не защитите. Но приблизиться к этой цифре гораздо проще путём маркетинга и развития продукта, нежели технически вставляя палки в колёса.
Любая такая "защита" обязательно скажется на скорости внедрения нового функционала, например. Разработчики, перед тем как делать новую фичу, будут изобретать способы обхода своей же собственной защиты или придумывать новую. Вы от этого только проиграете.
Всех клиентов вы не получите, просто примите это и сосредоточьте усилия на платежоспособных и адекватных. Клиентская база будет меньше, зато удовольствия от работы будет гораздо больше.

[four4]

Если для реализации полноценного аналога нужно месяц

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

[four4]

Георгий Н:

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

Не обязательно будет скоро украдено. Украть сервис информирования о погоде не так просто.
Или если цена продажи достаточно не напрягающая, то зачем красть-то, это же тоже стоит ресурса (время - деньги).

Answer 2

[nirvimel]

Простая (ограниченная) защита от парсинга: Блоки, в которых отображаются защищаемые данные, выводить на странице в виде картинок, генерируемых на сервере. Например, каждое отдельное чисто/строку в маленькой PNG. Еще лучше слепить все в одну большую картинку (вперемешку), а на странице, в соответствующих позициях, вместо текста вставить img теги, в каждом указать смещение и размер соответствующего блока на большой картинке.

Answer 3

[four4]

Не отдавать в простом/удобном виде больше, чем нужно по минимуму.
Исключить возможность логически догадаться (например, нумерация объектов подряд позволяет из предположения что есть объекты 1 и 2 получить объекты 3-100500).
Ограничить число запросов в единицу времени.
При подозрениях на автоматизированное скачивание данных - активировать Капчу.

Comments

[Георгий Н]

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

[mofecuju]

Георгий Н:
Ограничивать на нормальном уровне - для человека подходящим.
Но затрудняющим реализацию автоматики.

Answer 4

[Александр Таратин]

Передавать данные в шифрованном бинарном виде по вебсокетам.
+ блокируйте консоль в браузере. Как например это делает авито
Как авито блокирует консоль разработчика в браузере Chrome?
Отсечет процентов 50 ломальщиков.
Ибо на шаред хостингах в основном некастомизируемый php, на котором тяжко с вебсокетами работать.
Тот же кто может позволить себе vps скорее всего и так купит у вас тариф.

Comments

[mofecuju]

Дешевые VPS дешевле чем дорогой Shared.
Разница существенная в пользу VPS

[Александр Таратин]

mofecuju: vps еще админить нужно. Это тоже стоит учесть.

[mofecuju]

Александр Таратин: Там по умолчанию предлагается довольно удобная админ-панель. И по умолчанию все довольно хорошо настроено. Вручную ковыряю оченьььььььььььььььььььььььььььььььььь редко.

[mofecuju]

Александр Таратин: простите, речь же вроде об использовании ВПС "хаерами" - им там слишком сложно?

[Александр Таратин]

mofecuju: Ну смотрите. Допустим я нищеброд и не хочу покупать тариф с аналитикой.
Поэтому я иду на fl.ru
Ищу школьника, который мне напишет парсер за отзыз/кусок хлеба. Который будет работать на моем нищебродском хостинге/vps. И при этом этот парсер не должен давать сбоев, чтобы не искать потом постоянно новых фрилансеров.

Короче собственных шифрованный бинарный протокол поверх вебсокетов считаю достаточной защитой данных.

[mofecuju]

Александр Таратин: ВДС начинаются от 150 рублей в месяц. А за 500 рублей - уже 4 гигабайта оперативки.

[Александр Таратин]

mofecuju: Ок.

[four4]

Ибо на шаред хостингах в основном некастомизируемый php, на котором тяжко с вебсокетами работать.
Тот же кто может позволить себе vps скорее всего и так купит у вас тариф.

Что мешает прямо со своего адреса ломать, это не банк в конце концов?
Зачем ВПС, когда достаточно прокси?

[Александр Таратин]

four4: Ну лично я не представляю, чтобы у меня на домашнем ПК крутился какой-то парсер и отправлял данные на сервер. Слишком неудобно и ненадежно выходит.

[four4]

Александр Таратин: почему? у вас плохой интернет?

[Александр Таратин]

four4: Держать ПК включенным 27/7 - это шумно и не экономно.
А вдруг поломка?
На vps все таки проще.
+ я за использование windows на домашних ПК.