本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
使用 CAPTCHA 和Challenge 操作的最佳实践
按照本节中的指导来计划和实施 Amazon WAF CAPTCHA 或质疑。
规划您的验证码并质询实施
根据您的网站使用情况、要保护的数据的敏感度以及请求的类型,确定在哪里放置验证码拼图或静默质询。选择您要应用验证码的请求,这样您就可以根据需要展示拼图,但要避免在没有用处且可能降低用户体验的地方展示拼图。使用该Challenge操作来运行静默挑战,这些挑战对最终用户影响较小,但仍有助于验证请求是否来自 JavaScript 已启用的浏览器。
决定在哪里对您的客户进行验证码拼图和静默质询
确定您不希望受到验证码影响的请求,例如对 CSS 或图像的请求。仅在必要时使用验证码。例如,如果您计划在登录时进行验证码检查,并且用户总是直接从登录到另一个屏幕,则可能不需要在第二个屏幕上进行验证码检查,这可能会降低您的最终用户体验。
配置Challenge并CAPTCHA使用,以便 Amazon WAF 仅在响应请求时发送验证码谜题和静默挑战。GET
text/html
您不能运行拼图或质询来响应 POST
请求、跨源资源共享 (CORS) 预检 OPTIONS
请求或任何其他非 GET
请求类型。其他请求类型的浏览器行为可能有所不同,可能无法正确处理插页式广告。
客户可以接受 HTML,但仍然无法处理验证码或质询插页式广告。例如,带有小 iFrame 的网页上的控件可能接受 HTML,但无法显示或处理验证码。避免为这些类型的请求设置规则操作,就像对不接受 HTML 的请求一样。
使用 CAPTCHA 或 Challenge 验证之前的令牌获取
在合法用户应始终拥有有效令牌的地方,您只能使用规则操作来验证是否存在有效令牌。在这些情况下,请求能否处理插页式广告并不重要。
例如,如果您实现了 JavaScript 客户端应用程序 CAPTCHA API,并在向受保护的端点发送第一个请求之前立即在客户端上运行 CAPTCHA 拼图,则您的第一个请求应始终包含对质询和验证码均有效的令牌。有关 JavaScript 客户端应用程序集成的信息,请参见Amazon WAF JavaScript 集成。
对于这种情况,您可以在 Web ACL 中添加与第一个调用匹配的规则,并使用 Challenge 或 CAPTCHA 规则操作对其进行配置。当规则与合法的最终用户和浏览器匹配时,该操作将找到有效的令牌,因此不会阻止请求或发送质询或验证码拼图作为响应。有关规则操作的工作原理的更多信息,请参阅 CAPTCHA 和 Challenge 操作行为。
使用和保护带有 CAPTCHA 和 Challenge 的敏感非 HTML 数据
您可以通过以下方法对敏感的非 HTML 数据(例如 API)使用验证码和 Challenge 保护。
-
识别接受 HTML 响应且与敏感的非 HTML 数据的请求非常接近的请求。
-
编写与 HTML 请求相匹配且与敏感数据请求相匹配的 CAPTCHA 或 Challenge 规则。
-
调整您的 CAPTCHA 和 Challenge 免疫时间设置,以便在正常的用户交互中,客户端从 HTML 请求中获得的令牌在请求您的敏感数据时可用且未过期。有关调整信息,请参阅 时间戳过期:令牌免疫时间。
当对您的敏感数据的请求与 CAPTCHA 或 Challenge 规则匹配时,如果客户端仍有来自先前拼图或质询的有效令牌,则该请求不会被阻止。如果令牌不可用或时间戳已过期,则访问您的敏感数据的请求将失败。有关规则操作的工作原理的更多信息,请参阅 CAPTCHA 和 Challenge 操作行为。
使用验证码和 Challenge 以调整现有规则
查看您的现有规则,看看是否要修改或添加这些规则。以下是一些需要考虑的常见情况。
在部署之前先测试您的验证码和质疑实施方案
至于所有新功能,请按照 测试和调整您的 Amazon WAF 保护措施 中的指导进行操作。
在测试期间,请查看您的令牌时间戳到期要求,并设置您的 Web ACL 和规则级别免疫时间配置,以便在控制网站访问权限和为客户提供良好体验之间取得良好的平衡。有关信息,请参阅时间戳过期:令牌免疫时间。