Империя наносит ответный удар: kad.arbitr.ru снова поддается парсингу (часть 1)

В статьях ^[1] 2021 года можно встретить довольно пессимистичный вывод: «ресурс окончательно уничтожил возможность сбора информации с помощью Selenium» . Но, как оказалось, это не совсем так.

Сайт kad.arbitr.ru - предоставляет информацию о гражданских делах, в первую очередь данная информация интересна юристам. Также там можно найти информацию о началеконце банкротства и много другой информации связанной с юридической составляющей нашей жизни как граждан данной страны. На практике часто возникает задача мониторинга состояния дел по заданному списку - допустим по ИНН или же по ФИО. Именно такая задача была поставлена предо мной, найти дело по ИНН (если оно существует) и открыть его карточку чтобы собрать информацию.

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

Первое, что приходит в голову при решении задачи парсинга по конкретному полю — это использование API .

Возможны три варианта:

1. Сайт отдает сырой HTML

2. Есть JSON API без серьезной защиты

3. Есть 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 ^[2]_SessionId=... → ID сессии на сервере (обычно для сайтов на ASP.NET ^[2]). Используется, чтобы сайт “узнавал” тебя между запросами.

• CUID=... → Уникальный ID пользователя (часто шифрованный). Может использоваться для авторизации или трекинга.

• rcid=... → Ещё один уникальный идентификатор клиента (часто для аналитики или рекламы).

4) Проверки на «человечность»

__ddg* — это:
* Информация поведения клиента, часто используется для антибот систем, но тут сложно что-то сказать точно

5) Наиболее важные поля для понимания

• pr_fp=... → Fingerprint (цифровой отпечаток браузера/устройства)

• wasm=... → Может использоваться для WebAssembly-проверок (часто антибот/безопасность)

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

Нашей задачей было понять как работает сайт с api - и попробовать самим что-то получить с помощью него. Попробуем воспроизвести этот запрос вручную - например, с помощью curl - это быстрый способ проверки. Для того чтобы скопировать интересующий нас запрос сделаем следующее - правая кнопка мыши на запрос - copy - curl (cmd).

Копируем данный запрос и открываем cmd, вставляем и пробуем — должен быть нормальный ответ — похожий на тот который мы ранее получили в разделе Response. Если же нет — проблемы уже начались:‑)

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

Тут остались 3 категории полей:

1. Кодировки и просто согласования форматов данных

2. Fingerprint и wasm

3. Данные непосредственно по запросу - тут это ИНН

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

В ходе анализа обнаруживаются:

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

Промежуточные итоги

1. Определены основные endpoint’ы

2. Определено, какие заголовки можно игнорировать

3. Выделены заголовки, участвующие в антибот-защите

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