AWS WAF капча: що це і як з нею працювати
AWS WAF капча — це виклик, який подає веб-фаєрвол Amazon, коли власник сайту налаштував його перевіряти відвідувачів. Запит, який фаєрвол вважає підозрілим, отримує сторінку з викликом замість вмісту. Відвідувач має пройти перевірку, перш ніж завантажиться справжня сторінка. Якщо ви натрапили на неї під час тестування або збору даних, потрібно знати, як її розпізнати, що контролює власник сайту і що 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 можна налаштувати правила, які запускають виклик. Найкорисніші опції:
- Правила на основі частоти, які ставлять виклик лише клієнтам, що надсилають забагато запитів, щоб звичайні відвідувачі проходили без перешкод.
- Allowlist для вашого моніторингу, CI або IP-діапазонів партнерів, щоб ваші власні тести не потрапляли під виклик.
- Виклик лише на чутливих шляхах, наприклад входу або оформлення замовлення, а не на всьому сайті.
Якщо тестуєте власний сайт, найчистіше рішення — allowlist для ваших тестових раннерів. Не намагайтеся подолати виклик на сайті, яким не керуєте. Це захист власника, і саме він першим перекриє вам доступ.
Де зараз підтримка Scarnox
- Працює зараз: PopularCaptcha, proxyless і з власним проксі.
- Скоро: AWS WAF, разом з GeeTest, reCAPTCHA v2 і v3, Cloudflare Turnstile та Arkose. Не будуйте промисловий процес, який залежить від розв'язання AWS WAF, доки він не буде позначений як робочий.
Отже, якщо сайт, з яким вам дозволено працювати, сьогодні показує виклик AWS WAF, у вас є варіанти, описані вище: сповільнитися, використати allowlist, якщо сайт ваш, або попросити власника про API чи канал даних. Ви можете створити обліковий запис і почати з безкоштовного пробного кредиту, картка не потрібна, щоб налаштувати процес PopularCaptcha зараз і бути готовими, коли підтримка AWS WAF з'явиться. Актуальні тарифи є на сторінці цін.
Тестування власного сайту за AWS WAF
Якщо ви власник сайту і хочете, щоб автоматизовані тести проходили фаєрвол, не послаблюючи його для реальних відвідувачів, використовуйте власні інструменти фаєрвола, а не обходьте виклик:
- Створіть нове правило в режимі count. Воно фіксує запити, які отримали б виклик, нікого не зачіпаючи, тож ви бачите, що саме спричиняють ваші тести.
- Увімкніть логування WAF у Amazon CloudWatch Logs, Amazon S3 або Amazon Data Firehose. Лог покаже, яке правило спрацювало і який заголовок або шлях його викликав.
- Виділіть тестовому середовищу окремий staging-домен з окремим набором правил, щоб продакшн залишався захищеним, поки ваш набір тестів працює вільно.
- Додавайте в allowlist лише конкретні IP-діапазони або значення заголовків, які використовують ваші тестові раннери, і переглядайте цей список щоразу, коли раннери змінюються.
Ці кроки зберігають захист і роблять тестовий трафік передбачуваним, а це і є результат, якого вам справді потрібно. Переглядайте правила після кожної зміни тестового середовища, бо правило, правильне для раннерів минулого місяця, тепер може їх блокувати.
Scrape responsibly
Якщо ви натрапили на сторінку AWS WAF, бо збираєте дані:
- Прочитайте
robots.txtсайту і умови використання, перш ніж надсилати запити. - Тримайте низьку частоту запитів. Виклик часто означає, що сайт просить вас сповільнитися.
- Зупиніться, коли сайт явно не хоче автоматизованого доступу.
- Не збирайте персональних даних, які вам не потрібні, і обробляйте ті, що збираєте, відповідно до чинних правил конфіденційності.