Scarnox · Blog

Captcha AWS WAF wyjaśnione i jak sobie z nim radzić

Captcha AWS WAF to wyzwanie serwowane przez Web Application Firewall Amazona, gdy właściciel serwisu skonfigurował go do sprawdzania odwiedzających. Żądanie, które firewall uzna za podejrzane, dostaje stronę z wyzwaniem zamiast treści. Odwiedzający musi wtedy przejść sprawdzenie, zanim załaduje się właściwa strona. Jeśli trafisz na nie podczas testów lub zbierania danych, musisz wiedzieć, jak je rozpoznać, co kontroluje właściciel serwisu i co Scarnox może zrobić dziś. Ten przewodnik omawia wszystkie trzy kwestie.

Czym jest captcha AWS WAF

AWS WAF to silnik reguł ustawiony przed aplikacją webową, na CloudFront Amazona, Application Load Balancerze lub API Gateway. Reguły mogą przepuszczać, blokować, zliczać lub wyzwać żądanie. Wyzwanie może być ciche, czyli sprawdzenie JavaScript, albo widoczną zagadką captcha, zależnie od tego, jak ustawiono regułę.

Ważne jest to, że decyzję podejmuje właściciel serwisu. Firewall nie zna celu Twojego scrapera. Ocenia wyłącznie ruch, który widzi: tempo żądań, reputację adresu IP, nagłówki i zachowanie klienta.

Jak rozpoznać je w kodzie

Wyzwania AWS WAF często da się rozpoznać po odpowiedziach. Częstym sygnałem jest nagłówek odpowiedzi x-amzn-waf-action, a wyzwanie bywa serwowane z kodem HTTP 202, zanim pojawi się właściwa strona. Traktuj to jako sygnał, a nie dowód, bo serwisy konfigurują firewall na różne sposoby:

import requests

def looks_like_aws_waf(resp: requests.Response) -> bool:
    # Sygnał w nagłówku, a nie dowód. Potwierdź na testowanej stronie.
    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)

Szukaj też skryptu załadowanego ze ścieżki wyzwania AWS WAF w kodzie źródłowym strony oraz strony, która nie pokazuje treści, dopóki nie uruchomi się skrypt. Zwykłe wywołanie requests często dostanie stronę z wyzwaniem zamiast danych. To jest oczekiwane.

Co może zrobić właściciel serwisu

Jeśli prowadzisz serwis, konsola AWS WAF pozwala dostroić reguły, które uruchamiają wyzwanie. Najbardziej przydatne opcje to:

Reguły oparte na tempie, które wyzwanie nakładają tylko na klientów wysyłających zbyt wiele żądań, dzięki czemu zwykli odwiedzający przechodzą bez problemu.
Allowlisty dla Twojego monitoringu, CI lub zakresów IP partnerów, aby Twoje własne testy nie były wyzwaniem.
Wyzwanie tylko na wrażliwych ścieżkach, takich jak logowanie lub koszyk, zamiast na całym serwisie.

Jeśli testujesz własny serwis, najczystszym rozwiązaniem jest allowlista dla Twoich runnerów testowych. Nie próbuj pokonywać wyzwania na serwisie, którego nie kontrolujesz. To ochrona właściciela i pierwsza rzecz, która odetnie Twój dostęp.

Gdzie stoi wsparcie Scarnox

Działa dziś: PopularCaptcha, bez proxy i z własnym proxy.
Wkrótce: AWS WAF, obok GeeTest, reCAPTCHA v2 i v3, Cloudflare Turnstile oraz Arkose. Nie projektuj produkcyjnego przepływu, który zależy od rozwiązania AWS WAF, dopóki nie będzie oznaczone jako działające.

Jeśli serwis, z którym możesz pracować, pokazuje dziś wyzwanie AWS WAF, masz do wyboru opcje wymienione wyżej: zwolnić, użyć allowlisty, jeśli serwis jest Twój, lub poprosić właściciela o API albo kanał danych. Możesz założyć konto i zacząć od darmowego kredytu próbnego, bez karty, aby skonfigurować już teraz przepływ PopularCaptcha i być gotowym, gdy wsparcie AWS WAF zostanie uruchomione. Aktualne ceny znajdziesz na stronie cennika.

Przetestuj własny serwis za AWS WAF

Jeśli jesteś właścicielem serwisu i chcesz, by zautomatyzowane testy przechodziły przez firewall bez osłabiania go dla prawdziwych odwiedzających, użyj własnych narzędzi firewalla zamiast obchodzenia wyzwania:

Utwórz nową regułę w trybie count. Zapisuje ona żądania, które zostałyby wyzwane, bez wpływu na kogokolwiek, dzięki czemu widzisz dokładnie, co wywołują Twoje testy.
Włącz logowanie WAF do Amazon CloudWatch Logs, Amazon S3 lub Amazon Data Firehose. Log pokaże, która reguła zadziałała i który nagłówek lub ścieżka ją wywołały.
Daj środowisku testowemu osobną domenę stagingową z odrębnym zestawem reguł, aby produkcja pozostała chroniona, a Twój zestaw testów działał swobodnie.
Dodaj do allowlisty tylko konkretne zakresy IP lub wartości nagłówków, których używają Twoje runnery, i przeglądaj tę listę za każdym razem, gdy runnery się zmienią.

Te kroki utrzymują ochronę na miejscu i sprawiają, że ruch testowy jest przewidywalny, a to właśnie jest potrzebny rezultat. Przeglądaj reguły po każdej zmianie w konfiguracji testów, bo reguła poprawna dla runnerów z zeszłego miesiąca może dziś ich blokować.

Scrapuj odpowiedzialnie

Jeśli celem wejścia na stronę AWS WAF jest zbieranie danych:

Przeczytaj robots.txt i regulamin serwisu przed wysłaniem żądań.
Utrzymuj niskie tempo żądań. Wyzwanie bywa sposobem, w jaki serwis prosi Cię o zwolnienie.
Zatrzymaj się, gdy serwis wyraźnie nie chce zautomatyzowanego dostępu.
Nie zbieraj danych osobowych, których nie masz powodu przechowywać, a te, które zbierzesz, obsługuj zgodnie z obowiązującymi przepisami o prywatności.