Подтвердить что ты не робот

Лучшие методы, чтобы избежать "скрепок данных" из базы данных веб-сайта

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

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

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

4b9b3361

Ответ 1

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

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

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

Ответ 2

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

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

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

  • RIA - сделать ваши данные доступными через интерфейс Rich Internet Application. Сетки на основе JavaScript включают ExtJs, YUI, Dojo и т.д. Более богатые среды включают Flash и Silverlight как 1kevgriff упоминает.

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

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

    Пользовательский агент: *

    Запретить:/

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

    < meta name= "robots" content = "noindex, follow, noarchive" >

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

Правило большого пальца: если вы хотите что-то сохранить себе, не делайте этого в Интернете.

Ответ 6

заставляет reCAPTCHA каждые 10 страниц загружать для каждого уникального IP

Ответ 7

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

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

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

Ответ 8

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

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

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

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

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

Как насчет создания чего-то похожего на защиту троллей на доске объявлений... Если обнаружена царапина (возможно, определенный объем доступа в минуту от одного IP-адреса или направленный обход, который похож на сканирование карты сайта), вы можете затем начните представлять данные мусора, например, измените пару цифр номера телефона или добавьте глупые имена для названия полей.

Отключите это для IP-адресов Google!

Ответ 13

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

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

Ответ 14

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

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

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