Простая инструкция как защитить свой сайт или интернет-магазин от парсинга

Советы, которые позволят максимально сократить "паразитный" трафик.

Несмотря на то, что моя компания XMLDATAFEED профессионально занимается парсингом уже более 3х лет и ежедневно парсим порядка 400 крупнейших сайтов РФ, мы часто сталкиваемся с просьбами наших клиентов помочь в противодействии парсингу их ресурсов.

Да, это звучит немного странно, особенно учитывая тот факт, что клиенты знают что мы часто и их сайты парсим (мы это никогда не скрываем), но наш опыт в парсинге иногда помогает сделать их защиту лучше, т.к. в 80% случаев их парсят не профессионалы, а "студенты", которые в массе своей учатся этому делу, создают очень высокую паразитную нагрузку и не готовы заниматься серьезным анализом обхода защиты (исповедуют принцип "сила солому ломит" и включают в 50 потоков сбор данных).

Советы ниже не являются 100% панацеей от парсинга, но могут настолько усложнить "жизнь" парсерам (особенно неофитам в этом деле), что встанет вопрос о целесообразности продолжения этого дела. Плюс, скорость парсинга тоже имеет значение (особенно в товарной сфере) и если у вас на 1 товар будет уходить, условно говоря, 20 секунд, то ценность сбора данных за 2-3 недели вызывает вопросы. Мы стараемся получать данные по Интернет- магазинам не чаще чем 1 товар в 3-4 секунды (это быстрее анализа человеком, но при этом не создает невыносимую нагрузку на сервера).

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

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

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

Как правило, эти парсинговые программы написаны для того, чтобы извлечь конкретную информацию с вашего сайта, такую как статьи, результаты поиска, сведения о товарах или информацию об исполнителе и альбоме. Обычно люди парсят веб-сайты для получения определенных данных, чтобы повторно использовать их на своем собственном сайте (и зарабатывать деньги на вашем контенте!) либо создавать альтернативные интерфейсы для вашего сайта (например, мобильные приложения), или даже просто для частных исследований или анализа. Например, к нам приходят заказчики для мониторинга цен своих конкурентов. Посмотрите нашу статью на этом ресурсе, где мы рассказываем более подробно наш опыт.

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

Например: если на вашем сайте есть функция поиска, такой парсер может отправить HTTP-запрос для поиска (например, подставить название товара - мы так част делаем), а затем получить все ссылки на результаты и их заголовки с HTML-страницы поисковой выдачи, иногда срабатывая сотни раз для сотен различных поисков, чтобы получить именно результаты поиска ссылок и их заголовки. Вот самые распространенные примеры:

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

Неудивительно, что профессиональным поставщикам услуг парсинга (таким как мы 😀) труднее всего противостоять, но если вы сделаете парсинг вашего сайта трудоемким и время-затратным, то эти компании (и люди, которые платят им за это) могут посчитать парсинг вашего сайта нерентабельным. И это правда, бывали случаи, когда мы отказывались от парсинга ресурсов – слишком сложно.

Хотя технически это не является парсингом, но это всё равно проблема, поскольку мобильные приложения (Android и iOS) могут встраивать ваш сайт и даже внедрять пользовательские CSS и JavaScript, таким образом полностью изменяя внешний вид сайта и отображая только нужную информацию, такую как сам контент статьи или список результатов поиска, а также скрывать верхние и нижние колонтитулы или рекламу.

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

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

Некоторые общие методы обнаружения и ограничения парсеров:

Регулярно проверяйте логи и, в случае подозрительной активности, свидетельствующей об автоматическом доступе (парсинге, например), множестве запросов с одного и того же IP-адреса, блокируйте или ограничивайте доступ.

Вот некоторые идеи:

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

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

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

Например, если вы получаете много запросов с одного IP-адреса, все используют один и тот же User-Agent, размер экрана (определяется с помощью JavaScript), и пользователь (в данном случае парсер) всегда нажимает на кнопку одинаково и с регулярными интервалами, то очевидно, что это парсер, и вы можете временно заблокировать подобные запросы (например, блокировать все запросы с этим пользовательским агентом и размером экрана, приходящим с этого конкретного IP-адреса), и, таким образом, вы не будете доставлять неудобства реальным пользователям, которые находятся на этом IP-адресе, как бывает при общем подключении к интернету.

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

Всё это будет эффективно в отношении парсеров, использующих JavaScript, поскольку вы можете получить от них много информации.

Смежные вопросы по Security Stack Exchange:

Самая простая реализация ограничения трафика — блокировка доступа на определенное время, однако капчу можно использовать эффективнее, см. ниже раздел «Капчи».

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

Чтобы избежать заскриптованной регистрации множества учетных записей, вам необходимо:

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

Иногда парсеры запускаются из служб веб-хостинга, таких как Amazon Web Services, Google App Engine или VPS. Ограничьте доступ к вашему веб-сайту (или поставьте капчу) для запросов, исходящих с IP-адресов таких хостингов. Вы также можете заблокировать доступ с IP-адресов парсинг-сервисов.

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

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

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

Вместо этого покажите дружелюбное сообщение об ошибке, которое не сообщит парсеру, чем именно он себя выдал. Например так:

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

Капчи (CAPTCHAs, «полностью автоматизированные тесты для распознания компьютеров и людей») очень эффективны против парсеров. К сожалению, они также очень эффективны для раздражения ваших пользователей.

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

Что нужно знать при использовании капчи:

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

Однако это плохо для программ чтения с экрана, поисковых систем, производительности и почти всего остального. Также это незаконно в некоторых странах (из-за ограничения доступности, например, закона об американцах-инвалидах). Такой способ защиты легко обойти с помощью OCR, так что не стоит его использовать.

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

Это будет неэффективно, если:

Убедитесь, что вы, даже непреднамеренно, не выставляете какой-либо API. Например, если вы используете AJAX или сетевые запросы из Adobe Flash или Java-апплетов (не дай Бог!), то для загрузки ваших данных достаточно просто просмотреть сетевые запросы со страницы и выяснить, куда они направлены, а затем перепроектировать их и использовать эти конечные точки (endpoints, рабочие станции и другие конечные точки своей сети) в программе парсера. Убедитесь, что вы обфусцируете свои endpoints и затрудняете их использование другими.

Учитывая, что HTML-парсеры при извлечении контента опираются на идентифицируемые шаблоны в HTML, можно преднамеренно менять эти шаблоны, чтобы сломать парсеры или запутать их. Большинство из этих советов также актуальны для поисковых “пауков” и инструментов захвата экрана.

Парсеры, которые напрямую обрабатывают HTML, извлекают содержимое из определенных идентифицируемых частей вашей HTML-страницы. Например: если все страницы на вашем сайте имеют div-идентификатор article-content с текстом статьи, то для получения текста всех статей с вашего сайта достаточно написать скрипт для посещения всех страниц статьи на вашем сайте и извлечь текст содержимого article-content div с каждой страницы статьи.

Если вы часто меняете HTML и структуру своих страниц, такие парсеры могут не сработать.

Однако не следует забывать:

По сути, убедитесь, что для скрипта не так просто будет найти настоящее содержимое для каждой подобной страницы.

Смотрите также: Как запретить сканерам, зависящим от XPath, получать содержимое страницы, и узнайте, как это можно реализовать на PHP.

В принципе, это совет похож на предыдущий. Использование разного HTML-кода для разного местоположения (определяется по IP-адресу) нарушит работу парсеров. Например, если кто-то пишет мобильное приложение, которое собирает данные с вашего сайта, то в начале оно будет работать нормально. Но? как только приложение окажется у реальных пользователей, в его работе тут же возникнут неполадки, поскольку эти пользователи могут находиться в разных странах и, таким образом, получать разный HTML, который встроенный парсер не поддерживает.

Пример: на вашем веб-сайте есть функция поиска example.com/search?query=somesearchquery, которая возвращает следующий HTML-код:

(И далее множество идентично структурированных div с результатами поиска.)

Как вы уже догадались, такие данные легко извлечь: все, что нужно сделать парсеру — это нажать на URL-адрес поиска с помощью запроса и извлечь нужные данные из возвращенного HTML-кода. В дополнение к периодическому изменению HTML, как описано выше, вы также можете оставить старую разметку со старыми идентификаторами и классами, скрыть ее с помощью CSS и заполнить ее ложными данными, тем самым запутав парсер. Вот как можно изменить страницу результатов поиска:

(Более реальные результаты поиска следуют далее)

Это значит, что парсеры, написанные для извлечения данных из HTML на основе классов или идентификаторов, по-прежнему будут работать, но получат поддельные данные или даже рекламу, данные, которые реальные пользователи никогда не увидят, поскольку они скрыты с помощью CSS.

Относительно прошлого примера, вы можете добавить невидимые элементы-приманки в ваш HTML-код, чтобы ловить парсеры. Например, такой элемент можно добавить на ранее описанную страницу результатов поиска:

(Фактические, реальные результаты поиска следуют далее.)

Парсер, написанный для получения всех результатов поиска, выберет этот результат, как и любые другие реальные результаты поиска на странице, и перейдет по ссылке в поисках нужного контента. Настоящий человек никогда даже не увидит его (из-за того, что он скрыт с помощью CSS) и не пойдет по ссылке. Настоящий и желанный бот, такой как Google или Яндекс, также не будет посещать ссылку, потому что вы запретили это (/scrapertrap/) в своем файле robots.txt (не забывайте об этом!)

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

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

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

Часто “лениво” написанные парсеры, не отправляют заголовок User Agent вместе со своим запросом, в отличии от браузеров и сканеров поисковых систем. Если вы получили запрос, в котором отсутствует заголовок User Agent, можно показать капчу или просто заблокировать или ограничить доступ. (Или предоставьте поддельные данные, как описано выше, или что-нибудь еще…)

Подделывать данные — банально, но в качестве меры против плохо написанных парсеров это можно применять.

В некоторых случаях парсеры будут использовать User Agent, который не используется реальными браузерами или поисковиками, например:

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

В дополнение к прошлому совету, ещё можно проверить наличие [Referer] (заголовок https://en.wikipedia.org/wiki/HTTP_referer) (да, это Referer, а не Referrer), так как плохо написанные парсеры могут его не отправлять или всегда отправляйте одно и то же (иногда это “google.com”). Например, если пользователь заходит на страницу статьи со страницы результатов поиска, убедитесь, что заголовок Referer присутствует и указывает на эту страницу результатов поиска.

Остерегайтесь следующего:

Опять же, хорошо подойдет в качестве дополнительной меры против плохо написанных парсеров.

Настоящий браузер (практически всегда) запрашивает и загружает ресурсы, такие как изображения и CSS. HTML-парсеры и сканеры этого делать не будут, поскольку их интересуют только реальные страницы и их содержание.

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

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

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

Например: когда пользователь выполняет поиск, установите уникальный идентификационный файл cookies. При просмотре страниц результатов проверьте этот файл cookie. Если пользователь открывает все результаты поиска (это можно узнать из cookies) — это парсер.

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

Обратите внимание, что если вы используете JavaScript для установки и получения cookie, вы заблокируете парсеры, которые не запускают JavaScript, так как они не могут получить и отправить cookies с помощью своего запроса.

Вы можете использовать JavaScript + AJAX для загрузки вашего контента после загрузки самой страницы. Это сделает контент недоступным для анализаторов HTML, которые не поддерживают JavaScript. Довольно часто такой способ является эффективным сдерживающим фактором для начинающих и неопытных программистов, пишущих парсеры.

Необходимо знать:

Если для загрузки данных вы используете Ajax и JavaScript, замаскируйте передаваемые данные. Например, вы можете кодировать свои данные на сервере (с помощью чего-то простого, например base64 или более сложного, с несколькими уровнями маскировки, сдвига битов и, возможно, даже шифрования), а затем после получения декодировать и отображать их через Ajax на клиенте. Это будет означать, что кто-то, проверяющий сетевой трафик, не сразу увидит, как работает ваша страница и загружает данные, и кому-то будет сложнее напрямую запросить данные запроса у ваших конечных точек, поскольку им придется перепроектировать ваш алгоритм маскировки данных.

И все-таки у этого способа есть несколько недостатков:

Например, популярный CloudFlare обеспечивает защиту от ботов и взлома, которую вам просто нужно включить, как и AWS. Существует также mod_evasive, модуль для Apache, который позволяет легко реализовать ограничение скорости.

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

Они знают, как бороться с нарушением авторских прав, и могут отправить письмо о прекращении и отказе от них. Также в этом отношении помогает DMCA. Такой подход используют Stack Overflow и Stack Exchange (это в основном рекомендация для США).

Это может показаться контрпродуктивным, но вы могли бы сделать ваши данные открытыми и требовать указания авторства и ссылки на ваш сайт. Может быть, даже получать за это реальную плату… Опять же, Stack Exchange предоставляет API, но с указанием авторства.

Из нашего опыта написания парсеров и помощи людям в написании парсеров, наиболее эффективными методами являются:

Удачи в опасном путешествии по защите вашего контента!..