Introduction to HTTP/2

HTTP/2 is the latest version of the HTTP standard that aims to reduce latency and improve the performance of HTTP traffic. Additionally, the new version also comes with better security, in particular regarding request smuggling. However, as we will see in this section, if HTTP/2 is used incorrectly in a deployment setting, request smuggling vulnerabilities can still arise.

What is HTTP/2?

HTTP/2 was introduced in 2015 and implements improvements to HTTP traffic while maintaining full backward compatibility. In particular, HTTP methods, HTTP headers, and HTTP query paths still exist but data is formatted differently in transit. Specifically, this means that there is no noticeable difference in a web proxy like Burp since HTTP/2 requests and responses are displayed the way we are used to from HTTP/1.1. However, data is formatted differently during actual transmission to allow for performance improvements. While HTTP/1.1 is a string-based protocol, meaning HTTP requests and responses are sent as strings just like we can see them in Burp, HTTP/2 is a binary protocol. Just like TCP, data is not sent in a string format but in a lower-level binary format that is not human-readable.

Additionally, HTTP/2 allows the server to push content to the client without a prior request. This is particularly helpful for static resources like stylesheets, script files, and images. The server knows that the client needs those files as soon as the client requests a web application's index. So, the server pushes these resources immediately instead of waiting for the client to parse the response and subsequently request each static resource separately as is the case in HTTP/1.1.

Let's have a look at example HTTP/1.1 and HTTP/2 requests. Consider the following HTTP/1.1 request:

GET /index.php HTTP/1.1
Host: http2.htb

In HTTP/2, the same request is represented using so-called pseudo-headers:

:method GET
:path /index.php
:authority http2.htb
:scheme http

The following pseudo-headers are defined in an HTTP/2 request. Have a look at section 8.3.1 of the RFC here for more details:

• :method: the HTTP method
• :scheme: the protocol scheme (typically http or https)
• :authority: similar to the HTTP Host header
• :path: the requested path including the query string

Burp displays requests in the HTTP/1.1 format. However, in Burp Repeater we can see the HTTP/2 pseudo-headers in the Burp Inspector:

Another change that is important regarding security, particularly regarding request smuggling, is that the chunked encoding is no longer supported in HTTP/2. Additionally, since HTTP/2 transmits the request body in a binary format consisting of data frames, there is no explicit length field required to determine the length of the request body. The data frames contain a built-in length field that any system can use to calculate the request body's length. Thus, request smuggling attacks are almost impossible if HTTP/2 is used correctly in a deployment setting.