В статьях 2021 года можно встретить довольно пессимистичный вывод: «ресурс окончательно уничтожил возможность сбора информации с помощью Selenium» . Но, как оказалось, это не совсем так.
Сайт kad.arbitr.ru - предоставляет информацию о гражданских делах, в первую очередь данная информация интересна юристам. Также там можно найти информацию о начале\конце банкротства и много другой информации связанной с юридической составляющей нашей жизни как граждан данной страны. На практике часто возникает задача мониторинга состояния дел по заданному списку - допустим по ИНН или же по ФИО. Именно такая задача была поставлена предо мной, найти дело по ИНН (если оно существует) и открыть его карточку чтобы собрать информацию.
При первом знакомстве сайт выглядит довольно устаревшим - как и многие государственные сайты, тем не менее, первое впечатление бывает обманчиво, ведь тут достаточно неплохая защита от тех кто хочет собрать много информации автоматически. Далее разбор будет строиться по следующей схеме: простой способ сбора информации → анализ, почему он работает или нет и так далее.
Первое, что приходит в голову при решении задачи парсинга по конкретному полю — это использование API .
Возможны три варианта:
Сайт отдает сырой HTML
Есть JSON API без серьезной защиты
Есть JSON API с антибот-защитой (наиболее вероятный вариант)
Здесь конечно первые 2 варианта будут для нас благосклонными и облегчат нашу задачу по сравнению с 3 вариантом. Для того чтобы понять какой у нас вариант - заходим на сам сайт и открываем DevTools - инструмент, показывающий сетевые запросы между браузером и сервером. Нас интересует вкладка Network — она отвечает за сетевые запросы.
Мы видим множество файлов загрузилось. Введем любой ИНН и посмотрим, какие файлы появятся. Для этого введем ИНН по которому знаем что дело точно есть (можете по имени — так будет проще найти). Далее чтобы лучше посмотреть что именно ресурс нам отправил, выделим временной промежуток, который показывает файлы пришедшие на этот запрос. Среди всех запросов видно, что большинство — это статические ресурсы (например,.png). Eсть интересный запрос SearchInstances — скорее всего именно в нем находится нужная нам информация. Чтобы понять структуру ответа, можно перейти во вкладку «Response». Убедившись, что это нужный нам запрос, переходим в раздел «Headers». Здесь можно увидеть, какие заголовки отправляет браузер и какие получает в ответ. В разделе Headers есть три блока. Первый — «General» — общая информация куда направлялся запрос, какой метод использовался, статус ответа, ip адрес с которого был отправлен запрос, и политики. Далее идут 2 раздела «Response headers» и «Request headers» — там информация о том какие заголовки отправляются и принимаются. В первой части мы видим информацию про кэширование, кодирование, сжатие, снова политики... и какие то строки Set‑Cookie — эти данные непосредственно присваиваются на наши следующие запросы к данному ресурсу, он их добавляет чтобы в следующем запросе точно нас опознать.
Гораздо важнее понять, какие данные отправляет браузер. Чтобы получить данную информацию (он отправил нам информацию о записи в таблице). Именно эта информация подскажет какая тут стоит защита - если она вовсе есть.
Тут мы видим уже более интересную картинку. Все остальное вокруг этого большого набора cookie - информация о браузере, кодировки, и прочая несущественная для текущей задачи информация. Разберем что в разделе куки (строки были отчасти замазаны по понятным причинам).
Здесь можно определить несколько видов записей:
1) Яндекс собирает данные
ymuid=... → ID пользователя в Яндекс.Метрике.
ymd=... → Дата первого визита.
ymisad=1 → Флаг наличия блокировщика рекламы (adblock).
2) Google тоже собирает
_ga=... → ID пользователя в Google Analytics (долгоживущий).
_gid=... → ID сессии в Google Analytics (обновляется чаще).
_gat=1 → Ограничение частоты запросов к GA.
ga95...89Y6 / gaQ2...01XE → Связаны с конкретными проектами/сайтами в Google Analytics 4.
3) Служебные идентификаторы
ASP.NET_SessionId=... → ID сессии на сервере (обычно для сайтов на ASP.NET). Используется, чтобы сайт “узнавал” тебя между запросами.
CUID=... → Уникальный ID пользователя (часто шифрованный). Может использоваться для авторизации или трекинга.
rcid=... → Ещё один уникальный идентификатор клиента (часто для аналитики или рекламы).
4) Проверки на «человечность»
__ddg* — это:
* Информация поведения клиента, часто используется для антибот систем, но тут сложно что-то сказать точно
5) Наиболее важные поля для понимания
pr_fp=... → Fingerprint (цифровой отпечаток браузера/устройства)
wasm=... → Может использоваться для WebAssembly-проверок (часто антибот/безопасность)
По-хорошему все эти данные так или иначе можно использовать для антибот систем, возможно, часть из них действительно используется, но на данном этапе это не критично, просто будем иметь в уме все что только что поняли.
Нашей задачей было понять как работает сайт с api - и попробовать самим что-то получить с помощью него. Попробуем воспроизвести этот запрос вручную - например, с помощью curl - это быстрый способ проверки. Для того чтобы скопировать интересующий нас запрос сделаем следующее - правая кнопка мыши на запрос - copy - curl (cmd).
Копируем данный запрос и открываем cmd, вставляем и пробуем — должен быть нормальный ответ — похожий на тот который мы ранее получили в разделе Response. Если же нет — проблемы уже начались:‑)
В данном случае запрос успешно воспроизводится. Далее начинаем поэтапно убирать из запроса поля ответственные за антибот защиту (предположительно). Цель — запросы проходящие без этих полей полностью, если нет — придется рассмотреть другие способы, помимо сырых запросов.
После нескольких итераций остались только самые необходимые поля — при их удалении запрос перестает выполняться, это позволяет определить, какие заголовки участвуют в антибот‑защите.
Тут остались 3 категории полей:
Кодировки и просто согласования форматов данных
Fingerprint и wasm
Данные непосредственно по запросу - тут это ИНН
Возникает вопрос: откуда берутся значения этих полей, если они не устанавливаются через Set-Cookie? Предположим, что если они не сетаются то вероятно их проставление идет через специфичные файлы. Поэтому для ответа на этот вопрос нам придется заново зайти на ресурс и просмотреть какие файлы в начале нам отправляет ресурс, также на более ранних запросах мы заметим что там список полей в запросах гораздо меньше, значит они проставляют со временем и вероятно по важности. То есть мы должны найти те пакеты, которые непосредственно связаны с проставлением данных полей.
В ходе анализа обнаруживаются:
Вероятно именно тут и считается тот самый wasm. Также можно заметить на этом скриншоте другой файл fp.js?=.... в котором на вход идет то же самое и имя совпадает с полем fingerprint. Таким образом, удалось определить два файла, отвечающих за механизм антибот-защиты.
Промежуточные итоги
Определены основные endpoint’ы
Определено, какие заголовки можно игнорировать
Выделены заголовки, участвующие в антибот-защите
Если тема окажется интересной — в следующей части разберем, как воспроизвести генерацию fingerprint и обойти проверку.
