Xpoint
   [напомнить пароль]

Необходимо максимально усложнить сканирование базы данных через сайт

Метки: [без меток]
2012-05-24 17:24:15 [обр] zx9r[досье]

Здравствуйте, Уважаемые!
Работаю над проектом-справочником, основной ценностью которого является содержимое базы данных. Это содержимое предполагается заносить туда в ручном режиме из разных многочисленных групп открытых источников. Способ представления информации в источнике сильно разнится от группы к группе. Соответственно, работа только по первичному заполнению базы, навскидку, тянет на тысячи человекочасов (как просто операторской работы, так и программерской работы по подгонке интерфейса заполнения базы под очередную группу источников). Т.е. можно сказать, что будет проделана колоссальная работа по поиску и упорядочиванию разрозненной информации. И результат этой работы будет доступен на сайте сервиса в уже упорядоченной форме.
Конечно, помимо наполнения БД содержимым, придется написать и сам механизм сервиса (включающий поиск с анализом опечаток, снятием омонимии и т.п.) но это не так затратно по ресурсам, как собирание базы. Плюс, тексты скриптов, по определению, неплохо защищены.

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

Мне представляется что техническое решение моей задачи лежит в плоскости максимального затруднения (вплоть до невозможности) автоматизированного парсинга информации, содержащейся в БД. Т.е. пусть нанимают операторов и вручную копируют содержимое моей БД.

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

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

  1. Засекаем слишком частые обращения с одного IP и блокируем доступ с него на некоторое время (правда, придется как-то обрабатывать ситуацию, когда большие группы юзеров "видны" под одним IP). Реверс-инженер легко обойдет эту защиту, использовав список анонимных открытых прокси-серверов и установив безопасный тайм-аут для каждого IP.
  2. Усложнить задачу реверс-инжиниринга можно занося в черный список листинги анонимных открытых прокси-серверов. Но бесплатно это можно осуществить только с листингами, публикуемыми в открытом доступе. Если покупать так называемые "приватные" листинги, то это никаких денег не хватит. Реверс-инженер же может себе позволить потратиться - ему надо всего один приватный список купить, а мне (для повышения надежности) - все.
  3. Анализ других параметров клиента - детский сад, как мне кажется, т.к. подделываются легко. Хотя, можно попробовать исхитриться...

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

  1. Сложные JS-цепочки формирования текста на странице из "зашифрованного" ответа сервера. Полагаю, что на "серьезное решение" не тянет даже при использовании AJAX-подобного механизма с несколькими сеансами связи. ИМХО, предварительно вручную распутать даже сложную цепочку и восстановить алгоритм дешифровки не составит труда.
  2. Применение переменных JS-цепочек, когда дешифрующий JS-механизм каждый раз уникален. При грамотной реализации заметно осложнит реверс-инжиниринг т.к. потребует исполнения JS, содержащегося в генерируемом моим сервером html-коде. Тут моего кругозора недостаточно (с JS не работал), подскажите, плз, доступны ли сейчас механизмы, позволяющие реверс-инженеру внутри своей программы выполнить JS, содержащийся в отданном ему html-коде? Также, задачу по реверсу такого решения можно свести к задаче по автоматическому изготовлению скриншота окна браузера и дальнейшего распознавания текста.
  3. Вывод данных в виде изображений. Специфика информации, которой будет оперировать сервис, такова, что в браузер клиента отдается большое количество разнообразных цифровых данных - различные значения параметров и другая интересная юзеру информация. Данных в виде объемного текста нет вовсе. Т.е. все эти данные можно легко представить в виде небольших картинок и в таком виде отдавать клиенту. К сожалению, в настоящее время доступна возможность постановки "на поток" распознавания текста на изображениях. Правда, я не в курсе относительно распространенности/цены такого решения.

Различные "подлянки".
Путей реализации и подходов может быть много. Но цель - отдать вражеской программе сканирования (но не обычному юзеру) слегка поврежденные данные таким образом, чтобы "враг" этого не заметил и создал конкурирующий продукт на основе этих "слегка поврежденных" данных. Существенный минус - после того, как "враг" обнаружит проблемы с данными, у него будет уже работающий сервис и получится, что мотивация "починить" будет относительно высока по сравнению с изначальной мотивацией "создать с нуля, украв БД".

Прошу прощения за большой объем текста. Буду признателен за комментарии и идеи.

спустя 25 минут [обр] Евгений Седов aka KPbIC(4/176)[досье]
Для начала поищите на самой Точке по "защита от {роботов|скачивания|сайта}".
спустя 25 минут [обр] zx9r[досье]
Упс. Спасибо за наводку. Перед созданием темы я честно прошерстил раздел "Безопасность". И, на свою беду, им и ограничился.
спустя 1 час 46 минут [обр] Филипп Ткачев(6/112)[досье]
Можно попробовать выдавать временные токены на доступ, распространяемые через sms или хуже, например код, который будет диктовать голосом тот же asterisk. Это затратно, но информация может стоить того.
спустя 3 часа 54 минуты [обр] zx9r[досье]
Для начала поищите на самой Точке по "защита от {роботов|скачивания|сайта}".

Увы и ах... Поискал и по самой Точке (и не только по указанному запросу), и по интернетам. К сожалению, что касается идей и методов решения моей задачи, имеются только варианты уже изложенного мной. Хотя, по моему вопросу относительно возможности исполнить JS, ясность внесена - можно и, насколько я понял, не сложно (при условии достаточной квалификации программиста). Оптимизма сей факт не добавляет.

Можно попробовать выдавать временные токены на доступ, распространяемые через sms или хуже, например код, который будет диктовать голосом тот же asterisk. Это затратно, но информация может стоить того.

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

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

спустя 6 часов [обр] Jared(0/26)[досье]

zx9r[досье], ограничьте количество данных в единицу времени с одного аккаунта. Скажем, один запрос в 10-20 секунд. Или 30 запросов в сутки. При превышении - капча. При фейле капчи 3 раза подряд - бан аккаунта до разбирательства; ну или на 12 часов. При зафейленной капче 10 раз подряд с одного ip, но нескольких аккаунтов - бан всем. При неожиданной смене ip, особенно если новый адрес из новой страны - снова капча (прокси, особенно из открытых списков имеют обыкновение отваливаться).
При слишком активной работе (3 суток по запросу каждые 20 секунд без продыха), с прохождением капчи - бан до разбирательства.

Ну и тому подобные меры.

Фактически, сложная капча, генерируемая одним случайным способом из тысячи возможных - единственный способ хоть как-то защититься от ботов, особенно если контент настолько ценен. Да и капчи ломаются =\. Любой js код, который будет исполняться на клиенте, можно выполнить и с помощью бота. Например браузер со скриптом, который примет исходные данные от бота, выполнит все что надо и отдаст сборщику результат. Или, думается, node.js можно для этих целей использовать.

Можно попробовать выдавать временные токены на доступ, распространяемые через sms или хуже, например код, который будет диктовать голосом тот же asterisk. Это затратно, но информация может стоить того.

Воткнуть в машину gsm модем и спокойно автоматом кушать sms-токены - не проблема. С астериском может выйти интереснее, но, AFAIK есть достаточно неплохие инструменты, и, кажется даже сервисы для обратного преобразования (speech-to-text).

Яндекс и Гугл защищают свою выдачу от постоянного парсинга именно с помощью капчи.

Да, кстати, на самом деле, даже ограничение на количество данных в единицу времени не панацея. Нет принципиальной сложности прикрутить к браузеру скрипт, который будет ходить по ссылкам с заданным интервалом. И к нему демона, который будет просто делать скриншоты с заданным периодом. Дальше, как вы и сами понимаете, OCR и парсинг результата. Ну, и понятно, несколько браузеров и несколько аккаунтов, чтобы ускорить процесс.

Вобщем, на первый взгляд, абсолютного решения не видно. Только вариант вынуждать бота ходить по страницам не быстрее человека. Да и еще усложнить ему (точнее программисту, который будет его ваять) задачу всякими мелкими пакостями вроде динамических урлов (адрес конкретного ресурса меняется для данного аккаунта после каждого запроса) Но это не спасет от автоматического парсинга.

спустя 1 час 16 минут [обр] Филипп Ткачев(6/112)[досье]
Где-то проскакивала библиотека на PHP умеющая исполнять JS. Ничего сложного вытащить потом сгенерированное DOM-дерево и скормить его XPath.
Как вариант мошенники могут воспользоваться API к тому же FineReader и делать полный рендрер страницы с последующим распознаванием. Я вроде слышал, что Google патентовал подобную технологию.
А защита через Captcha выглядит самой эффективной, я с Jared[досье] согласен.
спустя 1 день 4 часа [обр] zx9r[досье]

Jared[досье], Филипп Ткачев[досье], спасибо за информацию. Получается, что как-то кардинально воспрепятствовать парсингу моих страниц я не смогу. Остается максимально осложнить задачу, применив выше уже мной озвученную схему (изображения + динамическое JS-шифрование). Что еще можно навернуть, ума не приложу. Для преодоления таких решений реверсу придется исполнять JS и распознавать картинки, или, как вариант, делать скриншоты и опять распознавать (и не факт, что вариант со скриншотами будет проще в реализации). Полагаю, что эти меры повысят как требования к уровню профессионализма реверс-инженера, так и, соответственно, усложнят поиск подходящего кандидата.

Выходит, действительно, придется серьезно препятствовать не только парсингу уже полученной страницы, но и процессу автоматического потокового получения этих страниц. Но проблема в том, что я не могу использовать решения, заметно осложняющие жизнь пользователю. В противном случае, я своими руками создаю потенциальное конкурентное преимущество для потенциального конкурента (пардон за рекурсивную тавтологию). Я и так опасаюсь, как бы мои фокусы с картинками и JS не аукнулись (например, некоторые мобильные пользователи могут выпасть). Так что, предварительная каптча для всех запросов - это не вариант. Остается отлавливать/детектировать именно ботов и уже для них выдавать каптчу. Плюс принять другие меры (уже озвучены):

  1. Установить минимальное время между запросами с одного IP - секунд пять...десять.
  2. Усложнить схему выдачи информации - сначала минимум данных на предварительной странице, а по клику выдавать уже более полную версию (естественно, в ссылку на полную версию включать динамический шифр, чтобы получить ее можно было только с предварительной страницы).
  3. Навскидку больше не придумывается. Если есть что-то принципиально отличающееся от озвученного, просветите, плз.

Создавать систему аккаунтов не хочется - слишком много сложностей для юзеров создается. А с технической точки зрения, реверсу работать из под кучи акаунтов не сильно сложнее, чем из под кучи IP. Другое дело, что контролируя как просто параметры аккаунтов (в частности, дату создания и историю запросов), так и связку аккаунт+IP+(уровень_недоверия_к_аккаунту_и_IP) можно получить дополнительный мощный инструмент по засечке ботов. Так что, можно какой-нибудь промежуточный вариант применить - при неавторизованном доступе выдавать каптчу при малейшем подозрении, что клиент является ботом. А при авторизованном (получив дополнительные инструменты детекции ботов) - ослабить контроль (но не сразу, а только после некоторого стажа). Но это, все равно, сделает сервис немного менее прозрачным для юзера.

Яндекс и Гугл защищают свою выдачу от постоянного парсинга именно с помощью капчи.

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

спустя 33 минуты [обр] Филипп Ткачев(6/112)[досье]
Я могу вам предложить еще один вариант - проанализировать поведение реально валидных пользователей, построить "слепок поведения" (или набор слепков) и находить корреляцию поведения новичков со слепком(и). Если корреляции нет - то понятно, что это бот, каптчу ему на каждый запрос. Каптчу делать такую, чтобы генерировалась легко с вычислительной точки зрения, а распознавалась проблематично. Опять же можно recaptcha использовать для уменьшения нагрузки на свои сервера. Как вариант - при появлении отклонения от нормального поведения - выдавать меньшие порции данных с большой задержкой. Например по 5 записей через 15-20 сек.
Powered by POEM™ Engine Copyright © 2002-2005