HTTP/2 Downgrading

---

HTTP/2 downgrading occurs when HTTP clients talk HTTP/2 to the reverse proxy but the reverse proxy and web server talk HTTP/1.1. In this scenario, the reverse proxy needs to rewrite all incoming HTTP/2 requests to HTTP/1.1. Additionally, all incoming HTTP/1.1 responses returned from the web server need to be rewritten to HTTP/2. This behavior leaves the door open for request smuggling vulnerabilities.

While it might seem unclear why such a setting would ever be used in a real-world deployment setting, there can be plenty of reasons for it. Maybe the web server does not support HTTP/2 yet. Maybe it's a misconfiguration by the system administrator. Maybe it's the default behavior of the reverse proxy that the system administrator is unaware of. Regardless of the reason, such deployments exist in the real-world and they can enable request smuggling attacks even though the supposedly secure HTTP/2 is used.

---

Downgrading leading to Request Smuggling

Foundation

Before jumping into an example, let's discuss how rewriting HTTP/2 requests to HTTP/1.1 can cause request smuggling vulnerabilities. As mentioned previously, HTTP/2 provides a built-in mechanism to determine the length of a request body, thus the CL header becomes obsolete. However, it says in the HTTP/2 RFC:

A request or response that includes a payload body can include a content-length header field. 
A request or response is also malformed if the value of a content-length header field 
does not equal the sum of the DATA frame payload lengths that form the body.

Thus, the CL header is explicitly allowed, provided it is correct. However, if the reverse proxy does not properly validate that the provided CL header is correct and instead rewrites the request to HTTP/1.1 using the faulty CL header, request smuggling vulnerabilities arise. This results in a so-called H2.CL vulnerability. Assuming an attacker sends the following HTTP/2 request (header names are red, header values are green, and the request body is yellow):

:method POST
:path /
:authority http2.htb
:scheme http
content-length 0
GET /smuggled HTTP/1.1
Host: http2.htb

The vulnerable reverse proxy trusts the provided CL header and thus uses it when rewriting the request to HTTP/1.1, resulting in the following TCP stream:

POST / HTTP/1.1
Host: http2.htb
Content-Length: 0


GET /smuggled HTTP/1.1
Host: http2.htb

After the HTTP/1.1 rewriting, the TCP stream contains two requests due to the manipulated CL header: a POST request to / and a GET request to /smuggled. However, the reverse proxy only ever sees a POST request to / with the other request being contained within that request's body. Since the web server receives the rewritten HTTP/1.1 TCP stream from the reverse proxy, it sees two requests, meaning we successfully smuggled the second request past the reverse proxy.

Similarly, we can create an H2.TE vulnerability with the TE header. The HTTP/2 RFC says:

The "chunked" transfer encoding defined in [Section 4.1 of [RFC7230]] MUST NOT be used in HTTP/2.

If a reverse proxy fails to reject HTTP/2 requests containing the TE header and uses it when rewriting the request to HTTP/1.1, we can achieve request smuggling with an HTTP/2 request similar to the following (header names are red, header values are green, and the request body is yellow):

:method POST
:path /
:authority http2.htb
:scheme http
transfer-encoding chunked
0

GET /smuggled HTTP/1.1
Host: http2.htb

A vulnerable reverse proxy creates the following TCP stream:

POST / HTTP/1.1
Host: http2.htb
Transfer-Encoding: chunked
Content-Length: 48

0

GET /smuggled HTTP/1.1
Host: http2.htb

The reverse proxy adds the CL header in the rewriting process to inform the web server about the request body's length. However, since the TE header has precedence over the CL header in HTTP/1.1, the web server treats the first request as having chunked encoding. The empty chunk terminates the first request, such that the smuggled data is treated as a separate request. Thus, from the web server's perspective, the TCP stream contains two separate requests while the reverse proxy only sees a single POST request, so we successfully smuggled the second request past the reverse proxy.

H2.CL Example

As a practical example, consider the following scenario. We have a simple website that sits behind a reverse proxy which also implements a WAF. We want to access the flag by revealing it:

The flag can be revealed by sending a request with the GET parameter reveal_flag=1. However, the WAF blocks all requests containing this GET parameter. To bypass the WAF, we can utilize an H2.CL vulnerability. By applying what we discussed above, we know that we need to smuggle the request that reveals the flag to hide it from the WAF but ensure that the web server still parses it correctly. For that, we can set the CL header to 0 just like in the example above and use a request like the following (make sure to uncheck the Update Content-Length option in Burp Repeater):

POST /index.php HTTP/2
Host: http2.htb
Content-Length: 0

POST /index.php?reveal_flag=1 HTTP/1.1
Host: http2.htb

Due to the behavior explained above, this will bypass the WAF and reveal the flag for us. When we need to obtain the response to our smuggled request, we can use tab groups in Burp and send multiple requests subsequently via the same TCP connection just like was demonstrated in previous sections. For instance, the first request which contains the smuggled request could look like this:

POST /index.php HTTP/2
Host: http2.htb
Content-Length: 0

POST /index.php?reveal_flag=1 HTTP/1.1
Foo: