发布于: Aug 24, 2020
Application Load Balancer (ALB) 和 Classic Load Balancer (CLB) 现在支持 HTTP 请求不同步缓解模式，这项新功能可防止您的应用程序出现 HTTP 请求不同步引起的问题。现代 Web 应用程序通常使用一系列代理构建而成，以确保客户端和服务器之间进行快速可靠的通信。尽管这些代理遵循标准机制来解析符合 RFC 7230 的 HTTP/1.1 请求，但在解析不符合要求的请求时，它们的解释可能有所不同。这些解释上的差异会导致请求不同步问题，其中不同代理可能在请求边界上不一致，因此可能无法处理同一请求。这可能会留下任意消息，这些消息可能会被预先添加到队列中的下一个请求中，然后再夹带到后端。最终，请求夹带会使应用程序容易受到请求队列或缓存投毒的影响，这可能导致凭证被劫持或执行未经授权的命令。
缓解请求不同步问题的一种方法是仅允许完全符合 RFC 的请求。但是，很大一部分真实请求都包含不完全符合 RFC 的字符。因此，采用仅允许完全符合要求的请求的策略可能会对某些合法使用案例带来可用性风险。使用请求不同步缓解模式，您的 ALB/CLB 将提供持久的安全性，同时保持应用程序的可用性和性能。为此，负载均衡器将使用称为 HTTP Desync Guardian 的 亚马逊云科技开源库，根据威胁级别对每个请求进行分类。然后，您可以配置负载均衡器，并根据应用程序的安全需求选择适当的缓解策略。使用此功能，您的 ALB 或 CLB 将减轻负载均衡器前面和后面的 HTTP 漏洞对您的应用程序的威胁。
使用请求不同步缓解模式，客户可以在“防御”、“最严格”和“监控”这三种模式之间进行选择。在“防御”模式下，负载均衡器将执行三个特定任务。首先，它将允许您的应用程序接收已知的安全请求，而不管其是否符合 RFC 7230。其次，它将阻止不符合 RFC 和属于已知安全威胁的请求。第三，它将关闭客户端连接和上游连接，而不考虑对模棱两可的请求的 HTTP 持久连接限制。模棱两可的请求是不符合 RFC 7230 的请求，可能会导致不同步，因为不同的代理或 Web 服务器对这些请求的解释不同。您可以选择“防御”模式作为默认模式，因为它提供了针对 HTTP 请求不同步的持久自动缓解机制，同时保持了应用程序的可用性。如果您需要确保应用程序仅看到符合 RFC 7230 的请求，则可以选择“最严格”模式。最后，如果您希望负载均衡器将收到的所有请求（不论分类）都转发给后面的应用程序，还可以灵活地配置“监控”模式。
所有这三种模式都提供有关 ALB 和 CLB 的 CloudWatch 指标，以便您了解从您的流量到应用程序的总体威胁级别。ALB 还将提供访问日志，您可以启用访问日志来执行详细的按请求分析，以确定客户端对应用程序造成的威胁。