Как защититься от парсинга сайтов и Интернет- магазинов

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

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

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

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

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

• Поисковые боты, такие как бот Google, или «копиры» веб-сайтов, такие как HTtrack. Они посещают ваш сайт и рекурсивно переходят по ссылкам на другие страницы для получения данных. Иногда они используются при целенаправленном парсинге для получения конкретных данных, часто в сочетании с анализатором HTML для извлечения нужных данных с каждой страницы.
• Сценарии командной строки: иногда для парсинга используются общие инструменты Unix: Wget или Curl для загрузки страниц и Grep (Regex) для извлечения нужных данных, обычно с использованием сценариев командной строки. Это самый простой тип парсера, а также самый неустойчивый (никогда не пытайтесь анализировать HTML с помощью регулярных выражений! :). В общем, это самый легкий для блокировки вид парсера.
• HTML-сканеры и парсеры, основанные на Jsoup, Scrapy, а также множество других. Как и в сценариях с использованием командной строки на основе регулярных выражений, они работают, извлекая данные из ваших страниц на основе шаблонов в вашем HTML, при этом игнорируя все остальное.

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

• Парсеры экрана, собранные на Selenium или PhantomJS, фактически открывают ваш сайт в реальном браузере, запускают JavaScript, AJAX и т.д, а затем получают желаемый текст с веб-страницы. Как правило, они действуют одним из следующих способов:
  • Получение HTML-кода из браузера после загрузки вашей страницы и запуска JavaScript, а затем использование анализатора HTML для извлечения нужных данных или текста. Такие парсеры являются наиболее распространенными, и поэтому против них работают многие методы для защиты от HTML-парсеров/сканеров.
  • Сохранение снимков отрендеренных страниц, а затем использование оптического распознавания символов для извлечения нужного текста. Такой способ применяется крайне редко и только специализированными парсерами, которым действительно нужны ваши данные (но все это будет медленно, стоит отметить).

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

• Парсинг-сервисы, например ScrapingHub или Kimono. На самом деле, существуют люди, чья работа заключается в том, чтобы выяснить, как парсить ваш сайт и извлечь контент для использования третьими лицами. Они используют обширные сети прокси-серверов и постоянно меняющиеся IP-адреса, чтобы обойти ограничения и блокировки, поэтому защититься от них особенно проблематично.

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

• Интеграция вашего сайта в страницы других сайтов с помощью фреймов или встраивание его в мобильные приложения.

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

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

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

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

Как обнаружить и остановить парсинг?

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

Следите за своими логами и статистикой трафика; ограничивайте доступ, при обнаружении подозрительной активности:

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

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

• Ограничение трафика:

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

• Выявление подозрительной активности:

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

• Не ограничивайтесь идентификацией только лишь по IP-адресу — используйте и другие индикаторы:

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

• Скорость заполнения формы пользователем и место нажатия на кнопку;
• С помощью JavaScript вы можете собрать много информации, такой как размер / разрешение экрана, часовой пояс, установленные шрифты и т.д. Всё это можно использовать для идентификации пользователей.
• Заголовки Http и их порядок, в особенности User-Agent.

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

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

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

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

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

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

Требуйте регистрации и входа

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

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

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

• Требовать адрес электронной почты для регистрации и проверять его, отправив ссылку, переход по которой активирует учетную запись. Разрешить регистрировать только одну учетную запись на один адрес электронной почты.
• Требуйте решения капчи при регистрации/создании учетной записи.

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

Блокируйте доступ с IP-адресов облачного хостинга и парсинг-сервисов

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

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

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

При блокировке, ваше сообщение об ошибке не должно быть информативно для парсера

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

• Слишком много запросов с вашего IP-адреса, повторите попытку позже.
• Ошибка, заголовок User Agent отсутствует!

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

• Извините, что-то пошло не так. Вы можете связаться со службой поддержки через helpdesk@example.com, если проблема не устранена.

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

Используйте капчи, если вы подозреваете, что к вашему сайту обращается парсер

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

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

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

• Нет необходимости самостоятельно разрабатывать капчи. Воспользуйтесь reCaptcha от Google ‒‒ это намного проще и удобнее для пользователя, чем какое-то размытое и искаженное текстовое решение, которое вы можете придумать самостоятельно (пользователям часто нужно только поставить галочку). Для парсера такая капча намного сложнее, чем простое изображение с вашего сайта.
• Не включайте решение для капчи в разметку HTML ‒‒ я действительно видел один сайт, который имел решение для капчи на самой странице (хотя и довольно хорошо скрытое), что делало её довольно бесполезной. Не стоит делать что-то подобное. Опять же, используйте сервис а-ля reCaptcha, и у вас не будет таких проблем (при условии его правильного использования).
• Капчи могут быть решены массово: существуют сервисы по решению капчей, где реальные люди за низкую плату решают капчи. Опять же, использование reCaptcha является хорошей идеей, поскольку у них есть защита (например, относительно короткое время, которое пользователь имеет для того, чтобы решить капчу). Такой вид сервиса вряд ли будет использоваться, если только ваши данные не являются действительно ценными.

Подавайте текстовый контент в виде изображения

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

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

Вы можете сделать что-то подобное со спрайтами CSS, но там будут аналогичные проблемы.

Не раскрывайте свой полный набор данных:

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

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

• Бот/скрипт не нуждается в полном наборе данных.
• Ваши статьи обслуживаются с URL-адреса, который выглядит примерно так example.com/article.php?articleId=12345. Этот адрес (и подобные ему адреса) позволит парсерам просто перебирать все articleIds и, таким образом, запрашивать все статьи.
• Существуют и другие способы найти все статьи, например, написать скрипт для перехода по ссылкам внутри статей, которые ведут к другим статьям.
• Поиск что-то вроде «и» или «а» может выявить почти все, так что об этом нужно знать. (Вы можете избежать этого, только вернув по запросу 10 или 20 результатов).
• Вам необходимы поисковые системы для поиска вашего контента.

Скрывайте свои API, endpoints и тому подобное:

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

Противодействие парсерам и сканерам

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

Чаще меняйте HTML-код

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

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

• Вы можете часто изменять идентификаторы и классы элементов в своем HTML, причем автоматически. Так что, если ваш div.article-content превращается во что-то вроде div.a4c36dda13eaf0 и меняется каждую неделю, парсер сначала будет работать нормально, но через неделю сломается. Обязательно меняйте длину ваших идентификаторов/классов, иначе парсер будет использовать div.[any-14-characters] для поиска нужного элемента. Остерегайтесь других подобных дыр. 
• Если невозможно найти желаемый контент по структуре разметки, парсер сделает это по структуре всего HTML-кода. Если все ваши страницы статьи сделаны по одному такому шаблону, что каждый div внутри div, который идет после тега h1, является содержимым статьи, то на на основе этого парсеры легко получат содержимое статьи. Опять же, чтобы избежать этого, вы можете добавлять/удалять дополнительную разметку вашего HTML, периодически и случайно. Например, добавление дополнительных divs или spans. При современной обработке HTML на стороне сервера это не составит большого труда.

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

• Такой процесс будет сложно реализовать, поддерживать и отлаживать.
• Вы будете мешать кэшированию. Особенно, если вы измените идентификаторы или классы ваших элементов HTML, это потребует соответствующих изменений в ваших файлах CSS и JavaScript. А, значит, они будут повторно загружаться браузером после каждого изменения. Это приведет к увеличению времени загрузки страницы для повторных посетителей и увеличению нагрузки на сервер. Впрочем, если вводить такие изменения раз в неделю, то это не доставит больших проблем.
• Умные парсеры все равно смогут получить ваш контент, сделав вывод, где фактически находится содержимое. Например, предполагая, что большой отдельный блок текста на странице, вероятно, является настоящей статьей, можно находить и извлекать нужные данные со страницы. Boilerpipe делает именно так.

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

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

Меняйте HTML-код в зависимости от местоположения пользователя

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

Часто меняйте свой HTML, активно «запутывайте» парсеры

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

< div class =»search-result»>

 <h3 class=»search-result-title»>Stack Overflow стал самым популярным в мире веб-сайтом для вопросов и ответов по программированию</h3>

 <p class=»search-result-excerpt»>В настоящее время веб-сайт Stack Overflow стал самым популярным веб-сайтом для вопросов и ответов по программированию, в котором содержится 10 миллионов вопросов и множество пользователей, которые …</p>

<a          class»search-result-link» href=»/stories/stack-overflow-has-become-the-most-popular»>Подробнее</а> 

</div>

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

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

<div class=»the-real-search-result»>

<h3 class=»the-real-search-result-title»>Stack Overflow стал самым популярным в мире веб-сайтом для вопросов и ответов по программированию </h3>

 <p class=»the-real-search-result-excerpt»>В настоящее время веб-сайт Stack Overflow стал самым популярным веб-сайтом для вопросов и ответов, в котором содержится 10 миллионов вопросов и много пользователей, которые … </p>

            <a class»the-real-search-result-link» href=»/stories/stack-overflow-has-become-the-most-popular»>Подробнее</a> 

</div>

<div class=»search-result» style=»display:none»>

 <h3class=»search-result-title»>Посетите example.com сейчас, чтобы узнать все последние новости, связанные со Stack Overflow!</h3>

 <p class=»search-result-excerpt»>EXAMPLE.COM НАСТОЛЬКО УДИВИТЕЛЬНЫЙ, ПОСЕТИТЕ СЕЙЧАС! (Реальные пользователи вашего сайта никогда не увидят этого, только парсеры.)</p>

 <a class»search-result-link» href =»http://example.com/»>Посетите сейчас!</a> 

</div>

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

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

Запутайте парсер: вставьте поддельные, невидимые данные-приманку на свою страницу

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

<div class=»search-result» style=»display:none»>

 <h3 class=»search-result-title»>Этот результат поиска здесь для предотвращения парсинга</h3>

 <p class=»search-result-excerpt»>Если вы человек и видите это, пожалуйста, игнорируйте его. Если вы парсер, нажмите на ссылку ниже 🙂

 Обратите внимание, что нажатие на ссылку ниже заблокирует доступ к этому сайту на 24 часа.</p>

 <a class»search-result-link» href=»/scrapertrap/scrapertrap.php»>Я парсер!</a> 

</div>

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

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

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

• Не забудьте запретить ваш honeypot (/scrapertrap/) в файле robots.txt, чтобы роботы поисковых систем не попадали в него.
• Для повышения эффективности лучше всего сочетать этот способ с предыдущим советом частого изменения HTML-кода.
• Постоянно изменяйте ловушки, иначе парсеры научатся избегать их. Измените адрес приманки и текст. Необходимо рассмотреть возможность изменения встроенного CSS, используемого для сокрытия, и использовать вместо этого атрибут ID и внешний CSS, поскольку парсеры научатся избегать всего, что имеет style атрибут с CSS, который используется для сокрытия содержимого. Попробуйте периодически включать-выключать приманку, чтобы парсер выходил из строя не сразу, а через какое-то время.
• Помните, что злоумышленники могут публиковать что-то наподобие [img]http://yoursite.com/scrapertrap/scrapertrap.php[/img] где-нибудь на форуме (или в другом месте), и, таким образом, обычные пользователи получат отказ в обслуживании, когда они посещают этот форум, а их браузер переходит на ваш адрес приманки. Таким образом, предыдущий совет по изменению URL-адреса важен вдвойне.

“Скармливайте” парсеру поддельные и бесполезные данные

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

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

Не принимать запросы, если User Agent пуст или отсутствует

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

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

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

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

• «Mozilla» (И всё, больше ничего. Я видел несколько вопросов парсинге с такими User Agent. Настоящий браузер никогда не будет указывать только одно слово);
• «Java 1.7.43_u43» (по умолчанию в HttpUrlConnection Java используется что-то вроде этого);
• «BIZCO EasyScraping Studio 2.0»;
• «wget», «curl», «libcurl», … (Wget и cURL иногда используются для базового анализа).

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

Проверьте заголовки Referer

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

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

• Реальные браузеры тоже не всегда отправляют его;
• Referer легко подделать.

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

Если браузер не запрашивает ресурсы (CSS, изображения) — это не настоящий браузер

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

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

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

Используйте и запрашивайте cookies; это пригодится  для отслеживания действий пользователей и парсеров

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

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

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

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

Используйте связку JavaScript + Ajax для загрузки контента

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

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

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

Маскируйте свою разметку, сетевые запросы от скриптов и все остальное

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

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

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

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

Нетехнические способы борьбы:

Ваш хостинг-провайдер может предоставлять защиту от ботов и парсеров

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

Попросите людей не парсить ваши данные, и некоторые будут уважать ваше желание

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

Найти адвоката 🙂

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

Сделайте ваши данные открытыми, предоставьте API

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

Прочие способы:

• Найдите баланс между удобством использования для реальных пользователей и устойчивостью к ботам: все, что вы делаете, так или иначе негативно повлияет на работу реальных пользователей, поэтому вам нужно будет искать компромисс.
• Не забывайте про свой мобильный сайт и приложения: если у вас есть мобильная версия вашего сайта, будьте осторожны, боты тоже могут её парсить. Если у вас есть мобильное приложение, оно также может попасть под атаку парсеров. Можно проверить сетевой трафик, чтобы определить конечные точки REST, которые он использует.
• Если вы используете специальную версию вашего сайта для конкретных браузеров, например, урезанную версию для более старых версий Internet Explorer, не забывайте, что боты тоже могут её видеть и сканировать.
• Комбинируйте эти советы, и выберите то, что для вас работает лучше.
• Парсеры могут сканировать другие парсеры: если существует один веб-сайт, на котором отображается содержимое, взятое с вашего сайта, другие парсеры могут взять его с сайта этого парсера.

Какой самый эффективный способ?

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

• Частое изменение разметки HTML
• Ловушки и поддельные данные
• Использование замаскированного JavaScript, AJAX и файлов cookie
• Ограничение скорости при обнаружении парсера и последующая блокировка.

Читайте также:

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

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