Как защитить свой сайт от парсинга данных. Практические советы

Меня зовут Максим Кульгин и моя компания xmldatafeed занимается парсингом сайтов в России порядка четырех лет. Ежедневно мы парсим более 500 крупнейших интернет-магазинов в России и на выходе мы отдаем данные в формате Excel/CSV и делаем готовую аналитику для маркетплейсов.

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

Отдельно хочу подчеркнуть, что 100% защиты от парсинга открытых данных в природе, наверное, не существует. Но используя комбинацию подходов вы можете очень сильно усложнить процесс сбора данных. Если данных много и они часто меняются (попробуйте парсить, например, АлиЭкспресс), то парсинг может стать просто нецелесообразным (или очень затратным мероприятием). Перечисленные ниже методы бесплатные в реализации (разве что оплата труда программиста вашего сайта), но на рынке есть и платные варианты. Например, вы можете потратить 10 минут и включить CloudFlare (тариф 20$, защита от ботов включена). В этом случае особо назойливые парсеры будут получать капчу (кстати, CloudFlare использует hCaptcha, которая, как считаю наши разработчики, более сложная чем reCaptcha). В конечном счете, совокупность механизмов защиты поможет защитить сайт от паразитной нагрузки, которые зачастую создают сотни парсеров, написанных малограмотными студентами-программистами, не думающих о последствиях.

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

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

Парсинг также известен как: веб-парсинг (webscraping), считывание данных с экрана (screenscraping), добыча веб-данных (web data mining), сбор веб-данных (web harvesting) или извлечение веб-данных (web data extraction). Чтобы препятствовать парсингу, полезно знать, как работают парсеры и что мешает им работать эффективно — об этом и пойдет речь в данной статье.

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

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

Таким образом, например, если на вашем сайте есть функция поиска, такой парсер может отправить 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-адресам, используемым поставщиками виртуальных частных сетей или прокси-серверов, так как парсеры могут использовать такие прокси-сервера с целью избежания того, чтобы их многочисленные запросы были замечены администраторами или владельцами сайтов.

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

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

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

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

Капчи («Completely Automated Test to Tell Computers and Humans apart» — «Полностью автоматизированный публичный тест Тьюринга для различения компьютеров и людей») очень эффективны против парсеров. К несчастью, они при этом очень эффективно раздражают пользователей.

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

Моменты, о которых нужно помнить при использовании капч:

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

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

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

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

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

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

Так как HTML-анализаторы работают посредством извлечения контента из веб-страниц на основе поддающихся распознаванию шаблонов в HTML-коде, мы можем намеренно изменить эти шаблоны, чтобы сломать такие парсеры или даже обмануть их. Большинство из этих советов также применимы к другим парсерам наподобие «пауков» и экранных парсеров.

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

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

Нужно иметь в виду следующее:

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

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

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

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

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

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

В дополнение к предыдущему примеру вы можете добавить невидимые элементы-приманки в свою HTML-разметку, чтобы «ловить» парсеры. Пример разметки, которую можно было бы добавить к описанной ранее веб-странице с результатами поиска:

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

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

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

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

Зачастую недостаточно качественно разработанные парсеры не будут отправлять заголовок User-Agent в своих запросах, в то время как все браузеры и поисковые роботы делают это.

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

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

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

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

В дополнение к предыдущему параграфу вы можете также проверить заголовок Referer (да, именно Referer, а не Referrer), так как некачественные парсеры могут не отправлять его или всегда отправлять один и тот же — иногда это может быть «google.com». К примеру, если пользователь приходит на веб-страницу статьи со страницы результатов поиска по сайту, проверьте, что заголовок Referer присутствует и указывает на эту страницу с результатами поиска.

Обратите внимание, что:

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

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

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

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

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

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

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

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

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

Имейте в виду, что:

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

Однако у подобных приемов есть несколько недостатков:

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

Может быть стоит попросить людей, например в условиях вашего пользовательского соглашения, не парсить ваш сайт. Некоторые люди действительно прислушаются к вашим словам и не будут без разрешения собирать данные на вашем сайте. Но должен признать, что доброе слово с «кулаком» лучше, чем просто доброе слово :)

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

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

Наиболее эффективными методами считаются: