Защита от парсинга PHP

Black#FFFFFF

Постоялец
Регистрация
19 Июл 2007
Сообщения
228
Реакции
172
Задача (алгоритм) :
реализовать для не очень умных парсинговых скриптов защиту от парсинга страниц средствами php со временным баном особо наглых без ущерба для поисковой выдачи/быстроты получения страниц пользователями.

Собственно нужны мысли (советы) :
- от SEO шников
- от программистов
- от системных администраторов
1) есть ли готовые решения (не обязательно php) (не предлагать Cloudflare, ибо они как попало перенаправляют трафик при любых пакетах, а гуляния пользователей: СНГ - Индия - Китай - США - СНГ позитива не добавляют)
2) мысли по построению защиты (мои) :
а) кол-во запросов с одного айпи с обратным dns запросом (и пропуском поисковых ботов - если у кого есть список, был бы благодарен) в минуту, если больше определенной величины - в бан на время (с записью в лог ip).
б) отсеивание тех, кто вернул не правильный айпи адрес, вообще не представился | filter_var([ip], FILTER_VALIDATE_IP)
в) заголовки (набор заголовков) супер глобального массива SERVER для определения прозрачных proxy
'REMOTE_ADDR',
'HTTP_VIA',
'HTTP_X_FORWARDED_FOR',
'HTTP_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_FORWARDED',
'HTTP_CLIENT_IP',
'HTTP_FORWARDED_FOR_IP',
'VIA',
'X_FORWARDED_FOR',
'FORWARDED_FOR',
'X_FORWARDED',
'FORWARDED',
'CLIENT_IP',
'FORWARDED_FOR_IP',
'HTTP_PROXY_CONNECTION',
'HTTP_X_FORWARDED_SERVER'
можно дополнить, или дать ссылку на полный список подобных заголовков, если кто где собирает.
г) можно ли определить NAT? возможно не только средствами php, но и (например) библиотеками web сервера? (пока что мысли: если ip один, user agent разные, страницы запросов разные, и не выходят за кол-во адекватных конкурентных запросов в интервал времени, но здесь сложновато будет проверять)
в) Проверка Cookie/XHR Request еще актуальна? или к данному моменту это уже моветон?
д) Приветствуются мысли по построению быстрой проверки, исключая проверку портов и т.п., чтобы не снизить время получения нормальными пользователями обычных страниц.
ж) Приветствуется конструктивная критика: почему так не делать с аргументацией.
з) Как на Ваш взгляд хранить списки IP для более быстрой проверки/считывания (формат)? key:ip as int = val: кол-во запросов: массив? или как быстрее?
и) проверять ли: определен ли referer?
Можете дополнить. Рад любым мыслям. Реализация не нужна. Разрабатываем алгоритм.
После разработки алгоритма поделюсь своей реализацией/и некоторое время на общественных началах в случае с php реализацией готов дорабатывать/править с размещением, скажем, на Github.

Тестовой площадкой будет магазин до 20 тысяч пользователей в сутки/3-4 тыс страниц в поисковом индексе/2-3 тыс уник товаров.
 
Последнее редактирование:
Пол четвёртого ночи, я последние сутки обновлял сервера и не спал, поэтому ниже может быть полный бред, но мой подыхающий мозг советует такое:

Очень тупые парсеры запрашивают только HTML и картинки, но игнорируют JS и CSS, а так же не умеют обрабатывать эти JS.

Делаешь фронт с подгрузкой контента через JS и парсерам скажешь досвидания.
wget/file_get_contents будет возвращать страничку с небольшим JS файлом и пустым содержимым.

Чуть более умная защита - смотреть логи. Если клиент приходит за html, но не запрашивает CSS и JS - можно блочить.
Обратная проблема - кеш браузера. Браузер не всегда делает запрос контента, который закеширован.

Ещё можно попробовать - установка куки через JS.
Нет куки - редирект на страницу её установки, затем редирект обратно.
Парсеры с вероятностью 90% не смогут установить такую куку.

Защита через referer - немного глупая. Часть антибаннеров его блокируют к передаче. Заблокируешь реальных людей.

А вообще, защита через PHP - глупая затея. Это большая нагрузка на сервер.
Работа с подобными данными идёт средствами nginx, varnish и подобным ПО.
Смотри в сторону защиты от ДДОС и бери идеи там.

P.s. в теме защит не обновлял знания лет 5, так что всё вышенаписанное могло устареть...
 
А вообще, защита через PHP - глупая затея. Это большая нагрузка на сервер.
Работа с подобными данными идёт средствами nginx, varnish и подобным ПО.
Смотри в сторону защиты от ДДОС и бери идеи там.
Спасибо за ответ, сам в 4 утра пишу код сижу:) По сабжу: все это сейчас рассматриваю в виде дополнения к cms, и когда (на хостинге) нет возможности работать с п.о. сервера напрямую, поэтому и отрабатываю алгоритм и спрашиваю похожие мысли. В крайнем случае отправлю клиента на vds с хорошим решением. На основании set cookie, ajax/iframe + timestamp (rand request строка) в запросе сам писал мини защиты (но тоже лет 5 уже прошло), отшибало дурных ботов на ура. Но все идет, все меняется. Поэтому лишний раз спрошу/узнаю:) Клиент просто на сайте проделал интересную работу в плане подбора разного рода запчастей. И в последнее время 30% его трафика: это парсеры разного рода от конкурентов, причем не всегда умные. Задолбал перебор страниц:) с паразитной нагрузкой.
 
Тут надо смотреть чем парсят.
Я могу парсить тупым wget или curl, а могу через Selenium на Java.
В первом случае, как я говорил, будут только страницы и картинки.
Во втором будет Google Chrome с плагинами, полноценным интерфейсом и тыканьем по ссылкам.

Что-то мне подсказывает, что 90% парсеров - это первый вариант.
Поэтому ограничение количество страниц в минуту с какой-нить страничкой "подождите загрузки" и какая-нить JS страничка с простановкой куки.
Причём как я понял, защита делается чуть умнее - JS даётся задание что-то вычислить (математика) и отправить результат. Если результат верный - отдаётся кука. Ну и если кука есть - то пускаем на сайт.
Саму сессию привязывать ко всему, что только можно - данные браузера, IP, user agent и т.д. Чтобы было сложно отдать такой же заголовок парсером.

Думаю этого будет более чем для базовой защиты.
 
А ещё лучше признак прохождения проверки пихать не в куку, а в сессию...
Мне кажется передать сессию от браузера в парсер будет вообще не реальной задачей... Там же алгоритм не только привязки к куке, т.е. просто скопировать куку будет не достаточно.
 
А ещё лучше признак прохождения проверки пихать не в куку, а в сессию...
Мне кажется передать сессию от браузера в парсер будет вообще не реальной задачей... Там же алгоритм не только привязки к куке, т.е. просто скопировать куку будет не достаточно.
сессия более разумная идея, но не навредит ли поисковым ботам сессия/куки?
 
Я не кодер, проф навыков нет, но в парсинге с самым сложным чем я сталкивался это спарсить яндекс выдачу wordstat. Что там сейчас - я не знаю, но еще год назад он мне знатную какаху подкинул...

При заходе на страницу, если через код открывать - все поля и все данные были зашифрованы JS, причем в конце страницы был ключ для расшифровки, и этот ключ постоянно менялся да еще и сам был зашифрован :D, пришлось на шарпе обходить. В целом алгоритм не сложный, но заставил попариться, думаю такая штука отобъет у многих желание парсить
 
сессия более разумная идея, но не навредит ли поисковым ботам сессия/куки?
А мы ботов будем отсекать обратным dns запросом (reverse dns lookup), там на выходе по ip выдает поддомен, который содержит подстроку: google, yandex и т.п. и в отличие от проверки USER AGENT подделать такое сложновато. И к ним никакой санкции. Но здесь бы мнение SEO шников тоже получить.
 
сессия более разумная идея, но не навредит ли поисковым ботам сессия/куки?
Роботов Яндекса/Гугла очень легко определить. Они спокойно предоставляют информацию о себе, запрашивают robots.txt и т.д. Да даже их IP адреса относительно известны.
На поисковых роботов каких-то мелких поисковиков, думаю, в данном случае можно положить болт.
Да и вроде как они умеют JS уже давно, ибо ajax и прочее.

Вообще надо смотреть как делает Cloudflare и делать по аналогии. Они через JS защищаются. Надо загуглить как они поступают с поисковыми роботами.
 
Назад
Сверху