Captcha do AWS WAF explicado e como lidar com ele
O captcha do AWS WAF é um desafio servido pelo Web Application Firewall da Amazon quando o dono de um site configurou a proteção para verificar os visitantes. Uma requisição que o firewall considera suspeita recebe uma página de desafio no lugar do conteúdo. O visitante então precisa passar por uma verificação antes que a página real carregue. Se você encontrar isso durante testes ou coleta de dados, precisa saber reconhecê-lo, o que o dono do site controla e o que a Scarnox pode fazer hoje. Este guia cobre os três pontos.
O que é o captcha do AWS WAF
O AWS WAF é um motor de regras que fica na frente de uma aplicação web, no Amazon CloudFront, em um Application Load Balancer ou em um API Gateway. As regras podem permitir, bloquear, apenas contar ou desafiar uma requisição. Um desafio pode ser uma verificação silenciosa em JavaScript ou um puzzle de captcha visível, dependendo de como a regra foi configurada.
O ponto importante é que a decisão é tomada pelo dono do site. O firewall não conhece a finalidade do seu scraper. Ele apenas avalia o tráfego que vê: a taxa de requisições, a reputação do IP, os cabeçalhos e o comportamento do cliente.
Como reconhecê-lo no código
Os desafios do AWS WAF costumam ser identificáveis pelas respostas. Um sinal comum é o cabeçalho de resposta x-amzn-waf-action, e um desafio costuma ser servido com status HTTP 202 antes de a página real aparecer. Trate esses itens como sinais, não como prova, porque os sites configuram o firewall de formas diferentes:
import requests
def looks_like_aws_waf(resp: requests.Response) -> bool:
# Um sinal pelo cabeçalho, não uma prova. Confirme na página que você está testando.
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)
Procure também um script carregado de um caminho de desafio do AWS WAF no código-fonte da página, e uma página que não mostra conteúdo até que um script seja executado. Uma chamada simples com requests frequentemente recebe a página de desafio em vez dos dados. Isso é esperado.
O que o dono do site pode fazer
Se você administra o site, o console do AWS WAF permite ajustar as regras que disparam um desafio. As opções mais úteis são:
- Regras baseadas em taxa, que desafiam apenas clientes que enviam requisições demais, para que os visitantes normais passem.
- Allowlists para o seu monitoramento, CI ou faixas de IP de parceiros, para que os seus próprios testes não sejam desafiados.
- Desafio apenas em caminhos sensíveis, como login ou checkout, em vez do site inteiro.
Se você está testando o seu próprio site, a solução mais limpa é uma allowlist para os seus runners de teste. Não tente derrotar o desafio em um site que você não controla. Essa é a proteção do dono, e é a primeira coisa que vai quebrar o seu acesso.
Onde está o suporte da Scarnox
- Disponível hoje: PopularCaptcha, proxyless e com o seu próprio proxy.
- Em breve: AWS WAF, junto com GeeTest, reCAPTCHA v2 e v3, Cloudflare Turnstile e Arkose. Não crie um fluxo de produção que dependa de uma resolução do AWS WAF até que ela esteja listada como disponível.
Então, se um site com o qual você tem permissão para trabalhar mostrar um desafio do AWS WAF hoje, as opções são as descritas acima: desacelerar, usar uma allowlist se o site for seu, ou pedir ao dono uma API ou feed de dados. Você pode criar uma conta e começar com crédito de teste grátis, sem cartão, para configurar agora o seu fluxo com PopularCaptcha e estar pronto quando o suporte ao AWS WAF for lançado. Os preços atuais estão na página de preços.
Teste o seu próprio site atrás do AWS WAF
Se você é o dono do site e quer que os testes automatizados passem pelo firewall sem enfraquecê-lo para os visitantes reais, use as ferramentas do próprio firewall em vez de contornar o desafio:
- Crie uma nova regra no modo count. Ela registra as requisições que seriam desafiadas sem afetar ninguém, para que você veja exatamente o que os seus testes disparam.
- Ative o log do WAF para o Amazon CloudWatch Logs, o Amazon S3 ou o Amazon Data Firehose. O log mostra qual regra foi acionada e qual cabeçalho ou caminho causou isso.
- Dê ao ambiente de teste o seu próprio domínio de staging com um conjunto de regras separado, para que a produção continue protegida enquanto a sua suíte roda livremente.
- Faça allowlist apenas das faixas de IP ou valores de cabeçalho específicos que os seus runners usam, e revise essa lista sempre que os runners mudarem.
Esses passos mantêm a proteção no lugar e tornam o tráfego de teste previsível, que é o resultado que você realmente precisa. Revise as regras após cada mudança na configuração de testes, porque uma regra que estava correta para os runners do mês passado pode bloqueá-los agora.
Faça scraping com responsabilidade
Se o seu motivo para acessar uma página do AWS WAF é coletar dados:
- Leia o
robots.txte os termos de uso do site antes de enviar requisições. - Mantenha a taxa de requisições baixa. Um desafio costuma ser o site pedindo que você desacelere.
- Pare quando o site deixar claro que não quer acesso automatizado.
- Não colete dados pessoais sem motivo para tê-los, e trate com cuidado qualquer dado pessoal que colete, de acordo com as regras de privacidade aplicáveis.