Лучшие методы, чтобы избежать «очистки данных» из базы данных сайта - PullRequest
23 голосов
/ 14 января 2010

Я настраиваю сайт с использованием PHP и MySQL, который по сути является просто веб-интерфейсом к существующей базе данных. Понятно, что мой клиент очень старается помешать кому-либо сделать копию данных в базе данных, но в то же время хочет, чтобы все было общедоступным, и даже ссылку «просмотреть все» для отображения каждой записи в БД.

Хотя я создал все для предотвращения таких атак, как атаки с использованием SQL-инъекций, ничто не мешает кому-либо просматривать все записи в формате html и запускать какой-либо сценарий для анализа этих данных обратно в другую базу данных. Даже если бы мне пришлось удалить ссылку «просмотреть все», кто-то теоретически мог бы использовать автоматизированный процесс, чтобы просмотреть каждую запись одну за другой и скомпилировать их в новую базу данных, по существу сжимая всю информацию.

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

Ответы [ 14 ]

45 голосов
/ 14 января 2010

Хотя ничто не мешает определенному человеку отказаться от общедоступного контента, вы можете сделать несколько основных вещей, чтобы смягчить опасения клиента:

  • Ограничение скорости по учетной записи пользователя, IP-адресу, агенту пользователя и т. Д. - это означает, что вы ограничиваете объем данных, которые конкретная группа пользователей может загрузить за определенный период времени. Если вы обнаружите большой объем передаваемых данных, вы закроете учетную запись или IP-адрес.

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

  • RIA - сделайте ваши данные доступными через интерфейс насыщенного интернет-приложения. Сетки на основе JavaScript включают ExtJ, YUI, Dojo и т. Д. Более богатые среды включают Flash и Silverlight, так как 1kevgriff упоминает .

  • Кодирование данных в виде изображений. Это довольно навязчиво для обычных пользователей, но вы могли бы закодировать некоторые из ваших таблиц данных или значений в виде изображений, а не текста, что могло бы победить большинство текстовых анализаторов, но, конечно, не надежно.

  • robots.txt - для запрета явных веб-пауков, известных агентов-пользователей роботов.

    Пользователь-агент: *

    Запретить: /

  • Использовать метатеги роботов. Это остановило бы пауков. Это не позволит Google проиндексировать вас, например:

Существуют разные уровни сдерживания, и первый вариант, вероятно, наименее навязчив.

29 голосов
/ 14 января 2010

Если данные опубликованы, они видны и доступны каждому в Интернете. Это включает людей, которых вы хотите видеть, и людей, которых вы не видите.

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

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

11 голосов
/ 14 января 2010

Есть несколько способов сделать это, хотя ни один из них не идеален.

  1. Представить данные в виде изображения вместо HTML. Это требует дополнительной обработки на стороне сервера, но это не составит труда с графическими библиотеками в PHP. В качестве альтернативы вы можете сделать это только для запросов определенного размера (то есть всего).

  2. Загрузить оболочку страницы, затем получить данные с помощью вызова AJAX и вставить их в DOM. Используйте сеансы для установки хэша, который должен быть передан обратно с вызовом AJAX для проверки. Хеш будет действителен только в течение определенного промежутка времени (то есть 10 секунд). На самом деле это просто добавление дополнительного шага, через который кто-то должен был бы перепрыгнуть, чтобы получить данные, но это предотвратило бы простой просмотр страницы.

7 голосов
/ 14 января 2010

Попробуйте использовать Flash или Silverlight для своего интерфейса.

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

5 голосов
/ 26 сентября 2010

принудительная перекапча каждые 10 страниц для каждого уникального IP-адреса

5 голосов
/ 14 января 2010

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

Эмпирическое правило: если вы хотите что-то сохранить для себя, не используйте Интернет.

3 голосов
/ 15 января 2010

Уберите руки от клавиатуры и спросите своего клиента о причине , почему он хочет, чтобы данные были видны, но не могли быть скопированы?

Он спрашивает о двух несоответствующих вещах и, возможно, обсуждает свои рассуждения, что принесет некоторые плоды.

Возможно, он действительно не хочет, чтобы он был общедоступным, и вам нужно добавить аутентификацию / авторизацию. Или он может решить, что действительно важно открыть API. Но ты не узнаешь, пока не спросишь.

2 голосов
/ 14 января 2010

Использование чего-то вроде Adobe Flex - интерфейса приложения Flash - исправит это.

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

2 голосов
/ 14 января 2010

Я не знаю, почему ты это сдерживаешь. Клиент предлагает данные.

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

В любом случае.

Вы можете проверить браузер, разрешение экрана и IP-адрес, чтобы убедиться, что это какой-то автоматический скребок.

Большинство вещей, таких как cURL и wget - если их тщательно не настроить - явно не браузеры.

1 голос
/ 14 января 2010

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...