CAPTCHA 및 Challenge 작업 사용 모범 사례

이 섹션의 지침에 따라 AWS WAF CAPTCHA 또는 챌린지를 계획하고 구현하십시오.

CAPTCHA 및 챌린지 구현 계획

웹사이트 사용량, 보호하려는 데이터의 민감도 및 요청 유형에 따라 CAPTCHA 퍼즐이나 자동 챌린지를 배치할 위치를 결정합니다. 필요에 따라 퍼즐을 제시하도록 CAPTCHA를 적용할 요청을 선택하되, 유용하지 않고 사용자 경험을 저하시킬 수 있는 경우에는 제시하지 마십시오. 이 Challenge 작업을 사용하면 최종 사용자에게 미치는 영향은 적지만 JavaScript 활성화된 브라우저에서 요청이 오는지 확인하는 데 도움이 되는 자동 챌린지를 실행할 수 있습니다.

클라이언트에서 CAPTCHA 퍼즐과 자동 챌린지를 실행할 위치 결정

CAPTCHA의 영향을 받지 않도록 할 요청(예: CSS 또는 이미지 요청)을 식별합니다. 필요한 경우에만 CAPTCHA를 사용하십시오. 예를 들어 로그인 시 CAPTCHA 검사를 실시할 계획이고 사용자가 항상 로그인 화면에서 다른 화면으로 직접 이동하는 경우 두 번째 화면에서 CAPTCHA 검사 요구는 아마도 필요하지 않을 것이며 최종 사용자 경험을 저하시킬 것입니다.

요청에 대한 응답으로 CAPTCHA 퍼즐과 사일런트 AWS WAF 챌린지만 전송하도록 Challenge 구성하고 CAPTCHA 사용하십시오. GET text/html POST 요청, 교차 오리진 리소스 공유(CORS) 프리플라이트 OPTIONS 요청 또는 기타 비 GET 요청 유형에 대한 응답으로는 퍼즐이나 챌린지를 실행할 수 없습니다. 다른 요청 유형의 브라우저 동작은 다를 수 있으며 중간 광고를 제대로 처리하지 못할 수 있습니다.

클라이언트가 HTML을 허용하지만 여전히 CAPTCHA 또는 챌린지 중간 광고를 처리하지 못할 수 있습니다. 예를 들어 작은 iFrame을 포함하는 웹 페이지의 위젯은 HTML은 허용하지만 CAPTCHA를 표시하거나 처리하지 못할 수 있습니다. HTML을 허용하지 않는 요청과 마찬가지로 이러한 유형의 요청에는 규칙 작업을 배치하지 마십시오.

CAPTCHA또는 Challenge 를 사용하여 이전 토큰 획득을 확인합니다.

합법적인 사용자가 항상 토큰을 보유해야 하는 위치에서는 유효한 토큰의 존재 여부를 확인하는 용도로만 규칙 조치를 사용할 수 있습니다. 이러한 상황에서는 요청이 중간 광고를 처리할 수 있는지 여부는 중요하지 않습니다.

예를 들어 JavaScript 클라이언트 애플리케이션 CAPTCHA API를 구현하고 보호된 엔드포인트에 첫 번째 요청을 보내기 직전에 클라이언트에서 CAPTCHA 퍼즐을 실행하는 경우 첫 번째 요청에는 항상 챌린지와 CAPTCHA 모두에 유효한 토큰이 포함되어야 합니다. 클라이언트 애플리케이션 통합에 대한 JavaScript 자세한 내용은 을 참조하십시오. AWS WAF JavaScript 통합

이 상황에서는 웹 ACL에서 이 첫 번째 호출과 일치하는 규칙을 추가하고 Challenge 또는 CAPTCHA 규칙 작업을 사용하여 해당 규칙을 구성할 수 있습니다. 규칙이 합법적인 최종 사용자와 브라우저에 대해 일치하는 경우 이 작업은 유효한 토큰을 찾게 되므로 요청을 차단하거나 이에 대한 응답으로 챌린지 또는 CAPTCHA 퍼즐을 보내지 않습니다. 규칙 작업 작동 방식에 대한 자세한 내용은 CAPTCHA 및 Challenge 작업 동작 섹션을 참조하세요.

CAPTCHA 및 Challenge를 사용하여 민감한 비 HTML 데이터 보호

다음 접근 방식을 통해 API와 같은 민감한 비 HTML 데이터에 CAPTCHA 및 Challenge 보호 기능을 사용할 수 있습니다.

1. 민감한 비 HTML 데이터에 대한 요청과 매우 근접한 곳에서 실행되는 요청과 HTML 응답을 받는 요청을 식별합니다.

2. HTML 요청과 일치하고 민감한 데이터에 대한 요청과 일치하는 CAPTCHA 또는 Challenge 규칙을 작성합니다.

3. 일반적인 사용자 상호 작용의 경우 클라이언트가 HTML 요청에서 획득한 토큰을 민감한 데이터에 대한 요청에서 사용할 수 있고 만료되지 않도록 하려면 CAPTCHA 및 Challenge 면제 시간 설정을 조정합니다. 조정 정보는 타임스탬프 만료: 토큰 면제 시간 섹션을 참조하세요.

민감한 데이터에 대한 요청이 CAPTCHA 또는 Challenge 규칙과 일치하더라도 클라이언트가 이전 퍼즐 또는 챌린지의 유효한 토큰을 여전히 가지고 있다면 해당 요청은 차단되지 않습니다. 토큰을 사용할 수 없거나 타임스탬프가 만료되면 민감한 데이터에 대한 액세스 요청이 실패합니다. 규칙 작업 작동 방식에 대한 자세한 내용은 CAPTCHA 및 Challenge 작업 동작 섹션을 참조하세요.

CAPTCHA 및 Challenge를 사용하여 기존 규칙을 조정합니다.

기존 규칙을 검토하여 이들 규칙을 변경할지 아니면 이들 규칙에 추가할지 알아봅니다. 고려해야 할 몇 가지 일반 시나리오는 다음과 같습니다.

• 트래픽을 차단하는 속도 기반 규칙이 있지만 합법적인 사용자를 차단하지 않기 위해 속도 제한을 비교적 높게 유지하는 경우 차단 규칙 다음에 두 번째 속도 기반 규칙을 추가하는 것을 고려해 보십시오. 두 번째 규칙에는 차단 규칙보다 낮은 제한을 지정하고 규칙 작업은 CAPTCHA 또는 Challenge로 설정합니다. 차단 규칙은 너무 높은 속도로 들어오는 요청을 여전히 차단하며, 새 규칙은 더 낮은 속도의 대부분의 자동화된 트래픽을 차단합니다. 속도 기반 규칙에 대한 자세한 내용은 비율 기반 규칙 문 섹션을 참조하세요.

• 요청을 차단하는 관리형 규칙 그룹이 있는 경우 일부 또는 모든 규칙의 동작을 Block에서 CAPTCHA 또는 Challenge로 전환할 있습니다. 이렇게 하려면 관리형 규칙 그룹 구성에서 규칙 작업 설정을 재정의합니다. 규칙 작업 재정의에 대한 자세한 내용은 규칙 작업 재정의 섹션을 참조하세요.

배포하기 전에 CAPTCHA 및 챌린지 테스트

모든 새 기능에 대해서는 AWS WAF 보호 기능 테스트 및 조정의 지침을 따르십시오.

테스트 중에 토큰 타임스탬프 만료 요구 사항을 검토하고 웹 ACL 및 규칙 수준 면제 시간 구성을 설정하여 웹 사이트에 대한 액세스 제어와 우수한 고객 경험 사이에서 적절한 균형을 이룰 수 있습니다. 자세한 내용은 타임스탬프 만료: 토큰 면제 시간 섹션을 참조하세요.