Парсим сайты с защитой от ботов

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

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

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

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

Давайте попробуем классифицировать способы, которые используют сайты, чтобы отфильтровать автоматические запросы.

• Самописные решения.

• Готовые модули для веб-cервера. По запросу “nginx bots protection module” находится много разных решений, и платных, и бесплатных, и открытых.

• Сторонний сервис, специализирующийся на фильтрации автоматического трафика.

Для начала, давайте разберемся, что о нас известно серверу на той стороне, вне зависимости от того, каким из способов реализована проверка.

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

Заголовки HTTP. По ним можно определить браузер, используемый язык интерфейса, и некоторые другие параметры. В них же передаются Cookies, с их помощью которых можно сопоставить запросы из одного браузера. Так же с их помощью можно определить, выполняется ли на клиенте код на JavaScript.

Особенности реализации TCP, TLS и HTTP/2. Суть в том, что HTTP — это прикладной, самый последний уровень модели OSI, а на уровнях ниже используются протоколы, реализация которых в разных программах может иметь особенности.

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

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

Я установил Microsoft Network Monitor и посмотрел, как выглядят запросы из разных инструментов в виде кадров канального уровня. Приводить целиком не буду, вот фрагмент:

Первое интересное наблюдение: IP-пакет содержит параметр TTL. Начальное значение этого параметра для TCP протокола отличается в разных операционных системах. Мне удалось найти такие значения для современных версий:

• Windows: 128
• Linux: 64
• Android: 64
• iOS: 64

Теоретически, можно проверить, соответствует ли значение заголовка User-Agent значению TTL IP-пакетов.

Второе интересное наблюдение: разные программы используют разные версии TLS для доступа к одному и тому же ресурсу. В частности, в моих экспериментах Вивальди всегда использовал версию 1.0, а Fiddler — версию 1.2.

Уверен, что опытный сетевой инженер найдет и другие закономерности.

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

Теперь рассмотрим наши пункты подробнее.

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

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

Чуть сложнее. Могут быть разные вариации непосредственно алгоритма, но суть состоит в проверке того, что заголовки корректно передаются и обрабатываются клиентом. В частности, может проверятся обработка клиетом заголовка Set-Cookie. Может проверяться соответствие значений заголовков User-Agent, Accept и Accept-Encoding. Браузер, не принимающий gzip, — возможно, не браузер.

Также может быть реализована проверка того, что на клиенте включен JavaScript.

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

Может быть установлено ограничение по количеству запросов с одного IP-адреса за единицу времени.

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

Случайный сайт в интернете, которому у нас нет оснований не доверять, говорит, что на рынке веб-серверов сложилась такая ситуация:

Nginx на первом месте, и он поддерживает сторонние модули. Apache на втором месте, и он тоже поддерживает сторонние модули. Часто они работают вместе, Nginx работает как reverse proxy и обрабатывает запросы к серверу на 80 и 443 портах, отдает статику и занимается кэшированием, а запросы на динамические страницы передаёт Apache.

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

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

Первым результатом Гугл выдал DataDome Nginx module. Документация говорит следующее: при получении запроса модуль сделает запрос к DataDome API, и, в зависимости от ответа, заблокирует запрос или продолжит его обработку. Модуль может сочетаться со скриптом, который добавляется на все страницы сайта. Скрипт выполняет дополнительные проверки на клиенте.

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

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

Следующий результат — Nginx Bad Bot and User-Agent Blocker, Spam Referrer Blocker, Anti DDOS, Bad IP Blocker and Wordpress Theme Detector Blocker. Тут уже доступен исходный код, и можно разобраться, как модуль работает. Если кратко — то работает на основе черных и белых списков. Анализируются не только IP-адреса, но и значения заголовков User-Agent, Refferrer и других. Возможно, дополнительно используются некоторые эвристики, но я в процессе беглого просмотра их не нашел.

Существуют сторонние сервисы, которые позволяют блокировать автоматические парсеры. Как правило, их функциональность этим не ограничивается, и они предлагают и другие полезные вещи: CDN, защиту от DoS и DDoS, кэширование, управление DNS, хостинг. Самым популярным таким сервисом является Cloudflare.

Сам Cloudflare даёт такую схему работы своего сервиса:

По сути, происходит следующее: владелец сайта в панели управления доменом меняет значения NS-записей на DNS-сервера Cloudflare. После этого запросы на преобразование имени (символьного адреса) хоста в его IP-адрес возвращают IP-адреса серверов Cloudflare. Соответственно, и запросы к сайту направляются на сервера Cloudflare.

Получив HTTP-запрос, сервер Cloudflare решает, заблокировать его, выполнить автоматическую проверку на клиенте на предмет “бот — не бот”, выполнить проверку, которая требует взаимодействия с пользователем (капча) , либо продолжить обработку запроса.

Что касается процесса первоначального анализа запроса, то серверу Cloudflare доступна вся информация о запросе, которую мы рассматривали выше. Кроме того, доступны разного рода статистические данные по всем запросам к серверам Cloudflare, а не только запросам к сайту одного клиента.

Рассматиривая Cloudflare, мы обязательно должны рассмотреть и проверку на клиенте. Это то, что в при обсуждении сервиса принято называть словом “challenge”. Суть его такова: в ответ на запрос к сайту Cloudflare отдает специальным образом сформированную страницу, где есть какой-то обфусцированный JavaScript. Этот JavaScript реализует обращения к разным API браузера, включая возможность делать ajax-запросы, производит вычисления, проверяет наличие Selenium-драйвера, в общем, проверяет, что браузер ведет себя как браузер, а не как другая реализация интерпретатора JavaScript. В зависимости от результатов этой проверки, разрешается или блокируется доступ к запрошенной странице. Конкретный алгоритм проверки меняется со временем.

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

• Будем использовать готовые решения для работы с HTTP запросами и DOM.
• Будем использовать распространенные и согласованные заголовки Accept, Accept-Encoding, User-Agent.
• Будем использовать сессии, под ними подразумевается корректная обработка заголовка Set-Cookie и хранение значнеия Cookie между запросами.
• В случае, если запросы к конкретному сайту блокируются, будем использовать браузер для получения HTML-кода страниц с этого сайта. Весь остальной процесс не изменяется.

Поскольку основная наша платформа — .NET, в качестве основного инструмента для работы с запросами и DOM будем использовать AngleSharp. Эту часть я опишу в виде псевдокода, потому что в этой статье мы не изучаем AngleSharp, а разбираемся, как пройти проверку Cloudflare.

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

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

Что же, несколькими строками кода мы решили вопрос с сессией и заголовками. Но больше всего нас интересует метод LoadDocumentWithSolverProxy(string url) . Он должен каким-то образом пройти проверку Cloudflare. На самом деле, не только проверку Cloudflare, но и другие подобные проверки.

Пройти проверку Cloudflare сложно, но возможно. Способы это сделать сводятся к следующим:

• Слать запросы непосредственно на сервер, обслуживающий сайт, в обход Cloudflare. Просто, но не всегда возможно. Подразумевается, что тот, кто настраивал защиту от ботов, поленился, ошибся или не до конца разобрался, и не запретил обращения к серверу мимо Cloudflare.
• Забирать страницы из кэша Гугла.
• Воспользоваться готовым программным решением для прохождения проверки. Например, FlareSolverr.
• Производить парсинг с помощью браузера, управляемого кодом. По сути, использовать инструменты для автоматического сквозного тестирования: Puppeteer, Playwright, Selenium.
• Воспользоваться платным сервисом, который умеет проходить проверки.
• Разобраться, как работает защита, провести реверс-инжиниринг, и проходить её наиболее оптимальным способом, не запуская ресурсозатратные браузеры.

Я попробовал почти все, и сейчас расскажу о результатах.

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

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

Но способ рабочий. Шаблон адреса такой: https://webcache. googleusercontent. com/search? q=cache:{url_of_requested_page_here}

Что касается готовых решений, я попробовал следующие:

• CloudflareSolverRe. Подход, примененный автором, не использует браузерный движок. Ответ сервера разбирается средствами C#, и на C# воспроизводится алгоритм решения задачи. К сожалению, не работает с 2020 года, когда Cloudflare поменяла алгоритм проверки. Он стал более сложным, и теперь состоит из нескольких шагов, и кроме того использует не только вычисления на JavaScript, но и взаимодействие с API браузера. Подход не оправдал себя, потому что любое изменение в алгоритме проверки приводит к необходимости менять алгоритм её обхода, а то и полностью его переписывать.

• FlareSolverr. На первый взгляд выглядит рабочим. Есть свежие (вчерашние на момент написания статьи) коммиты и живой баг-трекер. Когда я его скачал и запустил, он не прошел проверку на первом же сайте. Я пошел разбираться и выяснил, для разработки используется Python, а для прохождения проверок — Selenium. В процессе я обнаружил такой код:

Ниже производится поиск элементов по селектору на странице, этот код я не привожу. Элемент есть — ждем, элемента нет — возвращаем результат.

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

Следующим я попробовал Selenium. Это уже посложнее, чем скачать и запустить, речь про код на C#, который обрабатывает запросы вида “http://localhost/proxy? url=https://nowsecure. nl”, загружает нужный адрес в запущенном браузере, ждет, пока пройдет проверка, и возвращает результат. Взаимодействие с браузером осуществляется при помощи Selenium-драйвера.

Что же, на этом этапе выяснилось, что

• Проверка Cloudflare понимает, что браузер управляется драйвером.
• Это на самом деле несложно
• Алгоритм определения этого, который используется Cloudflare, сложнее, чем просто проверка свойства navigator. webdriver.
• Существует версия драйвера, которая, теоретически, не детектируется.
• Версия, которая, теоретически, не детектируется, не определяется при первом посещении сайта запущенным браузером, но детектируется со второго посещения. Почему — непонятно. Браузер нужно постоянно перезапускать.
• Алгоритм детектирования Selenium меняется с течением времени, и иногда драйвер начинает определяться. Тогда нужно ждать выхода следующей версии.

В общем, я почти повторил функциональность FlareSolverr на C#. Соответственно, недостатки решения на Selenium относятся и к FlareSolverr, но они дали о себе знать только при более тесном знакомстве с используемым подходом.

Из платных сервисов я попробовал scrapingbee. com и остался вполне доволен результатом. Возможно, для парсинга небольшого количества страниц это оптимальное решение. По крайней мере, стоит оценить затраты на платный сервис и затраты на собственную разработку и сравнить их. С другой стороны, я сделал с десяток запросов, этого мало, чтобы сделать обоснованные выводы. Вариант однозначно стоит рассмотреть, но мы в рамках нашей статьи его пропустим, потому что о простой интеграции с API стороннего сервиса неинтересно писать и неинтересно читать.

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

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

Оно у нас будет состоять из двух частей. Серверная часть будет реализована на языке C# и платформе .NET Core, а клиентская — в виде расширения для браузера Chrome. Выбор C# обусловлен личными предпочтениями, объективно, подойдет почти любой язык. Опыт использования Selenium для этой цели говорит о том, что расширение для браузера будет более надежным решением. Кроме того, мы будем контролировать весь процесс, и у нас не будет промежуточного черного ящика в виде Selenium драйвера.

Давайте начнем с серверной части. Подразумевается такой сценарий работы:

• Сервер получает запрос на загрузку некоторой страницы. В параметрах запроса передается адрес страницы и, опционально, css-селекторы элементов, сигнализирующих о том, что выполняется автоматическая проверка. Кроме того, в параметрах можно передать селектор элемента, по которому нужно эмулировать щелчок мыши. Соответственно, запрос должен выглядеть примерно так: https://proxy. loader/load? url=https% 3A% 2F% 2Fexample. com&waitSelector=% 23challenge&clickSelector=% 23click-here
• Запрос ставится в очередь необработанных запросов.
• Расширение запрашивает адрес для загрузки. Соответственно, сервер обрабатывает этот запрос и возвращает информацию опервом в очереди адресе, который необходимо загрузить. Адрес удаляется из очереди и перемещается в список адресов, которые находятся в процессе загрузки. Расширение переходит по полученному на какой-нибудь из вкладок (давайте пока не будем конкретизировать это поведение) .
• Расширение ждет, пока проходит автоматическая проверка. При необходимости, эмулирует нажатия мыши.
• Расширение преобразует загруженный документ в HTML-разметку и отправляет его на сервер с помощью POST запроса.
• Сервер возвращает ответ на запрос из пункта 1.

Давайте напишем сервер. Версия приведенная здесь, будет отличаться от версии в git. Я удалил несущественные в контесте обсуждения обхода блокировки проверки аргументов и обработки ошибок. Итак, файл Program. cs:

Что же, мы реализовали три метода, которые могут обрабатывать HTTP запросы.

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

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

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

SetResultAsync будет обрабатывать запросы от расширения с результатом загрузки страницы.

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

Реализацию в настоящем коде можно найти в репозитории.

Перейдем к клиентской части. Документацию по разработке расширений можно найти здесь.

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

Перейдем к основному файлу, background. js. Он будет выполнять всю работу. У нас будет основной цикл, в котором мы будем обрабатывать текущее состояние. Давайте схематично накидаем его структуру.

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

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

За этот процесс отвечает код:

Файл persistent. html выглядит следующим образом:

Этот файл ссылается на persistent. js. Его содержимое:

Думаю, на этом рассмотрение кода можно закончить. Код доступен на GitHub.

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

Теперь встает вопрос хостинга. Серверная часть нашего решения сможет работать на почти любом виртуальном хостинге, одного гигабайта оперативной памяти будет достаточно. Можно использовать Nginx как reverse proxy, но в данном случае я бы не стал, у нас нет типичных для него задач, Kestrel и сам справится.

Файл с конфигурацией сервиса для systemd может выглядеть примерно так:

Что касается окружения для запуска браузера, то потребуется больше памяти, можно начать с 3-4 гигабайт.

Итак, мы создали новую виртуальную машину с установленным Линуксом у какого-нибудь хостинг-провайдера. Установить Хром сразу не получится. Насколько я смог разобраться, проще всего сначала установить какое-нибудь окружение рабочего стола. Я установил XFCE.

Теперь можно попробовать установить Хром.

В процессе установки увидим, что не хватает некоторых пакетов. Мне помогла команда

Можно запускать. Пишем google-chrome в консоли и получаем ошибку "Missing X server or $display"

Мне удалось найти, что виртуальный монитор можно сделать при помощи утилиты Xvfb.

После этого мне удалось запустить Хром.

Запустить хром с загруженным расширением можно при помощи следующего ключа:

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

Как сделать так, чтобы Хром запускался при старте системы и перезапускался в случае падения, я оставлю за рамками статьи. Я использовал systemd сервис.

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

Разобрались, как работает детектирование роботов.

Разработали сервер и браузерное расширение для обхода блокировок. Ссылка на GitHub.

Запустили браузер в графическом режиме из консоли Линукса.