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 콘솔에서 챌린지를 발동시키는 규칙을 조정할 수 있습니다. 가장 유용한 옵션은 다음과 같습니다.
- 요청 빈도 기반 규칙. 요청을 너무 많이 보내는 클라이언트만 챌린지하므로 일반 방문자는 통과합니다.
- 허용 목록. 자체 모니터링, CI 또는 파트너 IP 대역을 등록하면 내 테스트가 챌린지되지 않습니다.
- 민감한 경로에만 챌린지. 사이트 전체가 아니라 로그인이나 결제처럼 민감한 경로에만 적용합니다.
내가 운영하는 사이트를 테스트하는 중이라면, 가장 깔끔한 해결책은 테스트 러너용 허용 목록입니다. 내가 통제하지 않는 사이트에서 챌린지를 무력화하려고 하지 마세요. 그것은 운영자의 보호 장치이며, 여러분의 접근을 가장 먼저 막는 것이기도 합니다.
Scarnox 지원 현황
- 현재 운영 중: PopularCaptcha, 프록시 없음 및 자체 프록시 사용.
- 준비 중: 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로 켜세요. 로그에는 어떤 규칙이 매칭되었고 어떤 헤더나 경로가 원인이었는지가 나옵니다.
- 테스트 환경에는 별도의 규칙 세트를 가진 자체 스테이징 도메인을 부여하세요. 그러면 실제 운영 환경은 보호된 상태로 유지되고, 테스트 스위트는 자유롭게 실행됩니다.
- 테스트 러너가 사용하는 특정 IP 대역이나 헤더 값만 허용 목록에 추가하고, 러너가 바뀔 때마다 그 목록을 검토하세요.
이 단계들은 보호를 유지하면서 테스트 트래픽을 예측 가능하게 만들며, 이것이 실제로 필요한 결과입니다. 테스트 설정을 바꿀 때마다 규칙을 검토하세요. 지난달 러너에 맞았던 규칙이 지금은 그 러너를 차단할 수 있습니다.
스크래핑은 책임감 있게
AWS WAF 페이지에 접근하는 이유가 데이터 수집이라면:
- 요청을 보내기 전에 사이트의
robots.txt와 이용 약관을 읽으세요. - 요청 속도를 낮게 유지하세요. 챌린지는 종종 사이트가 속도를 줄여 달라고 요청하는 것입니다.
- 사이트가 자동화된 접근을 원하지 않는다는 것이 분명하면 멈추세요.
- 보관할 이유가 없는 개인 데이터는 수집하지 말고, 수집한 것은 해당 개인정보 규정에 따라 처리하세요.