One request two responses

Question

I've encountered an interesting situation. While playing with Burp Suite, I noticed that if the Content-Length of a request does not match the size of its payload, this IIS Azure App Service will sometimes respond with a proper 200 response, but more often will respond with two responses concatenated together.

Here's the double response (occurs ~90% of the time): https://ibb.co/sHwZdv1

The single 200 occurs about ~10% of the time, and the server takes longer to respond (1-2 seconds) when it does: https://ibb.co/vJtbc79

While researching this, I've come across desync attacks which sound closest to what seems to be happening here. However, I'm not sure that's what this is because there's no Transfer-Encoding header. Also, why is the server's response to this request non-deterministic?

Answer 1

Let’s look at some attacks seen in the wild. We added a few rules to WAF to catch the HTTP anomalies.

The first HTTP anomaly we’ve seen being used is a request that consists of a Transfer-Encoding header with a value that isn’t specified in the RFC 7230, section 4: Transfer Codings specification. This is done in an attempt to hide the encoding of the payload from the WAF in the hope that the origin won’t be as strict on the exact header value and will therefore process the request.

Another HTTP anomaly we’ve seen is a Content-Length header with a Transfer-Encoding header with a value of chunked.

There are two possible scenarios here:

Content-Length value is smaller than the chunked payload size.The origin server will check the Content-Length header to determine the length of the request, but there will be some leftover payload that will be concatenated to the next incoming request.

Content-Length value is larger than the chunked payload size.The origin server reads the Content-Length header as in the previous case, but this time the connection won’t be closed after the current request as it will wait for more incoming bytes, resulting in a timeout on the next server in the chain waiting for the next request to arrive.

In both scenarios, an attacker might construct a two-step payload so that, by concatenating the second request to the first, a malicious payload will be received.

I found some articles about Desync Attacks and share them with you:

https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn https://www.imperva.com/blog/http-desync-attacks-and-defence-methods/