Как защититься от скрапинга данных: гайд SOC

Chess.com в 2023 году подтвердила: данные профилей утекли не через SQLi и не через компрометацию инфраструктуры. Атакующий тупо перебирал публичный API-эндпоинт, подставляя юзернеймы из готовых словарей, и складывал ответы в базу. Каждый запрос - валидный GET к эндпоинту профиля. Ничего подозрительного, если смотреть на единичный запрос. За последний год я разбирал три аналогичных инцидента на проектах с аудиторией от 50 тысяч пользователей - паттерн один и тот же: предсказуемые идентификаторы, одинаковый throttling на всех эндпоинтах и ноль алертов в SIEM до момента, когда дамп уже в продаже.

Бизнес-логика скрапера: зачем атакующему профили пользователей​

Прежде чем строить детектирование скрапинга, стоит разобрать мотивацию. Без этого невозможно приоритизировать защитные меры и объяснить бизнесу, почему "просто чтение профилей" требует бюджета. Подробнее - в нашем подробном разборе bola idor уязвимость.

Обогащение баз для credential stuffing. Скрапер собирает email, username, дату регистрации, привязанные соцсети. Эти данные обогащают существующие утечки паролей: если у атакующего есть пара email:password из другого сервиса, а скрапнутый профиль подтверждает, что email активен на вашей платформе - credential stuffing (T1110.004, Credential Access) становится на порядок эффективнее.

Таргетированный фишинг. Имя пользователя, email, рейтинг, дата последнего входа - готовый контекст для персонализированного письма. «Поздравляем с достижением рейтинга 1800 - подтвердите аккаунт» выглядит убедительнее массовой рассылки.

Перепродажа и конкурентная разведка. Базы профилей продаются на теневых площадках. Для сервисов с платной подпиской данные о tier-статусе пользователей имеют прямую коммерческую ценность.

По классификации OWASP API Security Top 10 (2023) массовый скрапинг попадает сразу под два риска:

• API4:2023 - Unrestricted Resource Consumption: API принимает неограниченное количество запросов без лимитов.
• API6:2023 - Unrestricted Access to Sensitive Business Flows: бизнес-процесс просмотра профиля доступен для автоматизированного злоупотребления.

Правовой контекст для РФ: с 2024 года штрафы за утечку персональных данных - оборотные. Если регулятор установит, что данные утекли через API без базового rate limiting, позиция «мы не знали» не сработает.

Kill chain скрапера по MITRE ATT&CK​

Скрапинг - не одноходовка. Типичная цепочка для массового сбора данных пользователей раскладывается по MITRE ATT&CK:


Если API требует аутентификации, атакующий берёт купленные или украденные API-ключи - вариант с Cloud Accounts (T1078.004, Initial Access). В кейсе Chess.com аутентификация для чтения публичных профилей не требовалась вовсе.

Ключевой момент для SOC: каждый отдельный запрос в цепочке - легитимный. Алерт должен срабатывать на паттерн, а не на единичное событие. По данным Cequence, HTTP GET-запросы составляют до 99% всех транзакций типичного домена, и именно через них идёт скрапинг. Инструменты bot mitigation, заточенные под анализ POST-запросов, этот вектор просто не видят.

Детектирование скрапинга: от логов до SIEM-правил​

Аномалии в API-трафике: сценарий из практики​

Понедельник, 9:15 утра. В Grafana-дашборде по API-метрикам вижу аномалию: эндпоинт /api/v2/users/{id} за выходные обработал в 40 раз больше запросов, чем в среднюю неделю. RPS с одного /24-подсета - стабильные 12 запросов в секунду, ровно на 2 ниже порога rate-limiter'а. Кто-то аккуратно подобрал скорость. User-Agent - Mozilla/5.0 (Windows NT 10.0; Win64; x64) без единой вариации за 48 часов. Время между запросами - 83+-2 мс, идеальная периодичность, невозможная для человека.

Что выдаёт скрапера в логах:

• Постоянный интервал между запросами. Человек кликает с разбросом 0.5-30 секунд. Скрипт на requests + time.sleep(0.08) даёт разброс в миллисекунды. Эту ровную "пилу" видно невооружённым глазом на графике.
• Один User-Agent без вариаций. Реальный браузер обновляется, меняет minor-версию. Скрапер использует захардкоженную строку.
• Последовательный перебор ID. Запросы к /api/user/1001, /api/user/1002, /api/user/1003 - инкремент на 1, или перебор по алфавитному словарю.
• Отсутствие навигационного контекста. Нормальный пользователь заходит на главную, кликает в профиль, переходит в другой раздел. Скрапер бьёт только в один эндпоинт - как дятел.
• IP из хостинг-подсетей. 95% запросов с DigitalOcean, Hetzner, OVH - не из резидентных подсетей.
• Доля 404-ответов выше 30%. Перебор несуществующих ID или юзернеймов генерирует массу 404. При нормальном использовании такого не бывает.

Baseline нормального API-трафика (DE.AE-01 по NIST CSF v2.0) - обязательная отправная точка. Без него любой порог алерта будет либо слишком шумным, либо бесполезным.

Скомпрометированные легитимные аккаунты: слепая зона SOC​

Отдельная головная боль - скрапинг через скомпрометированные легитимные аккаунты или партнёрские API-интеграции, которые превышают заявленный scope. Когда атакующий использует реальный API-ключ сотрудника, rate-limiter по IP и репутационные списки бесполезны. То же самое с инсайдером, который выгружает данные через штатный доступ.

Детектировать такие случаи можно только через anomaly detection по конкретному аккаунту: если партнёрская интеграция, которая обычно делает 200 запросов в день, внезапно начинает генерировать 20 000 - это сигнал. SIEM-правило должно учитывать исторический baseline каждого API-ключа, а не только глобальные пороги. На практике этот baseline мало кто ведёт - и зря.

Sigma-правила для корреляции в SIEM​

Для обнаружения автоматизированного сбора данных нужны правила, работающие на агрегации:
Базовое правило: более 200 запросов к эндпоинту профиля с одного IP за 5 минут. Порог подбирайте под свой baseline - 200 может быть и мало, и много. Дополнить стоит корреляцией по распределению ID в запросах: если разница между последовательными ID стабильно равна 1 - это скрапинг с инкрементом, тут и думать нечего. Дополнительные сигналы для корреляции: отношение уникальных запрошенных путей к общему числу запросов > 0.9 (каждый запрос - новый ID), отсутствие запросов к статике (CSS, JS, изображения) от того же source.

Защита API от скрапинга: rate limiting и поведенческий анализ​

Подход "только по IP" предсказуемо проваливается. Скрапинг-боты используют ротацию через residential proxy, где каждый IP делает единичные запросы - rate limiter их не ловит. Я видел скраперов, которые распределяли нагрузку на 10 000+ IP - по 2-3 запроса с каждого. Формально - обычные пользователи.

WAF от ботов и скрапинга: уровни детекции​

Статические правила WAF (блокировка по User-Agent, geo-фильтры, IP-репутация) - необходимый минимум, но не более того. Современные anti-scraping решения добавляют три уровня поведенческого анализа:

TLS/HTTP-fingerprinting. JA3/JA4-хеш TLS-хендшейка идентифицирует библиотеку запроса. Python requests и Go net/http дают характерные JA3-отпечатки, отличные от Chrome или Firefox. Против скриптов работает отлично, против headless-браузеров - бесполезно.

Browser fingerprinting. Canvas rendering, WebGL, список шрифтов, Audio API создают уникальный отпечаток посетителя. Headless-браузеры (Puppeteer, Playwright) оставляют артефакты: navigator.webdriver === true, отсутствие плагинов, характерные viewport-размеры. По данным Firecrawl, несоответствие между заявленным User-Agent и реальными capabilities - основной сигнал детекции автоматизации.

Поведенческий анализ сессии. Реальный пользователь скроллит, кликает, перемещает мышь. Скрапер делает только API-запросы без навигационного контекста. Graduated response - мониторинг, greylist, CAPTCHA-challenge, блок - минимизирует false positives и не мешает легитимным пользователям (A07:2021 - Identification and Authentication Failures по OWASP Top 10). Не надо сразу рубить - сначала присмотритесь.

Honeypot-эндпоинты и канареечные данные​

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

Три приёма, которые реально работают:

1. Скрытый эндпоинт через robots.txt. Добавьте Disallow: /api/v2/internal/users-export. Легитимные краулеры его пропустят, а скрапер, который читает robots.txt как карту сокровищ, отправит запрос. Любое обращение к этому URL - немедленный алерт (RS.AN-01 по NIST CSF v2.0).
2. Канареечные записи в ответах API. Встройте фейковые профили с уникальными email-адресами на домене-ловушке. Если такой email всплывёт в утёкшей базе - подтверждение скрапинга и точка для расследования. Простой, но элегантный трюк.
3. CSS-скрытые ссылки. Элемент с display:none, содержащий ссылку на API-эндпоинт: человек его не увидит, но бот, парсящий DOM - перейдёт.

Запрос к honeypot-эндпоинту = немедленная блокировка source IP, fingerprint и связанных сессий.

Мониторинг аномальной активности API: чек-лист для SOC​

Чек-лист покрывает DE.AE-01 по NIST CSF v2.0 (установка baseline и мониторинг аномалий) и RS.AN-01 (расследование алертов от систем детектирования). Начинайте с критических пунктов - они закрывают 80% вектора при минимальных затратах.

Массовый скрапинг - единственная категория API-атак, которую большинство SOC-команд до сих пор не мониторит вообще. Credential stuffing детектируют, DDoS отбивают, SQL injection WAF ловит. А когда бот тихо выкачивает профили со скоростью 5 RPS - это ниже радара, потому что формально ничего не ломает. Последствия проявляются позже: данные месяцами лежат на теневых площадках, потом возвращаются в credential stuffing-атаках уже против вас. И когда регулятор спрашивает, почему API с персональными данными работал без rate limiting на уровне эндпоинта - "мы не считали это угрозой" звучит как признание халатности.

На каждом втором проекте вижу одну и ту же картину: API-gateway настроен, rate-limiter стоит, но лимиты одинаковые для всех эндпоинтов. Поиск товаров и выдача PII пользователя живут с одним порогом в 100 RPS. Разделение лимитов по чувствительности данных - нулевые затраты на внедрение и кратный рост устойчивости. Отсутствие baseline по API-ключам партнёрских интеграций - вторая типичная дыра: инсайдер или скомпрометированный партнёр выкачивает данные штатным доступом, а SOC узнаёт об этом из Telegram-канала с утечками. Если вы строите мониторинг API-трафика с нуля или адаптируете правила под свой WAF-стек - на codeby.net коллеги ведут тред с разбором кейсов детектирования API-скрапинга и обменом конфигами под разные платформы.