Scarnox · Blog

Captcha AWS WAF expliqué et comment le gérer

Le captcha AWS WAF est un défi servi par le pare-feu applicatif d'Amazon (Web Application Firewall) lorsqu'un propriétaire de site l'a configuré pour contrôler les visiteurs. Une requête jugée suspecte par le pare-feu reçoit une page de défi au lieu du contenu. Le visiteur doit alors passer une vérification avant que la vraie page ne se charge. Si vous tombez dessus pendant des tests ou une collecte de données, vous devez savoir le reconnaître, ce que le propriétaire du site contrôle, et ce que Scarnox peut faire aujourd'hui. Ce guide couvre les trois points.

Ce qu'est le captcha AWS WAF

AWS WAF est un moteur de règles placé devant une application web, sur Amazon CloudFront, un Application Load Balancer ou une API Gateway. Les règles peuvent autoriser, bloquer, compter ou soumettre une requête à un défi. Un défi peut être une vérification JavaScript silencieuse ou un puzzle captcha visible, selon la façon dont la règle est définie.

Le point important est que la décision appartient au propriétaire du site. Le pare-feu ne connaît pas l'objectif de votre scraper. Il évalue seulement le trafic qu'il voit : le rythme des requêtes, la réputation de l'IP, les en-têtes et le comportement du client.

Comment le reconnaître dans le code

Les défis AWS WAF sont souvent identifiables à leurs réponses. Un signal courant est l'en-tête de réponse x-amzn-waf-action, et un défi est souvent servi avec le statut HTTP 202 avant l'apparition de la vraie page. Considérez-les comme des indices, pas comme une preuve, car les sites configurent le pare-feu différemment :

import requests

def looks_like_aws_waf(resp: requests.Response) -> bool:
    # Un signal d'en-tête, pas une preuve. Vérifiez sur la page que vous testez.
    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)

Cherchez aussi un script chargé depuis un chemin de défi AWS WAF dans le code source de la page, et une page qui n'affiche aucun contenu tant qu'un script ne s'exécute pas. Un simple appel requests recevra souvent la page de défi plutôt que les données. C'est attendu.

Ce que le propriétaire du site peut faire

Si vous gérez le site, la console AWS WAF vous permet d'ajuster les règles qui déclenchent un défi. Les options les plus utiles sont :

Des règles basées sur le débit qui ne soumettent à un défi que les clients envoyant trop de requêtes, afin que les visiteurs normaux passent.
Des listes blanches pour vos plages d'IP de supervision, d'intégration continue ou de partenaires, afin que vos propres tests ne soient pas contestés.
Un défi uniquement sur les chemins sensibles, comme la connexion ou le paiement, plutôt que sur tout le site.

Si vous testez votre propre site, la solution la plus propre est une liste blanche pour vos runners de test. N'essayez pas de contourner le défi sur un site que vous ne contrôlez pas. C'est la protection du propriétaire, et c'est la première chose qui bloquera votre accès.

Où en est le support Scarnox

Disponible aujourd'hui : PopularCaptcha, sans proxy et avec votre propre proxy.
Bientôt disponible : AWS WAF, avec GeeTest, reCAPTCHA v2 et v3, Cloudflare Turnstile et Arkose. Ne concevez pas de flux de production qui repose sur une résolution AWS WAF tant qu'elle n'est pas listée comme disponible.

Donc, si un site avec lequel vous êtes autorisé à travailler affiche aujourd'hui un défi AWS WAF, les options sont celles décrites plus haut : ralentir, utiliser une liste blanche si le site vous appartient, ou demander au propriétaire du site une API ou un flux de données. Vous pouvez créer un compte et démarrer avec un crédit d'essai gratuit, sans carte bancaire, pour mettre en place votre flux PopularCaptcha dès maintenant et être prêt lorsque le support AWS WAF sera disponible. Les tarifs actuels figurent sur la page tarifs.

Testez votre propre site derrière AWS WAF

Si vous êtes propriétaire du site et souhaitez que vos tests automatisés franchissent le pare-feu sans l'affaiblir pour les vrais visiteurs, utilisez les outils du pare-feu plutôt que de contourner le défi :

Créez une nouvelle règle en mode count. Elle enregistre les requêtes qui auraient été soumises à un défi sans affecter personne, afin que vous voyiez exactement ce que déclenchent vos tests.
Activez la journalisation WAF vers Amazon CloudWatch Logs, Amazon S3 ou Amazon Data Firehose. Le journal indique quelle règle a correspondu et quel en-tête ou quel chemin en est la cause.
Donnez à l'environnement de test son propre domaine de staging avec un jeu de règles séparé, afin que la production reste protégée pendant que votre suite tourne librement.
Ne mettez en liste blanche que les plages d'IP ou les valeurs d'en-têtes précises utilisées par vos runners de test, et revoyez cette liste chaque fois que les runners changent.

Ces étapes maintiennent la protection en place et rendent le trafic de test prévisible, ce qui est le résultat dont vous avez réellement besoin. Revoyez les règles après chaque modification de votre configuration de test, car une règle correcte pour les runners du mois dernier peut aujourd'hui les bloquer.

Scrapez de manière responsable

Si votre raison de solliciter une page AWS WAF est la collecte de données :

Lisez le robots.txt et les conditions d'utilisation du site avant d'envoyer des requêtes.
Gardez un rythme de requêtes faible. Un défi signifie souvent que le site vous demande de ralentir.
Arrêtez-vous lorsque le site ne veut clairement pas d'accès automatisé.
Ne collectez pas de données personnelles dont vous n'avez aucune raison de disposer, et traitez celles que vous collectez malgré tout selon les règles de confidentialité applicables.