发布于: Aug 17, 2020
Application Load Balancer (ALB) 和 Classic Load Balancer (CLB) 现在支持 HTTP 异步缓解模式，这是一项新功能，可避免您的应用程序因 HTTP 异步而产生问题。现代 Web 应用程序通常使用一系列代理来构建，以确保客户端与服务器之间能够快速可靠地通信。尽管这些代理按照标准机制来解析符合 RFC 7230 标准的 HTTP/1.1 请求，但它们在解析不符合标准的请求时，可能会产生不同的解释。这些解释上的差异会导致异步，通信链中的不同代理可能对请求边界有不同的看法，从而导致它们去处理不同的请求。这可能会留下任意消息，这些消息会先添加到队列中的下一个请求，然后再偷渡到后端。最终，请求偷渡会使应用程序容易受到请求队列或缓存投毒的影响，这可能导致凭证劫持或执行未经授权的命令。
该选项用于缓解异步，仅允许严格遵守 RFC 的请求。然而，现实世界的请求中有很大一部分包括未严格遵守 RFC 的字符。因此，如果采用的策略要求只允许严格符合标准的请求，则可能会导致某些合理的使用情况面临不可用的风险。在异步缓解模式下，ALB/CLB 将提供持久的安全性，同时保持应用程序的可用性和性能。为此，负载均衡器将使用名为 HTTP Desync Guardian 的 AWS 开源库，根据请求的威胁级别对每个请求进行分类。然后，您可以配置负载均衡器，并根据应用程序的安全需求选择适当的缓解策略。借助此功能，ALB 或 CLB 可缓解负载均衡器面前和背后的 HTTP 漏洞给应用程序带来的威胁。
异步缓解模式推出后，客户可在三种模式中进行选择，分别是：“防御”、“严格”和“监视”。在“防御”模式中，负载均衡器将执行三个特定任务。首先，它将允许应用程序接收已知安全的请求，无论该请求是否符合 RFC 7230 标准。第二，它将阻止不符合 RFC 标准的请求和已知具有安全威胁的请求。第三，对于模棱两可的请求，它将关闭客户端和上游连接，不考虑 HTTP 保持活跃限制。模棱两可的请求是指不符合 RFC 7230 标准的请求，这些请求可能由不同的代理服务器或 Web 服务器产生各种各样的解释，因此可能导致异步。默认情况下将选择“防御”模式，因为该模式可为 HTTP 异步提供持久的免人工干预缓解，同时保持应用程序的可用性。如果需要确保应用程序只看到符合 RFC 7230 标准的请求，您可以选择“严格”模式。最后，如果您希望负载均衡器不考虑请求的分类就直接将收到的所有请求转发给其背后的应用程序，则可以选择配置“监视”模式。
所有三种模式都同时在 ALB 和 CLB 上提供 CloudWatch 指标，以提供对从流量到应用程序的总体威胁级别的可见性。ALB 还将提供访问日志，您可以启用访问日志来按请求执行详细的分析，以确定客户端对应用程序造成的威胁。