Scarnox · Blog

Капча AWS WAF: что это и как с ней работать

Капча AWS WAF — это челлендж, который выдаёт веб-файрвол Amazon Web Application Firewall, когда владелец сайта настроил проверку посетителей. Запрос, который файрвол считает подозрительным, получает страницу-челлендж вместо содержимого. Посетитель должен пройти проверку, прежде чем загрузится настоящая страница. Если вы столкнулись с ней во время тестов или сбора данных, нужно знать, как её распознать, что контролирует владелец сайта и что Scarnox может сделать сегодня. Этот гайд охватывает все три вопроса.

Что такое капча AWS WAF

AWS WAF — это движок правил, который стоит перед веб-приложением: на Amazon CloudFront, Application Load Balancer или API Gateway. Правила могут разрешить, заблокировать, только посчитать или проверить запрос. Челлендж может быть тихой JavaScript-проверкой или видимой капчей — в зависимости от настройки правила.

Важно, что решение принимает владелец сайта. Файрвол не знает, зачем вашему скрейперу данные. Он оценивает только трафик, который видит: частоту запросов, репутацию IP-адреса, заголовки и поведение клиента.

Как распознать её в коде

Челленджи AWS WAF часто можно узнать по ответам. Частый признак — заголовок ответа x-amzn-waf-action, а челлендж нередко отдаётся с HTTP-статусом 202 до появления настоящей страницы. Считайте это признаками, а не доказательством, потому что сайты настраивают файрвол по-разному:

import requests

def looks_like_aws_waf(resp: requests.Response) -> bool:
    # Признак по заголовку, а не доказательство. Проверьте на странице, которую тестируете.
    return "x-amzn-waf-action" in resp.headers

resp = requests.get("https://example.com/products", timeout=30)
if looks_like_aws_waf(resp):
    print("Challenge served. Stop, slow down, and check your request rate.")
else:
    print("Status", resp.status_code)

Также ищите в исходном коде страницы скрипт, загруженный с пути челленджа AWS WAF, и страницу, которая не показывает содержимое, пока не выполнится скрипт. Простой вызов requests часто получает страницу-челлендж, а не данные. Это ожидаемо.

Что может сделать владелец сайта

Если сайт ваш, консоль AWS WAF позволяет настроить правила, которые запускают челлендж. Самые полезные опции:

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

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

Где сейчас поддержка Scarnox

Работает сегодня: PopularCaptcha, proxyless и со своим прокси.
Скоро: AWS WAF, а также GeeTest, reCAPTCHA v2 и v3, Cloudflare Turnstile и Arkose. Не проектируйте продакшн-поток, который опирается на решение AWS WAF, пока оно не отмечено как работающее.

Так что если сайт, с которым вам разрешено работать, сегодня показывает челлендж AWS WAF, у вас есть варианты, описанные выше: замедлиться, добавить белый список, если сайт ваш, или попросить владельца о API или потоке данных. Вы можете создать аккаунт и начать с пробного баланса, карта не нужна. Так вы настроите поток PopularCaptcha уже сейчас и будете готовы, когда поддержка AWS WAF выйдет. Актуальные цены — на странице тарифов.

Тестирование собственного сайта за AWS WAF

Если вы владелец сайта и хотите, чтобы автотесты проходили файрвол, не ослабляя защиту для реальных посетителей, используйте собственные инструменты файрвола, а не обход челленджа:

Создайте новое правило в режиме count. Оно фиксирует запросы, которые были бы проверены, и никого не затрагивает, так что вы видите, что именно вызывают ваши тесты.
Включите логирование WAF в Amazon CloudWatch Logs, Amazon S3 или Amazon Data Firehose. Лог покажет, какое правило сработало и какой заголовок или путь стал причиной.
Дайте тестовому окружению отдельный staging-домен с собственным набором правил, чтобы продакшн оставался защищённым, а тестовый набор работал свободно.
Добавляйте в белый список только конкретные IP-диапазоны или значения заголовков, которые используют ваши тестовые раннеры, и пересматривайте список при каждом изменении раннеров.

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

Парсите ответственно

Если вы попали на страницу AWS WAF, потому что собираете данные:

Прочитайте robots.txt и условия использования сайта, прежде чем отправлять запросы.
Держите низкую частоту запросов. Челлендж часто означает, что сайт просит вас замедлиться.
Остановитесь, если сайт явно не хочет автоматизированного доступа.
Не собирайте персональные данные, которые вам не нужны, и обрабатывайте собранные по применимым правилам защиты данных.