Веб-скраперы — это боты, которые автоматически собирают информацию с сайтов. Иногда они делают это вполне безобидно — например, для мониторинга цен. А иногда — вредят: копируют ваш каталог, перегружают сервер или крадут данные. 

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

Эта статья написана по докладу для конференции Saint Highload++ и носит исключительно ознакомительный характер. Написана для изучения уязвимостей веб-сайтов в целях повышения устойчивости к атакам злоумышленников. Любые попытки несанкционированного доступа, взлома или нарушения работы сайтов — противоправны и преследуются по закону.

Effective — это команда экспертов в искусственном интеллекте, мобильной и веб‑разработке. На проекте, на котором мы получили опыт построения веб‑скраперов — мы решали задачи не классического «читающего» скрапинга со сбором данных, — мы законно заполняем формы данными, которыми владеет наш клиент, для оптимизации его бизнеса.

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

Что такое веб-скрапинг?

Веб-скрапинг — это автоматизированный процесс извлечения данных оттуда, откуда не подразумевается автоматизированный процесс извлечения данных :)

Применение:

• Агрегация контента;

• Мониторинг цен;

• Сбор данных для машинного обучения — этот пункт уже можно поднять в топ-1 из-за актуальности. 

• Исследования рынка 

• Автоматизация бизнес-процессов, для которых просто нет готовых API.

Но с другой стороны:

• Потеря данных;

• Урон бизнесу — копирование каталога, цен, etc;

• Злоупотребление инфраструктурой.

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

• Как найти баланс между безопасностью и производительностью;

• Имеет ли смысл внедрять системы защиты от ботов;

• Когда простых решений достаточно, а когда нет;

• Как понять, что защищать, а что не стоит усилий;

• Решают ли классические инструменты бóльшую часть проблем.

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

Что видит защищающийся

Предлагаю раскрутить эту тему, как матрёшку.

Основная, самая понятная мысль:

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

Единственный способ понять, что что-то происходит — начать собирать метрики. А в метриках будут аномалии — в большинстве кейсов мы обнаружим их на уровне L7. Вспомните модель OSI: это там, где находится HTTP. 

Выглядит это так:

• Рост числа отбивок с 429, с 403 статусом.

• Рост количества нестандартных User-Agents (curl, etc.).

• Странные Referer-заголовки, либо отсутствие каких-либо заголовков, что не похоже на пользователей с браузером.

• «Эффективная» навигация и нажатие кнопок на сайте.

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

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

Ботов пишут не дураки. Они понимают что за их поведением смотрят. Поэтому бот действует аккуратно и мимикрирует:

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

• Эмулирует движение мышкой идеально по кривой.

• Печатает со скоростью человека.

• Кликает по разным частям сайта («человеческая» навигация).

Но как бы боты не старались, наше человеческое поведение — совокупность огромного количества факторов. 

Когда скрапер заврался

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

Intl.DateTimeFormat().resolvedOptions().timeZone === “Asia/Omsk”

Смотрим, что у него IP-адрес — США и задаёмся вопросом: «Погодите, вы сидите в США с IP-адресом Омска? Что-то не сходится». Такая история называется leak (утечка, несходимость). Но мы не делаем выводы только по одной утечке — мало ли, ему так нравится жить, а берём совокупность.

Есть классный сайт BrowserScan, на котором можно запустить проверку и на основании просто API браузера и определить, есть ли у вас такие утечки.

В примере выше я зашёл с IP-адреса Новосибирска, а тайм-зона — не Новосибирск, а Омск. Я был в Омске, но мой мобильный провайдер передаёт данные из Новосибирска. То есть, это не говорит о том, что я бот.

Как нас видит разработчик веб-скраперов

Есть метрики, боты, а как понять, на что конкретно смотреть, чтобы определить бота, на какие конкретно leak смотреть? Давайте вернёмся чуть назад и посмотрим, как вашу систему видит разработчик веб-скрапера.

Что делает атакующий?

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

Но давайте забудем, что это магазин техники и посмотрим, как реально выглядит приложение для разработчика веб-скрапера. Да, это Black-box, чёрный ящик, просто какое-то приложение. Непонятно, что оно делает, как ведёт себя и почему банит самого веб-скрапера.

Black / Grey / White box

Термины тестирования:

• Black-box: видим только то, что публично.

• Grey-box: знаем структуру URL, поведение компонентов, то есть понимаем, как система ведёт себя внутри.

• White-box: знаем схему API, возможно, даже токены, то есть у нас есть полный доступ к коду.

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

Скраперы эволюционируют

Как я сказал, скраперы уже давно не ходят через curl с одного IP-адреса и не генерируют заголовки. Они начинают адаптироваться:

• Генерируют реалистичные браузерные заголовки, делают постоянную ротацию прокси (Residential/Mobile proxy).

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

• Начинают использовать стелс-браузер, который закрывает утечки — те о которых мы только что поговорили, и те о которых ещё не успели.

Базовые инструменты скрапера

• curl/requests/axios – просит сайт поделиться данными.

• DOMparser – парсит HTML-контент.

Скраперы начинают с того, что ломятся по http-клиенту. Берут знакомый http-клиент и тянут ваш сайт. Если у вас там JSON API, то могут вытащить данные. Если HTML-контент, то придётся немного потрудиться и запарсить DOM-дерево. Это, на самом деле, отдельная наука. Чем чаще вы меняете классы в тегах HTML-контента, тем более вероятно, что чей-то бот сегодня сломается.

Работа с application/*

* Ничего не мешает разработчику приложения постоянно менять API-эндпоинты, но оставаться консистентным в HTML-разметке.

Наиболее удобная структура данных — это хорошо сериализованные структурированные данные, например, JSON, YAML, XML. Они, чаще всего, стабильные, с чёткой структурой и всем нравятся.

JSON:

• Стабилен*;

• Структурированные данные;

• Всем нравится.

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

HTML

• Чаще меняется*;

• Неструктурированные данные;

• Тоже ничего.

Так выглядит подбор селекторов:

Это вид от разработчика бота, представьте себя на его месте.

Мы поговорили про простые кейсы — открыли страницу, вытащили данные, обработали. Но часто сайт зависит от множества внешних систем, в которые мы делаем асинхронные запросы:

• Открываем сайт;

• Скачиваем JavaScript;

• Получаем куку с сессией;

• Отдаём отбивку в метрику;

• Делаем еще 100500 дел;

• Получаем стейт, который сайт ожидает увидеть в запросе.

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

Чтобы думать как браузер, мы переходим к использованию фреймворков для автоматизации браузеров. Они популярны для тестирования, так как позволяют оперировать популярными браузерными движками — Chromium, Gecko, WebDriver. Их удобно запускать и управлять ими, в том числе, заходить на сайт, извлекать из него данные, процессить фреймворки и так далее.

Proxy-сервисы

Мы уже определили основные инструменты — это HTTP клиент, браузер, который используется, чтобы симулировать движок браузера. Остаётся проблема с IP-адресами. Здесь в игру вступают proxy-сервисы:

• Free Proxy;

• TOR;

• Datacenter Proxy;

• Residential Proxy;

• Mobile Proxy.

Сразу скажу, обращайте внимание на первые два вида. Free Proxy мало и у них плохая репутация. TOR можно определять с помощью самого TOR. У него есть удобный API, который позволяет определить, является ли этот IP-адрес IP-адресом из TOR. Самая интересная часть — это DataCenter, Residential и Mobile Proxy:

• DataCenter:

• Быстрые и дешёвые;

• Легко идентифицируются сайтами;

• Хороши для некритичных задач.

• Residential:

• IP реальных устройств (домашних);

• Труднее обнаружить;

• Средняя стоимость/скорость.

• Mobile:

• IP мобильных операторов;

• Наименее подозрительные;

• Высокая стоимость.

Последние два — Residential и Mobile Proxy — самые опасные ребята на рынке, рекомендую их опасаться.

С Datacenter Proxy всё просто — есть какая-то VPS, с этой VPS идут запросы. Определяем CIDR, то есть пул IP-адресов этого VPS провайдера. Возможно, не нужно пропускать запросы от этого VPS провайдера, если у нас нет большой клиентской базы, которая почему-то через него ходит.

Residential Proxy уже интересней.

Тут нельзя просто забанить какой-то пул IP-адресов и считать, что боты больше не придут. В случае Residential Proxy получают доступ как через определённые хаки, условия в пользовательском соглашении о том, что “вы соглашаетесь передать часть своего трафика тому-то тому-то”, так и по предварительному уведомлению пользователя. На пользовательских девайсах, в том числе, мобильных (Mobile Proxy — это то же самое, что Residential Proxy). То есть простраивают канал обратно к своему серверу с браузерного экстеншена пользователя с мобильного приложения либо десктопа. Дальше по этому каналу все запросы выходят через чистые, крутые, домашние IP-адреса пользователей, как в случае с Residential Proxies или IP-адреса мобильных провайдеров, как в случае с Mobile Proxies.

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

Напомню, что Residential и Mobile Proxies стоят очень дорого. Они биллятся по трафику, который ходит через них. Понятно, что если закидывать им побольше контента, который они будут тянуть с вашего сайта, они в какой-то момент могут обанкротиться.

Читал статью на Хабре с классной историей. При обнаружении подозрительного IP-адреса, из которого до этого выходил бот, он просто подсовывал ZIP-бомбу, которая работала чисто на HTTP-хедерах зипующих. Бот её раскрывал, раскрывал, раскрывал, раскрывал. У него, во-первых, сам бот отваливался, во-вторых, ещё и биллинг.

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

Residential и Mobile Proxies — классная история, но их часто выдают следующие ситуации:

• Пул адресов Residential Proxies «протухает».

Если загуглить Residential Proxies, найдётся очень много сайтов, где ребята говорят, что у нас больше 70-200 миллионов уникальных адресов. Иногда эти чуваки выходят за пределы IPv4 и довольны, что у них много IP-адресов — берите и пользуйтесь нами! Но по факту чаще всего у них максимум 1000 IP-адресов, которые очень быстро загрязняются другими ботами, которые находятся конкурентно вместе с ними в этой среде и выдают себя за ботов. Так получается, что весь этот пул очень часто просто «протухает» и не работает.

• Боты выдают себя неконсистентными: тайм-зоной, локализацией и IP-адресом и пр.

Теперь о том, как будем защищаться — ведь мы здесь для этого:

• Используем сервисы IP Quality Score.

Существуют готовые решения IP Quality Score. Можно также поискать сервисы, которые позволяют отдать им IP-адрес. Они на основе всей своей закраудсорсенной базы, которую собрали, говорят: «Этот IP-адрес уже известен как бот. Будь аккуратнее с ним, поставь ему скор пониже».

• Смотрим в сторону собственного решения.

Допустим, можно собрать Redis. Просто кладём информацию по IP-адресам, которые уже выдавали себя какими-то неконсистентными параметрами, и начинаем этих ребят потихонечку раскручивать. Поймали бота, определились, что это бот — отлично, начинаем его обманывать: отдаём 200+ невалидных данных или подсовываем ему на страницу honeypots. Это скрытый attack на странице, который будет вести на рекурсивную страницу, из которой бот никогда не выйдет и тем самым попадёт в ловушку. Это относится к классическим скраперам, которые собирают данные из интернета.

CAPTCHA

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

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

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

• AI-решения с помощью машинного обучения;

• Аутсорс-решения через реальных людей.

Работает это примерно так.

Скрапер заходит на сайт, вытягивает токен сайта из HTML-контента в JSON прилетает, отправляет его сервису решения капчи. Дальше сервис решения капчи рендерит либо у реального человека, либо собирает из неё все картинки, пушит в CV модель и готово — получает готовое решение, которое решает капчу очень хорошо. Сейчас очень легко определить робота прошёл каптчу или человек. . Если слишком хорошо или плохо — робот, а если посередине, скорее всего, человек.

Ещё обычным людям за копеечку отправляют решать капчу. Работает очень стабильно.

Но есть небольшие НО:

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

• Капча-solvers часто используют отдельные серверы с другими IP-адресами. Возникает mismatch между запросом и решением. Вы делаете запрос на сайт с одного IP-адреса, а каптчу решают вообще откуда-то сбоку. 

• Заголовки, Accept-Language и Referer не совпадают

Сюда же можно отнести fingerprint. Это, по сути, уникальная информация, которая идентифицирует даже не пользователя, а конкретно ваш браузер на конкретном девайсе.

Fingerprinting или мы знаем о тебе всё

Это очень интересная тема в мире скрапинга и веб-секьюрити. 

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

• Со своего браузера я получаю данные.

• Через Playwright + Chromium + Residential proxy на том же сайте получаю бан.

• Загружаю профиль своего браузера в скрапер... Также получаю бан.

Fingerprint-система, которая работает из коробки, звучит как вообще идеальное решение. Собирает уникальные характеристики через API браузера, создаёт цифровой отпечаток посетителя, определяет ботов по аномалиям в отпечатке.

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

Что отслеживает fingerprinting:

• Базовые характеристики браузера и операционной системы.

• Заголовки.

• Установленные шрифты.

• Как рендерят все рендерящие API (Canvas/WebGL/аудио).

• Поведенческие паттерны пользователя.

Этот список постоянно растёт.

Простой кейс, на чем боты чаще всего попадаются

• const os = navigator.platform; // iOS

• const cpuCount = navigator.hardwareConcurrency // 1

• await navigator.mediaDevices.enumerateDevices(); // []

• iOS-девайс с одним ядром CPU?
  Ещё и без микрофона и камеры?

Довольно подозрительно!

Ребята запускают автоматизацию браузера и ставят себе юзер-агент. С ними всё очень круто — Darwin, Mozilla 5.0, «Я с Мака захожу, ещё и заголовки свои подгоню». А потом одна библиотка FingerprintJS из open-source, извлекает всю информацию о вас и узнаёт: «У вас OS Linux, один CPU и похоже, вы запускаетесь не с Мака, а с Docker-контейнера. Что-то тут не сходится».

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

Это работает по статистической вероятности.

Мы сейчас переходим от open-source решения FingerprintJS. Есть ребята, которые уже поставили на поток сбор этих данных, сравнение этих данных с настоящими ботами, и их использование для защиты сайтов. Речь о Web Application Firewall (WAF). Пример — ReCAPTCHA v3.

reCAPTCHA v3 — скоринговая система

Существует три версии ReCAPTCHA:

ReCAPTCHA v1, где нужно только кликнуть на галочку и всё.

ReCAPTCHA v2, где нужно кликнуть на галочку и порешать челлендж (аудио либо картинки).

ReCAPTCHA v3 — это просто зверь.

Принцип работы довольно простой:

• Возвращает score от 0.0 до 1.0 (1.0 = человек, 0.0 = бот).

• Не требует явного решения капчи.

• Анализирует поведение пользователя.

• Работает в фоновом режиме.

ReCAPTCHA v3 работает полностью в фоне. Мы абсолютно ничего не заставляем делать пользователя, он не решает никакие картинки. Всё, что он видит, это маленький баннер CAPTCHA (и то я его здесь увеличил в 3 раза, он ещё меньше), который появляется где-то на сайте, делает, непонятно что, а бота не пропускает — тот стабильно получает 403 ошибку.

ReCAPTCHA v3 анализирует поведение пользователя, собирает информацию по его fingerprint. Здесь речь идет о «дёрганном» поведении и эффективности ротации по сайту. 

Fingerprinting. Решения

Работает фоново и выступает как реверс-прокси поверх основного бэкенда.

Методы обхода:

• Эмуляция реальных браузеров.

• Генерация согласованных отпечатков.

• Имитация человекоподобного поведения.

Инструменты:

• BrowserForge.

• Camoufox.

Оба инструмента — решения с API под Python. 

BrowserForge

• Библиотека на Python для генерации HTTP-заголовков.

• Имитирует частотное распределение браузеров и ОС.

• Воссоздает реалистичные отпечатки.

• Байесовская генеративная сеть.

Мы говорим, что поняли, что не можем взять и подкинуть наш фейковый юзер-агент и сказать, что нам нужно доверять». Нам нужно эмулировать, в том числе, и все остальные параметры браузера, то есть всё, что находится в навигаторе — информация по OS и CPU, абсолютно вся информация, которая туда пробрасывается и которой очень много.

Эти ребята собрали из огромного количества open-source источников и утечек той же reCAPTCHA множество информации о том, а какие fingerprints вообще бывают. Дальше строят байесовскую сетку (вспомните теорию вероятностей).

Мы берём рутовые параметры fingerprint, которые не зависят от остальных ОС, доступные языки в системе. Дальше на основе этого идём по графу, по определённым вероятностям, и понимаем, какие у нас будут остальные параметры. Думаю, понятно, что если у нас операционная система iOS или macOS Darwin, то с очень малой вероятностью у нас не будет движков Chromium и Gecko, а будет только WebDriver. Потому что Apple требуют, чтобы на их операционных системах использовались движки только WebDriver. Firefox и прочие браузеры на самом деле на WebDriver сделаны. 

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

Camoufox

Можно отследить инъекцию скриптов в DOM-дерево. Например, чтобы что-то инъектировать в тот же навигатор, нужно залезть в DOM-дерево и прокинуть свой скрипт. Тут мы подключаем Camoufox, открытый браузер на базе Firefox.

Преимущества Camoufox:

• Патчи на уровне C++, то есть никаких JavaScript инъекций.

Прямо на уровне движка браузера, куда наше приложение никогда не зайдёт, загнана логика по генерации fingerprints и инъектированию их:

• Подмена всех fingerprint-свойств;

• Эмуляция движений курсора.

Camoufox умеет круто эмулировать движение курсора с помощью логарифмического распределения. Звучит как unbelievable, нерешаемо — обошли даже идеальные reCAPTCHA v3 и прочие fingerprint-системы, которые по fingerprint определяют, что бот будет делать.

Как защищаться

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

• «Протухшие» IP-адреса, «нечеловеческие» движения и пр.

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

• Скраперы экономят: блокируют часть трафика, чтобы не переплачивать → происходят утечки.

Снова вспомним, что скраперы часто используют такую штуку, как Residential и Mobile Proxy, где биллится каждый килобайт. Думаю, скраперу не особо интересно, что это за статика такая с картинками, шрифтами, stylesheet. Ему нужно зайти, эффективно извлечь все данные и уйти дальше. Он не хочет тратить деньги на картинки. Это тоже можно отслеживать даже на уровне XMLHttpRequest API для запросов в веб.

Есть штуки на уровне ниже L7, на TLS Fingerprinting.

• TLS Fingerprinting (JA3/JA4) отличается от классических браузеров.

У каждого браузера есть уникальный вектор, строка, которая содержит допустимые версии TLS, доступные ID алгоритмов шифрования и так далее. Допустим, у обычного браузера Firefox сначала идёт первый алгоритм шифрования, потом второй, а у Camoufox они поменялись.

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

Подобных штук — очень много. В том числе есть IP fingerprinting, когда мы смотрим не на приложение, а на уровень IP, на то, как пользователь инициализирует подключение по TCP/IP.

Распределение

По моему наблюдению, в интернете больше всего (60% трафика ботов) довольно тривиальных ботов:

• Ходят с обычными HTTP-клиентами;

• С одним IP-адресом, или free proxy, или TOR’ом;

• Легко детектятся/банятся/ ломаются, просто потому что одно изменение на странице — и всё, они упали.

Ребята посложнее (35% трафика ботов):

• Уже вместе с HTTP-клиентом используют браузер;

• Ротируют IP-адреса;

• Умеют решать капчу;

• Но выдают себя утечками вроде неумения закрыть fingerprint и всё ещё сидят с OS Linux, выдавая себя за macOS. 

Более хардкорные ребята — это стелс-браузеры (5% трафика ботов):

• Эмулируют человеческое поведение;

• Используют Residential Proxies и себя особо не выдают.

Опять же, я не делал замеры на огромном количестве сайтов, это моё наблюдение. Да и к тому-же, как думаете, сколько в эти 100% не вошло ботов, о которых мы вообще не знаем? :)

Стратегии защиты

WAF (Web Application Firewall)

Используйте WAF, который прямо из коробки решает большую часть проблем:

• Реверс-прокси перед вашим бэкендом;

• Анализирует трафик в совокупности;

• Zero-Proof Knowledge: каждый запрос – потенциальная угроза.

Очень важно, что мы хотим, чтобы это работало так: боты получают 403, пользователи получают 200 ошибку.

Но очень часто, если вы на ваш сайт накатываете WAF и меняете DNS-запись, происходит так:

Кто-то не закрыл на файрволе запросы с этого WAF, и бот смотрит сайт dnshistory.org. Там можно по вашим доменам посмотреть очень много историй по записям, как они изменялись. Бот просто идёт на старые IP-адреса и подменяет хост заголовок без проблем.

Есть классические зарубежные решения WAF:

• AWS WAF

• $5/мес. за Web ACL;
  $1/мес. за каждое правило;
  $0.60 за 1 млн запросов;

• Гибкость настройки, интеграция с другими сервисами AWS.

• Azure WAF

• От $0.443/час за шлюз;

• Интеграция с Azure Front Door, масштабируемость.

• Cloudflare WAF

• От $20/мес.

• Простота настройки, производительность.

Ребята делают хорошую работу, но есть и наши аналоги:

• Curator WAF

• Основан на SolidWall;

• Быстрый старт: нет нужды ждать обучения;

• Платные тарифы + плата за трафик сверх 3 Мбит/с;

• Отлично подходит для инфраструктур внутри Selectel.

• Yandex Cloud WAF

• Входит в Yandex Cloud, General Availability: реализует WAF + Advanced Rate Limiter;

• От ~$333/мес. за пакет WAF, далее – плата за трафик по тарифу;

• Плюсы: быстрая интеграция с облаком, анализ аномалий, DDoS-защита;

• Минусы: не лучший выбор для on-prem; затраты растут с объёмом трафика.

Честно скажу, я сам больше работал с AWS и Cloudflare, но рекомендую посмотреть решения от Selectel и Яндекса, потому что они годные. Если вас прямо сейчас атакуют, то защищайтесь. Если у вас есть время подумать, просто берите решение и пробуйте.

CAPTCHA

• reCAPTCHA V2 / Yandex Smart Captcha, которые требуют от нас экшена – хорошие решения.

• Но сейчас они очень легко обходятся Captcha Solvers.

• Используем в случае, если у нас большое количество ботов уровня «тривиальные» и «чуть посложнее».

• Используем в комбинации с WAF и показываем только подозрительным клиентам.

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

Распределение

• Тривиальные

• Обычный HTTP-клиент.

• Один IP-адрес/free proxy.

• Легко детектятся/банятся/ломаются.

• 60% трафика ботов.

• Посложнее

• HTTP-клиент/браузер.

• Ротация IP-адресов.

• Умеют решать капчу.

• Выдают себя утечками.

• 35% трафика ботов.

• Хардкорные

• Стелс-браузер.

• Эмулируют человеческое поведение.

• Используют Residential proxies.

• 5% трафика ботов.

В этом плане на рынке сейчас очень крутое решение от DataDome. 

DataDome: CAPTCHA + behaviour

Это зарубежное решение. Оно смотрит и на fingerprint, и на поведение пользователя на странице, и, если видит какую-то аномалию, просит сдвинуть пазл.

Сдвинуть пазл — это вот так:

DataDome сейчас тяжело обходится даже CamouFox, чистыми IP–адресами и Captcha Solver-сервисами, просто потому что Captcha Solver-сервисы чаще всего не умеют решать капчу in real life, прямо как экшенами на HTML документе.

Стоит ОЧЕНЬ дорого ($3 690/мес. за 100 млн запросов), идеален для больших проектов.

Заключение и рекомендации 

Скраперы VS Безопасники: гонка вооружений

Скраперы против безопасников, как и любые другие виды атак против безопасников — это вечная борьба: одни ломают, другие закрывают, потом снова ломают и закрывают, и это бесконечно. Появляются новые инструменты для скрапинга — появляются новые механизмы защиты, новые фильтры.

Простой хак для защиты своего сайта

Как я уже сказал, есть Residential Proxies. Мы можем увеличивать контент, который отдаём, просто заполняя комментариями HTML-страничку. Боты начнут платить больше. Либо мы можем начать увеличивать скорость ответа на 0,5 секунды. Человек не заметит разницы, боты станут получать меньше информации, SEO особо не пострадает, но при этом мы замедлим скрапинг в 2−3 раза.

Главное, что нужно помнить

• Разработчики скраперов – аналитики.

Они используют огромное количество решений (OWASP amass, dnsdumpster, WaybackMachine и пр.), которые могут рассказать абсолютно обо всём вашем контуре.

• Делайте единые точки входа в приложение, закрывайте старые API, отслеживайте несанкционированный доступ к API.

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

Простой пример: API мобильного приложения не имеет защиты от ботов.

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

Ключевые выводы

Важно оценивать влияние систем защиты на перфоманс и цену поддержки.

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

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

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

«Любая система защиты может быть преодолена — это лишь вопрос времени и ресурсов.

Задача сĸрапера, как и безопасника — найти оптимальный баланс между стоимостью получения данных и их ценностью».

Скрытый текст

Если вам интересна тема веб-скрапинга, вы хотите обезопасить свой бизнес или проверить свой сайт на уязвимости, — я и мои коллеги готовы вам помочь. Также готов ответить на ваши вопросы в телеграме: @ayusavin.

А если вы хотите узнать больше о технологиях, позволяющих одновременно обслуживать многие тысячи и миллионы пользователей, приходите на HighLoad++ 2025, который пройдёт в ноябре. Вас ждёт самая высокая концентрация IT‑профессионалов страны: 3800 участников, 10 залов, 140+ докладов и 8 мастер‑классов. И конечно, живое общение со специалистами отрасли — не пропустите!