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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Запретить: /

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так или иначе.

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

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

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

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

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

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

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

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

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

Как вы запрещаете сценаристам избивать ваш сайт сотни раз в секунду?

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

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

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

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

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