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

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

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

# CAPTCHA然后Challenge在 AWS WAF
<a name="waf-captcha-and-challenge"></a>

本节介绍如何使用CAPTCHA和Challenge使用 AWS WAF。

您可以将 AWS WAF 规则配置为对符合规则检查标准的 Web 请求运行CAPTCHA或Challenge操作。您还可以对 JavaScript 客户端应用程序进行编程，使其在本地运行 CAPTCHA 拼图和浏览器挑战。

只有当浏览器访问 HTTPS 端点时，才能运行验证码拼图和静默质询。浏览器客户端必须在安全环境中运行才能获取令牌。
+ **CAPTCHA**：要求最终用户完成验证码拼图，以证明是人类在发送请求。验证码拼图旨在让人类相当容易和快速地成功完成拼图，而计算机很难成功完成或随机完成。

  在保护包（web ACl）规则中，当 Block 操作会阻止过多的合法请求时，通常使用验证码，但是让所有流量通过会导致大量不想要的请求，例如来自机器人的请求。有关规则操作行为的信息，请参阅 [CAPTCHA AWS WAF 和 Challenge 规则操作的工作原理](waf-captcha-and-challenge-how-it-works.md)。

  您还可以在客户端应用程序集成中对验证码拼图实现进行编程。 APIs当这样做时，您可以在客户端应用程序中自定义拼图的行为和位置。有关更多信息，请参阅 [中的客户端应用程序集成 AWS WAF](waf-application-integration.md)。
+ **Challenge**：运行静默质询，要求客户端会话验证它是浏览器，而不是机器人。验证在后台运行，不涉及最终用户。这是一个不错的选择，可以验证您怀疑无效的客户端，而不会通过验证码拼图对最终用户体验产生负面影响。有关规则操作行为的信息，请参阅 [CAPTCHA AWS WAF 和 Challenge 规则操作的工作原理](waf-captcha-and-challenge-how-it-works.md)。

  Challenge规则操作与客户端智能威胁集成运行的挑战类似 APIs，如中所述[中的客户端应用程序集成 AWS WAF](waf-application-integration.md)。

**注意**  
当您在其中一个规则中使用 CAPTCHA 或 Challenge 规则操作或在规则组中将其作为规则操作覆盖时，您需要支付额外费用。有关更多信息，请参阅[AWS WAF 定价](https://aws.amazon.com/waf/pricing/)。

有关所有规则操作选项的信息，请参阅 [在中使用规则操作 AWS WAF](waf-rule-action.md)。

**Topics**
+ [AWS WAF 验证码拼图](waf-captcha-puzzle.md)
+ [CAPTCHA AWS WAF 和 Challenge 规则操作的工作原理](waf-captcha-and-challenge-how-it-works.md)
+ [使用 CAPTCHA 和Challenge 操作的最佳实践](waf-captcha-and-challenge-best-practices.md)

# AWS WAF 验证码拼图
<a name="waf-captcha-puzzle"></a>

本节介绍 AWS WAF 验证码拼图的特点和功能。

AWS WAF 提供标准的 CAPTCHA 功能，要求用户确认自己是人类。验证码代表完全自动化的公共图灵测试，用于区分计算机和人类。验证码拼图旨在验证人类是否在发送请求，并防止网页抓取、凭证填充和垃圾邮件等活动。验证码拼图无法清除所有不需要的请求。许多拼图已经可以通过机器学习和人工智能来完成。为了规避验证码，一些组织通过人工干预来补充自动化技术。尽管如此，验证码仍然是防止不太复杂的机器人流量和增加大规模运营所需资源的有用工具。

AWS WAF 随机生成其 CAPTCHA 谜题并轮流浏览它们，以确保向用户提供独特的挑战。 AWS WAF 定期添加新的谜题类型和风格，以保持对抗自动化技术的有效性。除了谜题之外， AWS WAF CAPTCHA脚本还收集有关客户端的数据，以确保任务由人类完成并防止重播攻击。

每个验证码拼图都包含一组标准控件，供最终用户申请新拼图、在音频和视觉拼图之间切换、访问其他说明以及提交拼图解决方案。所有拼图都支持屏幕阅读器、键盘控制和对比色。

 AWS WAF CAPTCHA 拼图符合《网络内容无障碍指南》(WCAG) 的要求。有关信息，请参阅万维网联盟 (W3C) 网站上的[网络内容无障碍指南 (WCAG) 概述](https://www.w3.org/WAI/standards-guidelines/wcag/)。

**Topics**
+ [验证码拼图的语言支持](waf-captcha-puzzle-language-support.md)
+ [验证码拼图示例](waf-captcha-puzzle-examples.md)

# 验证码拼图的语言支持
<a name="waf-captcha-puzzle-language-support"></a>

本节列出了 AWS WAF 验证码拼图支持哪些语言。

验证码拼图从采用客户端浏览器语言的书面指令开始，如果不支持浏览器语言，则使用英语。拼图通过下拉菜单提供了其他语言选项。

用户可以通过选择页面底部的耳机图标来切换到音频指令。音频版拼图提供文本的口语说明，用户应将其键入文本框中的文本，上面叠加了背景噪音。

下表列出了可以为验证码拼图中的书面指令选择的语言以及每种选择的音频支持。


**AWS WAF CAPTCHA 拼图支持的语言**  

| 书面指令支持 | 区域代码 | 音频指令支持 | 
| --- | --- | --- | 
|  阿拉伯语  |  ar-SA  |  阿拉伯语  | 
|  简体中文  |  zh-CN  |  英语音频  | 
|  荷兰料理  |  nl-NL  |  荷兰料理  | 
|  English  |  en-US  |  English  | 
|  法式料理  |  fr-FR  |  法式料理  | 
|  德语  |  de-DE  |  德国料理  | 
|  意大利料理  |  it-IT  |  意大利料理  | 
|  日式料理  |  ja-JP  |  英语音频  | 
|  巴西葡萄牙语  |  pt-BR  |  巴西葡萄牙语  | 
|  西班牙料理  |  es-ES  |  西班牙料理  | 
|  土耳其料理  |  tr-TR  |  土耳其料理  | 

# 验证码拼图示例
<a name="waf-captcha-puzzle-examples"></a>

典型的可视验证码拼图需要交互来表明用户可以理解一张或多张图像并与之交互。

以下屏幕截图显示了图片网格拼图的示例。该拼图需要您在网格中选择包含特定类型物体的所有图片。

![\[屏幕中包含“确认您是人类”标题和“选择所有椅子”文本。文字下方是一个 3x3 的网格图，其中一些图含有椅子，而其他图则含有非椅子物体，例如床和窗户。屏幕底部有加载其他拼图、切换信息框进入和关闭视野、切换到音频拼图以及更改语言的选项。底部还有“确认”按钮。\]](http://docs.aws.amazon.com/zh_cn/waf/latest/developerguide/images/CAPTCHAPuzzleGrid.png)


音频拼图提供背景噪音，上面有关于用户应在文本框中键入的文本的口语说明。

以下屏幕截图显示音频拼图选项的显示。

![\[屏幕包含标题“完成拼图”和“点击播放听取说明”文本。文字下方是一张显示播放按钮的图片。图片下方是“音频切换键：Alt + 空格”文本。下面是标题“输入您的答案”，下方有一个文本输入框。打开的信息框中写着“听取录音并在文本框中输入您的答案即可解答问题”。屏幕底部有加载其他拼图、切换信息框和切换到视觉拼图的选项。底部还有提交按钮。\]](http://docs.aws.amazon.com/zh_cn/waf/latest/developerguide/images/CAPTCHAPuzzleAudio.png)




# CAPTCHA AWS WAF 和 Challenge 规则操作的工作原理
<a name="waf-captcha-and-challenge-how-it-works"></a>

本节介绍了 CAPTCHA 和 Challenge 的工作方式。

AWS WAF CAPTCHA并且Challenge是标准规则操作，因此它们相对容易实现。要使用其中任何一个，您需要为规则创建检查条件，以确定要检查的请求，然后指定两个规则操作之一。有关规则操作选项的一般信息，请参阅 [在中使用规则操作 AWS WAF](waf-rule-action.md)。

除了从服务器端实现静默挑战和验证码谜题外，你还可以在你的 JavaScript iOS 和 Android 客户端应用程序中集成静默挑战，也可以在客户端中渲染验证码拼图。 JavaScript 这些集成使您能够为最终用户提供更好的性能和验证码拼图体验，还可以降低与使用规则操作和智能威胁缓解规则组相关的成本。有关这些选项的详细信息，请参阅[中的客户端应用程序集成 AWS WAF](waf-application-integration.md)。有关定价信息，请参阅 [AWS WAF 定价](https://aws.amazon.com/waf/pricing/)。

**Topics**
+ [CAPTCHA 和 Challenge 操作行为](waf-captcha-and-challenge-actions.md)
+ [CAPTCHA 和 Challenge 日志和指标中的操作](waf-captcha-and-challenge-logs-metrics.md)

# CAPTCHA 和 Challenge 操作行为
<a name="waf-captcha-and-challenge-actions"></a>

本节介绍了 CAPTCHA 和 Challenge 操作的作用。

当 Web 请求与规则的检查标准相匹配CAPTCHA或Challenge操作时，将根据其令牌状态和免疫时间配置来 AWS WAF 确定如何处理请求。 AWS WAF 还会考虑请求是否可以处理验证码拼图或挑战脚本插页式广告。这些脚本被设计为作为 HTML 内容处理，只有期望 HTML 内容的客户端才能正确处理它们。

**注意**  
当您在其中一个规则中使用 CAPTCHA 或 Challenge 规则操作或在规则组中将其作为规则操作覆盖时，您需要支付额外费用。有关更多信息，请参阅[AWS WAF 定价](https://aws.amazon.com/waf/pricing/)。

**操作如何处理 web 请求**  
AWS WAF 按如下方式对 Web 请求应用CAPTCHA或Challenge操作：
+ **有效令牌** — AWS WAF 处理方式与Count操作类似。 AWS WAF 应用您为规则操作配置的所有标签和请求自定义，然后使用保护包 (Web ACL) 中的其余规则继续评估请求。
+ **令牌丢失、无效或已过期** — AWS WAF 停止对请求的保护包 (Web ACL) 评估并阻止其前往预期目的地。

  AWS WAF 根据规则操作类型生成一个响应，然后将其发送回客户端：
  + **Challenge**： AWS WAF 在响应字段中包含以下内容：
    + 值为 `challenge` 的标头 `x-amzn-waf-action`。
**注意**  
对于在客户端浏览器中运行的 Javascript 应用程序，此标头仅在应用程序的域中可用。标头不可用于跨域检索。有关详细信息，请参阅以下部分。
    + HTTP 状态代码 `202 Request Accepted`。
    + 如果请求包含值为的`Accept`标头`text/html`，则响应将包括带有质询脚本的JavaScript 页面插页式广告。
  + **CAPTCHA**— 在响应中 AWS WAF 包括以下内容：
    + 值为 `captcha` 的标头 `x-amzn-waf-action`。
**注意**  
对于在客户端浏览器中运行的 Javascript 应用程序，此标头仅在应用程序的域中可用。标头不可用于跨域检索。有关详细信息，请参阅以下部分。
    + HTTP 状态代码 `405 Method Not Allowed`。
    + 如果请求包含值为的`Accept`标头`text/html`，则响应将包含带有验证码脚本的JavaScript 页面插页式广告。

要在保护包（web ACL）或规则级别配置令牌到期时间，请参阅 [将时间戳到期时间和令牌免疫时间设置为 AWS WAF](waf-tokens-immunity-times.md)。

**在客户端浏览器中运行的 JavaScript 应用程序无法使用标头**  
当使用验证码或质询 AWS WAF 响应来响应客户端请求时，它不包括跨源资源共享 (CORS) 标头。CORS 标头是一组访问控制标头，它们告诉客户端 Web 浏览器 JavaScript应用程序可以使用哪些域、HTTP 方法和 HTTP 标头。如果没有 CORS 标头，在客户端浏览器中运行的 JavaScript 应用程序将无法访问 HTTP 标头，因此无法读取CAPTCHA和Challenge响应中提供的`x-amzn-waf-action`标头。

**质询和验证码插页式广告的用途**  
当质询插页式广告运行时，在客户端成功响应之后，如果它还没有令牌，则插页式广告会为其初始化一个令牌。然后，它会使用质询解题时间戳更新令牌。

当验证码插页式广告运行时，如果客户端还没有令牌，验证码插页式广告会首先调用质询脚本来质询浏览器并初始化令牌。然后，插页式广告运行了验证码拼图。当最终用户成功完成拼图后，插页式广告会使用验证码解算时间戳更新令牌。

无论哪种情况，在客户端成功响应并且脚本更新令牌后，脚本都会使用更新的令牌重新提交原始 web 请求。

您可以配置如何 AWS WAF 处理令牌。有关信息，请参阅[代币在 AWS WAF 智能威胁缓解中的使用](waf-tokens.md)。

# CAPTCHA 和 Challenge 日志和指标中的操作
<a name="waf-captcha-and-challenge-logs-metrics"></a>

本节介绍如何 AWS WAF 处理和Challenge操作的日志CAPTCHA和指标。

CAPTCHA 和 Challenge 操作可以是非终止的，如 Count，也可以是终止的，如 Block。结果取决于请求是否具有有效令牌以及该操作类型的未过期时间戳。
+ **有效令牌**-当操作找到有效令牌且未阻止请求时，会按以下方式 AWS WAF 捕获指标和日志：
  + 增加 `CaptchaRequests` 和 `RequestsWithValidCaptchaToken` 或 `ChallengeRequests` 和 `RequestsWithValidChallengeToken` 的指标。
  + 将匹配项记录为带有 CAPTCHA 或 Challenge 操作的 `nonTerminatingMatchingRules` 条目。以下列表显示了与 CAPTCHA 操作相关的此类匹配的日志部分。

    ```
        "nonTerminatingMatchingRules": [
        {
          "ruleId": "captcha-rule",
          "action": "CAPTCHA",
          "ruleMatchDetails": [],
          "captchaResponse": {
            "responseCode": 0,
            "solveTimestamp": 1632420429
          }
        }
      ]
    ```
+ 令牌@@ **丢失、无效或已过期-当操作因令牌**丢失或无效而阻止请求时，会按以下方式 AWS WAF 捕获指标和日志：
  + 增加 `CaptchaRequests` 或 `ChallengeRequests` 的指标。
  + 将匹配项记录为带有 HTTP `405` 状态码的 `CaptchaResponse` 条目或带有 HTTP `202` 状态码的 `ChallengeResponse` 条目。该日志会显示请求是缺少令牌还是时间戳已过期。该日志还会显示是 AWS WAF 向客户端发送了 CAPTCHA 插页式页面还是向客户端浏览器发送了静默质询。以下列表显示了与 CAPTCHA 操作相关的此类匹配的日志部分。

    ```
        "terminatingRuleId": "captcha-rule",
        "terminatingRuleType": "REGULAR",
        "action": "CAPTCHA",
        "terminatingRuleMatchDetails": [],
        ...
        "responseCodeSent": 405,
        ...
        "captchaResponse": {
          "responseCode": 405,
          "solveTimestamp": 0,
          "failureReason": "TOKEN_MISSING"
        }
    ```

有关 AWS WAF 日志的信息，请参阅[记录 AWS WAF 保护包 (Web ACL) 流量](logging.md)。

有关 AWS WAF 指标的信息，请参阅[AWS WAF 指标和维度](waf-metrics.md)。

有关规则操作选项的一般信息，请参阅 [在中使用规则操作 AWS WAF](waf-rule-action.md)。

**没有令牌的请求似乎会在日志和指标中出现了两次**  
根据 [CAPTCHA 和 Challenge 操作行为](waf-captcha-and-challenge-actions.md) 和本节所述的日志记录和指标，没有令牌的请求通常会在日志和指标中出现两次。这是因为一条预期请求实际上由客户端发送了两次。
+ 第一个不带令牌的请求接收上述对缺失、无效或过期令牌的日志和指标处理。CAPTCHA 或 Challenge 操作会终止第一个请求，然后用静默质询或验证码拼图响应客户端。
+ 客户端评估质询或拼图，如果客户端浏览器或最终用户成功响应，则使用新获得的令牌再次发送请求。第二个请求接收上述对带有有效令牌的请求的日志和指标处理。

# 使用 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)。