**引入全新的主机体验 AWS WAF**

现在，您可以使用更新的体验访问控制台中任意位置的 AWS WAF 功能。有关更多详细信息，请参阅[使用控制台](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 使用 CAPTCHA 和Challenge 操作的最佳实践
<a name="waf-captcha-and-challenge-best-practices"></a>

按照本节中的指导来计划和实施 AWS WAF CAPTCHA 或质疑。

**规划您的验证码并质询实施**  
根据您的网站使用情况、要保护的数据的敏感度以及请求的类型，确定在哪里放置验证码拼图或静默质询。选择您要应用验证码的请求，这样您就可以根据需要展示拼图，但要避免在没有用处且可能降低用户体验的地方展示拼图。使用该Challenge操作来运行静默挑战，这些挑战对最终用户影响较小，但仍有助于验证请求是否来自 JavaScript 已启用的浏览器。

只有当浏览器访问 HTTPS 端点时，才能运行验证码拼图和静默质询。浏览器客户端必须在安全环境中运行才能获取令牌。

**决定在哪里对您的客户进行验证码拼图和静默质询**  
确定您不希望受到验证码影响的请求，例如对 CSS 或图像的请求。仅在必要时使用验证码。例如，如果您计划在登录时进行验证码检查，并且用户总是直接从登录到另一个屏幕，则可能不需要在第二个屏幕上进行验证码检查，这可能会降低您的最终用户体验。

配置Challenge并CAPTCHA使用，以便 AWS WAF 仅在响应请求时发送验证码谜题和静默挑战。`GET` `text/html`您不能运行拼图或质询来响应 `POST` 请求、跨源资源共享 (CORS) 预检 `OPTIONS` 请求或任何其他非 `GET` 请求类型。其他请求类型的浏览器行为可能有所不同，可能无法正确处理插页式广告。

客户可以接受 HTML，但仍然无法处理验证码或质询插页式广告。例如，带有小 iFrame 的网页上的控件可能接受 HTML，但无法显示或处理验证码。避免为这些类型的请求设置规则操作，就像对不接受 HTML 的请求一样。

**使用 CAPTCHA 或 Challenge 验证之前的令牌获取**  
在合法用户应始终拥有有效令牌的地方，您只能使用规则操作来验证是否存在有效令牌。在这些情况下，请求能否处理插页式广告并不重要。

例如，如果您实现了 JavaScript 客户端应用程序 CAPTCHA API，并在向受保护的端点发送第一个请求之前立即在客户端上运行 CAPTCHA 拼图，则您的第一个请求应始终包含对质询和验证码均有效的令牌。有关 JavaScript 客户端应用程序集成的信息，请参见[AWS WAF JavaScript 集成](waf-javascript-api.md)。

对于这种情况，您可以在保护包（web ACl）中添加与第一个调用匹配的规则，并使用 Challenge 或 CAPTCHA 规则操作对其进行配置。当规则与合法的最终用户和浏览器匹配时，该操作将找到有效的令牌，因此不会阻止请求或发送质询或验证码拼图作为响应。有关规则操作的工作原理的更多信息，请参阅 [CAPTCHA 和 Challenge 操作行为](waf-captcha-and-challenge-actions.md)。

**使用和保护带有 CAPTCHA 和 Challenge 的敏感非 HTML 数据**  
你可以使用验证码和对敏感的非 HTML 数据的Challenge保护，比如APIs，采用以下方法。

1. 识别接受 HTML 响应且与敏感的非 HTML 数据的请求非常接近的请求。

1. 编写与 HTML 请求相匹配且与敏感数据请求相匹配的 CAPTCHA 或 Challenge 规则。

1. 调整您的 CAPTCHA 和 Challenge 免疫时间设置，以便在正常的用户交互中，客户端从 HTML 请求中获得的令牌在请求您的敏感数据时可用且未过期。有关调整信息，请参阅 [将时间戳到期时间和令牌免疫时间设置为 AWS WAF](waf-tokens-immunity-times.md)。

当对您的敏感数据的请求与 CAPTCHA 或 Challenge 规则匹配时，如果客户端仍有来自先前拼图或质询的有效令牌，则该请求不会被阻止。如果令牌不可用或时间戳已过期，则访问您的敏感数据的请求将失败。有关规则操作的工作原理的更多信息，请参阅 [CAPTCHA 和 Challenge 操作行为](waf-captcha-and-challenge-actions.md)。

**使用验证码和 Challenge 以调整现有规则**  
查看您的现有规则，看看是否要修改或添加这些规则。以下是一些需要考虑的常见情况。
+ 如果您有阻止流量的基于速率的规则，但为了避免阻止合法用户，则将速率限制保持在相对较高的水平，请考虑在阻止规则之后添加第二条基于速率的规则。为第二条规则指定比阻止规则更低的限制，并将规则操作设置为 CAPTCHA 或 Challenge。阻止规则仍会阻止速率过高的请求，而新规则将以更低的速率阻止大多数自动流量。有关基于速率的规则的更多信息，请参阅 [在中使用基于费率的规则语句 AWS WAF](waf-rule-statement-type-rate-based.md)。
+ 如果您有阻止请求的托管规则组，则可以将部分或全部规则的行为从 Block 切换到 CAPTCHA 或 Challenge。为此，请在托管规则组配置中，覆盖规则操作设置。有关覆盖规则操作的信息，请参阅 [规则组规则操作的覆盖](web-acl-rule-group-override-options.md#web-acl-rule-group-override-options-rules)。

**在部署之前先测试您的验证码和质疑实施方案**  
至于所有新功能，请按照 [测试和调整您的 AWS WAF 保护措施](web-acl-testing.md) 中的指导进行操作。

在测试期间，请查看您的令牌时间戳到期要求，并设置您的 web ACL 和规则级别免疫时间配置，以便在控制网站访问权限和为客户提供良好体验之间取得良好的平衡。有关信息，请参阅[将时间戳到期时间和令牌免疫时间设置为 AWS WAF](waf-tokens-immunity-times.md)。