Posted On: Aug 24, 2020
Application Load Balancer (ALB) and Classic Load Balancer (CLB) now support HTTP Desync Mitigation Mode, a new feature that protects your application from issues due to HTTP Desync. Modern day web applications are typically built with a chain of proxies that ensure fast and reliable communication between clients and servers. While these proxies follow a standard mechanism to parse RFC 7230 compliant HTTP/1.1 requests, they may have differences in interpretation while parsing non-compliant requests. These differences in interpretation can cause Desync where different proxies in the chain may disagree on request boundaries and therefore may not process the same request. This could leave behind arbitrary messages that may be prepended to the next request in the queue and smuggled to the backend. Ultimately, request smuggling can make applications vulnerable to request queue or cache poisoning, which could lead to credential hijacking or execution of unauthorized commands.
An option to mitigate Desync is to only allow requests that strictly conform to RFC. However, a large percentage of real world requests include characters that don't strictly conform to RFC. As a result, pursuing a strategy of only allowing requests that has strict conformance could pose an availability risk to some legitimate use-cases. With Desync Mitigation Mode, your ALB/CLB will provide durable security while maintaining the availability and performance of your application. To accomplish this, the load balancer will classify every request based on its threat level using an Amazon Web Services Open Source library called HTTP Desync Guardian. You can then configure your load balancer and choose the appropriate mitigation strategy based on the security needs of your application. With this feature, your ALB or CLB will mitigate threats to your application from HTTP vulnerabilities both in front of the load balancer and behind it.
With Desync Mitigation Mode, customers can choose among three modes - “Defensive”, “Strictest”, and “Monitor”. In the “Defensive” mode, the load balancer will perform three specific tasks. First, it will allow your application to receive known safe requests irrespective of their RFC 7230 compliance. Second, it will block requests that are not RFC compliant and are known security threats. Third, it will close both the client and upstream connections irrespective of HTTP keep-alive limits for ambiguous requests. Ambiguous requests are requests that are not RFC 7230 compliant, and can cause Desync because they are subject to varying interpretations by different proxies or web-servers. The “Defensive” mode is chosen as your default as it provides a durable hands-free mitigation against HTTP Desync, while maintaining the availability of your application. You can opt into the “Strictest” mode if you need to ensure that your application only sees requests that are RFC 7230 compliant. Finally, you also have the flexibility to configure “Monitor” mode, if you want your load balancer to forward all requests it receives, regardless of classification, to the application behind it.
All three modes offer CloudWatch metrics on both ALB and CLB to provide visibility on the aggregate threat level from your traffic to your application. ALB will also provide access logs that you can enable to perform detailed per request analysis to determine the threats posed by your clients to your application.