An HTTP desync attack uses a technique called Request Smuggling to amend requests of victims with a malicious payload. The NSX Advanced Load Balancer platform is used as a front end for web applications. This topic explains how the NSX Advanced Load Balancer is not vulnerable to the attack and how the attack pattern can be monitored using on-board solutions within the platform.

For more information on Request Smuggling, see HTTP request smuggling.

Vulnerability of NSX Advanced Load Balancer to HTTP Desync Attack

The default configuration thwarts the attack and does not allow this type of request smuggling through the NSX Advanced Load Balancer.

The NSX Advanced Load Balancer goes beyond the requirement of Hypertext Transfer Protocol – HTTP/1.1 which states, If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

If a request contains both the content-length header and a transfer-encoding header, the NSX Advanced Load Balancer will not only ignore the content-length header for its own processing of the request, but also remove one of the conflicting headers before sending the request. Depending on the configuration setting for whether buffering can used for the request body inspection or not, the NSX Advanced Load Balancer will either send a content-length header with the correct size after de-chunking the body, or a transfer-encoding header, to the upstream server, but not both.

Example of default behavior in streaming mode. Content-length header is removed



Example of default behavior in buffering mode. Transfer-encoding header is removed, full request buffered, and content-length is adjusted:



Logging

HTTP requests received with both Content-Length and Transfer-Encoding:Chunked headers, generates a significant application log with the message: Client sent a request with both chunked Transfer-Encoding and Content-Length headers.

Enabling Monitoring and Full Blocking of Requests

The following are two ways within NSX Advanced Load Balancer to monitor the attack:

  1. Through DataScripts:

    Adding this DataScript to a virtual service will log any request containing the attack and close the connection to the client.

    content_length = avi.http.get_header( 'Content-Length')
 
if content_length ~= nil then
  transfer_encoding = avi.http.get_header( 'Transfer-Encoding')
  if transfer_encoding ~= nil and string.match(transfer_encoding, "chunked") then
    avi.vs.log('HTTP desync attack detected. Have Content-Length: ' .. content_length .. ' and Transfer-Encoding: ' .. transfer_encoding)
    avi.http.close_conn()
  end
end

  2. Using the Latest CRS Version:

    Since CRS version CRS-2019-2, we have rule 4022010 in CRS which detects this attack. It is recommended to enable WAF with the current CRS version to avoid HTTP desync attack.

Blocking through HTTP Security policy

To block this kind of requests in the most effective way is to use a rule in an HTTP Security Policy with the action Close Connection as shown below.



This will result in the following log view. The important point as shown in the log is that NSX Advanced Load Balancer is closing the connection. The next request coming over the same TCP connection is dropped - which is often the desired and critical behavior.