本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
使用CAPTCHA和Challenge操作的最佳实践
按照本节中的指导来计划和实施 Amazon WAF CAPTCHA 或质疑。
规划您的验证码并质疑实施
根据您的网站使用情况、要保护的数据的敏感度以及请求的类型,确定在哪里放置验证码谜题或静默挑战。选择你要应用验证码的请求,这样你就可以根据需要展示谜题,但要避免在没有用处且可能降低用户体验的地方展示谜题。使用该Challenge操作来运行静默挑战,这些挑战对最终用户影响较小,但仍有助于验证请求是否来自 JavaScript 已启用的浏览器。
决定在哪里对你的客户进行验证码拼图和无声挑战
确定您不希望受到 CAPTCHA 影响的请求,例如对 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动作行为。
使用和保护敏感的非 HTML CAPTCHA 数据 Challenge
您可以通过以下方法对敏感的非 HTML 数据(例如 API)使用验证码和Challenge保护。
-
识别接受 HTML 响应且与敏感的非 HTML 数据的请求非常接近的请求。
-
编写CAPTCHA与 HTML 请求相匹配且与敏感数据请求相匹配的Challenge规则。
-
调整您的CAPTCHA和Challenge免疫时间设置,以便在正常的用户交互中,客户端从 HTML 请求中获得的令牌在请求您的敏感数据时可用且未过期。有关调整信息,请参见时间戳过期:代币免疫时间。
当对您的敏感数据的请求与CAPTCHA或Challenge规则匹配时,如果客户端仍有来自先前拼图或挑战的有效令牌,则该请求不会被阻止。如果令牌不可用或时间戳已过期,则访问您的敏感数据的请求将失败。有关规则操作工作原理的更多信息,请参阅CAPTCHA和Challenge动作行为。
使用验证码Challenge并调整现有规则
查看您的现有规则,看看是否要修改或添加这些规则。以下是一些需要考虑的常见场景。
在部署之前先测试你的验证码和质疑实现方案
至于所有新功能,请按照中的指导进行操作测试和调整您的Amazon WAF保护措施。
在测试期间,请查看您的令牌时间戳到期要求,并设置您的 Web ACL 和规则级别免疫时间配置,以便在控制网站访问权限和为客户提供良好体验之间取得良好的平衡。有关信息,请参阅 时间戳过期:代币免疫时间。