В этой статье я хочу рассмотреть несколько известных методов защиты контента сайта от автоматического парсинга. Kаждый из них обладает своими достоинствами и недостатками, поэтому выбирать нужно исходя из конкретной ситуации. Кроме этого, ни один из этих методов не является панацеей и практически для каждого есть свои пути обхода, которые я тоже упомяну.
Самым простым и распространенным способом определения попыток парсинга сайта является анализ частоты и периодичности запросов к серверу. Если с какого-то IP адреса запросы идут слишком часто или их слишком много, то этот адрес блокируется и чтобы его разблокировать часто предлагается ввести каптчу.
Самое главное в этом способе защиты — найти границу между естественной частотой и количеством запросов и попытками скрейпинга чтобы не заблокировать ни в чем не винных пользователей. Обычно это определяется посредством анализа поведения нормальных пользователей сайта.
Примером использования этого метода может служить Google, который контроллирует количество запросов с определенного адреса и выдает соответствующее предупреждение с блокировкой IP адреса и предложением ввести каптчу.
Есть сервисы (вроде distilnetworks.com), которые позволяют автоматизировать процесс отслеживания подозрительной активности на вашем сайте и даже сами включают проверку пользователя с помощью каптчи.
Обход этой защиты осуществляется посредством использования нескольких прокси-серверов, скрывающих реальный IP-адрес парсера. Например сервисы типа BestProxyAndVPN предоставляют недорогие прокси, а сервис SwitchProxy хоть и дороже, но специально предназначен для автоматических парсеров и позволяет выдержать большие нагрузки.
В этом способе защиты доступ к данным осуществляется только авторизованным пользователям. Это позволяет легче контролировать поведение пользователей и блокировать подозрительные аккаунты вне зависимости от того, с какого IP адреса работает клиент.
Примером может служить Facebook, активно контролирующий действия пользователей и блокирующий подозрительных.
Эта защита обходится путем создания (в том числе автоматического) множества учетных записей (есть даже сервисы, которые торгуют готовыми учетными записями для известных социальных сетей, например buyaccs.com и bulkaccounts.com). Cущественным усложнением автоматического создания учетных записей может являться необходимость верификации аккаунта посредством телефона с проверкой его уникальности (так называемые, PVA -Phone Verified Account). Но, в принципе, это тоже обходится путем покупки множества одноразовых SIM-карт.
Это тоже распространенный метод защиты данных о парсинга. Здесь пользователю для доступа к данным сайта предлагается ввести капчу (CAPTCHA). Существенным недостатком этого способа можно считать неудобство пользователя в необходимости ввода капчи. Поэтому этот метод лучше всего применим в системах, где доступ к данным осуществляется отдельными запросами и не очень не часто.
Примером использования каптчи для защиты от автоматического создания запросов могут служить сервисы проверки позиции сайта в поисковой выдаче (например http://smallseotools.com/keyword-position/).
Обходится каптча посредством программ и сервисов по ее распознаванию. Они делятся на две основные категории: автоматическое распознавание без участия человека (OCR, например программа GSA Captcha Breaker) и распознавания с помощью человека (когда где-то в Индии сидят люди и в режиме онлайн обрабатывают запросы на распознание картинок, напримером может служить сервис Bypass CAPTCHA). Человеческое распознание обычно более эфективно, но оплата в данном случае происходит за каждую каптчу, а не один раз, как при покупке программы.
Здесь в запросе к серверу браузер отсылает специальный код (или несколько кодов), которые сформированы сложной логикой написанной на JavsScript. При этом, часто код этой логики обфусцирован и размещен в одном или нескольких подгружаемых JavaScript-файлах.
Типичным примером использования данного метода защиты от парсинга является Facebook.
Обходится это посредством использования для парсинга реальных браузеров (например, с помощью библиотек Selenium или Mechanize). Но это дает данному методу дополнителое преимущество: исполняя JavaScript парсер будет проявлять себя в аналитике посещаемости сайта (например Google Analytics), что позволит вебмастеру сразу заметить неладное.
Один из эффективных способов защиты от автоматического парсинга — это частое изменение структуры страницы. Это может касаться не только изменение названий идентификаторов и классов, но даже и иерархии элементов. Это сильно усложняет написание парсера, но с другой стороны усложняет и код самой системы.
С другой стороны, эти изменения могут делаться в ручном режиме где-то раз в месяц (или несколько месяцев). Это тоже существенно испортит жизнь парсерам.
Чтобы обойти такую защиту требуется создание более гибкого и «умного» парсера или же (если изменения делаются не часто) просто ручное исправление парсера, когда эти изменения произошли.
Это позволяет сделать парсинг большого количества данных очень медленным и поэтому нецелесообразным. При этом, ограничения неоходимо выбирать исходя из нужд типичного пользователя, что бы не снизить общее удобство пользования сайтом.
Обходится это посредством доступа к сайту с разных IP адресов или учетных записей (симуляция многих пользователей).
Данный способ защиты контента позволяет усложнить автоматический сбор данных, при этом сохранив визуальный доступ к ним со стороны обычного пользователя. Часто на картинки заменяются адреса электронной почты и телефоны, но некоторые сайты умудряются заменять картинками даже случайные буквы в тексте. Хотя ничто не мешает полностью выводить содержимое сайта в виде графики (будь то Flash или HTML 5), однако при этом может существенно пострадать его индексируемость поисковиками.
Минус этого способа не только в том, что не весь контент будт индексироваться поисковиками, но и в том, что исключается возможность пользователю скопировать данные в буфер обмена.
Обходится такая защита сложно, скорее всего нужно применять автоматическое или ручное распознавание картинок, как и в случае капчи.
Роберт Басыров
Сложность урока:
4 уровень - сложно, требуется сосредоточится, внимание деталям и точному следованию инструкции.
Недоступно в редакциях:
Ограничений нет
Несколько способов борьбы с автоматической регистрацией ботов.
Добавить в форму регистрации невидимое поле и скрыть его с помощью CSS. Скрывать с учётом того, что особо продвинутые боты обнаруживают display: none . Невидимое поле нужно назвать как-нибудь привлекательно для ботов в контексте содержания сайта: Компания, telefpone. К этому полю можно поставить знак * , - бот решит что без его заполнения не отправится форма.
Следом следует программное условие, что если это поле заполнено, то блокировать пользователя, либо возвращать ему тот же ответ, что и при удачной регистрации.
Другой вариант: подменить поле Имя. Для бота будет стандартное, для пользователей - названное вами, а при регистрации менять значения. Алгоритм регистрации не изменится, бот будет по прежнему вводить поле "имя(стандартное)" и не проходить регистрацию.
Защита по IP |
Во-первых , есть вероятность отсеять простого человека который:
Во-вторых , этих IP-адресов тысячи и десятки тысяч и ими не удобно эффективно управлять. Бессмысленно с ними возиться ради ботов, гораздо проще использовать нестандартные приёмы для защиты от автоматической регистрации. Кроме того, уже на нескольких специализированных форумах есть услуга регистрации аккаунтов не через прокси, а с IP реальных людей. Судя по всему используются ботнеты.
Организационные меры защиты |
Возможен такой вариант: пользователь после регистрации попадает в группу Новички с минимальными правами. Он может только заполнить профиль и ответить на форуме. Личные сообщения, постинг ссылок, добавление файлов, открытие новой темы и прочего ему запрещено. Как только он оставит на форуме N сообщений (на выбор администратора), он переходит в группу зарегистрированные пользователи , которая имеет базовые пользовательские права.
Можно создать и группу Активные пользователи , которые будут иметь расширенный набор прав и туда пользователь попадёт после набора M сообщений.
Штатно в Bitrix Framework такое реализовать не получится, нужны некоторые доработки. Пример возможного кода:
//при добавлении сообщения форума, если количество сообщений больше FLS_NUM_POSTS, //то припишем пользователя к специальной группе define("FLS_NUM_POSTS", 50); define("FLS_FORUM_GROUP", 27); AddEventHandler("forum", "onAfterMessageAdd", "FlsOnForumMessageAdd"); function FlsOnForumMessageAdd($ID, $arFields) { $arGroups = CUser::GetUserGroup($arFields["AUTHOR_ID"]); if(!in_array(FLS_FORUM_GROUP, $arGroups)) { $arProfile = CForumUser::GetByUSER_ID($arFields["AUTHOR_ID"]); if(intval($arProfile["NUM_POSTS"]) >= FLS_NUM_POSTS-1) { //добавим в группу $arGroups = FLS_FORUM_GROUP; //запишем новую группу CUser::SetUserGroup($arFields["AUTHOR_ID"], $arGroups); //обновим сессию текущему пользователю if($GLOBALS["USER"]->GetID() == $arFields["AUTHOR_ID"]) CUser::SetUserGroupArray($arGroups); } } }
В качестве организационных мер можно предусмотреть:
При использовании организационных мер может оказаться полезным платный модуль Модератор , позволяющий выносить предупреждения и поощрения пользователям, блокировать пользователей на сайте и форуме, скрывать и удалять сообщения конкретного пользователя и многое другое.
Самый "тяжёлый" способ. Не в плане технической реализации, а в плане удобства для пользователей. Суть проста: выполнение регистрации в несколько этапов.
Такую регистрацию могут пройти только специально написанные под конкретный проект боты. Либо производится ручная, человеческая регистрация с последующей передачей аккаунта под управление ботам.
Есть более мягкий вариант, когда авторизация происходит в один этап, но в её конце пользователям предлагается завершить авторизацию, заполнив ещё некоторое количество полей. Авторизовать на сайте пользователей можно и сразу, после заполнения минимума обязательных полей. И дать возможность им пользоваться сайтом. Но те из них, которые не сделали завершение авторизации (то есть не заполнили поля, которые их просили заполнить) попадают под подозрение, что они - боты. В дальнейшем их можно будет удалить или ограничить в правах (поместить в группу подозрительных), пока не заполнят.
Форумный движок phpBB обладает большим количеством достоинств, он удобен и для пользователей и для модераторов и, как следствие, очень популярен. Но именно популярность порождает его главный недостаток — его спамят, причем спамят в автоматическом режиме. Через некоторое время постоянный поток регистраций новых фейковых пользователей и спам сообщений от них может порядком поистрепать нервы администрации сайта.
PhpBB версии 3.* в базовой поставке содержит аж 4 варианта каптчи, которые можно предлагать пользователям при регистрации на форуме. Есть даже recaptcha , однако для автосабмиттеров, как показывает практика, это не помеха.
Эти программы знают как выглядят типовые точки входа на страницы регистрации различных форумных движков. Знание это основано на распознавании DOM-моделей вебстраниц, содержащих формы для регистрации новых пользователей, для постинга сообщений и так далее. То есть, например, в случае phpBB робот знает, что точка входа для регистрации находится по адресу /ucp.php?mode=register и что на этой странице есть кнопка вида:
Не вдаваясь в технические подробности, отмечу что найти и нажать эту кнопку в html-документе уже можно как минимум по id или по name.
Как только робот добирается до страницы с каптчей, он получает картинку каптчи и пытается распознать её. Тут могут применяться различные технологии, в зависимости от изощренности программы, от OCR-алгоритмов до простого распознавания каптчи живым человеком. Именно поэтому защита не срабатывает. Бан IP-адресов на форуме также абсолютно бесполезен, так как роботы спамят через многочисленные прокси сервера. В этом смысле нет разницы банить адреса или чистить новые авторегистрации, всё так или иначе сводится к потере времени.
Получается, что единственный способ отсечь автосабмиттеры — немного видоизменить разметку точки входа на форум уникальным образом. Еще года два-три назад для phpBB2 я проделал такой фокус и это сработало — автоматические регистрации прекратились. Тоже самое недавно удалось подтвердить на другом сайте, уже на движке на phpBB3.
Далее я приведу конкретный проверенный пример видоизменения страницы регистрации phpBB. Однако хотелось бы оговориться, что данный пост предлагает концепцию защиты от автоматических регистраций на форумах, а не конкретные способы. Всё зависит от рук и головы администратора форума. Желательно обладать элементарными знаниями html и css. Если читатели начнут массово копировать данный способ, то эту «эвристику» спамеры запрограммируют в свой софт и автоматические регистрации продолжатся.
Итак, выбираем настройках phpBB форума самую простую каптчу «CAPTHA без GD».
Выглядит в браузере (FF3) это так:
Если посмотреть на разметку страницы регистрации в районе картинки с каптчей, то она выглядит так:
Собственно атрибут src в теге img и содержит картинку с каптчей. Открываем фолдер с текущей темой, установленной на форуме. В моем случае это prosilver: /forum/styles/prosilver/template. В нём находим файл captcha_default.html. Если посмотреть в этот шаблон, то видно место, в котором формируется вышеупомянутая разметка:
Лёгким телодвижением усложним жизнь автосабмиттерам:
Выглядеть в браузере это будет теперь так:
Согласен, не очень красиво, зато нервы админа теперь будут в порядке. Обычные пользователи по-прежнему могут регистрироваться. Разумеется, при апгрейде движка на более новую версию нужно будет не забыть проделать этот фикс еще раз. Надеюсь, что храбро-phpbb-пользователи не будут зацикливаться на данном примере, а придумают другие способы изменения точки входа согласно предложенной концепции защиты.
