Lab: H2.CL request smuggling
After starting the exercise, the blog should look like the following illustration.
We now switch to Burp Suite and open Burp Proxy. In the HTTP history tab, we search for the first request to the application. In general, this should contain the following first line: GET / HTTP/1.1. Using the key combination CTRL + R, we send this request to Burp Repeater.
First, we change the protocol from HTTP/1.1 to HTTP/2. To do this, we use the Inspector in Burp Repeater. When we expand Requests attributes, we see the two protocols. Here, we now click on HTTP/2. Then we change the HTTP method from GET to POST.
We remove all headers from the request except for the Host header. Then we add the Content-Length and Content-Type headers and the word SMUGGLED at the end of the body. The request should now look like this:
Before sending this request, we must disable the Update Content-Length function in Burp Repeater. We can do this via the Burp menu. There, we select Repeater and then Update Content-Length.
Now we send the request twice to the application and see that when sending it the second time, an HTTP/2 404 Not Found response appears.
With the HTTP/2 404 Not Found in every second response, we have confirmation that we have caused the backend to append the subsequent request to the injected prefix.
We now return to Burp Proxy and send the same request as before to Burp Repeater using the key combination CTRL + R. In the first line of the request, we now insert the path /resources. The request should look like this:
When we send this request to the application, we receive an HTTP/2 302 Found response. In this response, we see that our request is redirected to the address https://0a0c00ab04cb5da3802d0378004900fd.web-security-academy.net/resources/.
We now combine the two requests and adjust the Host header in the second request. To do this, we enter the value foo. At the end of the second request, we enter x=1.
We now send this request several times. We see that by inserting this prefix at the front end, we can redirect the subsequent request on the connection to any host. The response can be seen in the following code snippet.
Now we open the exploit server by clicking on the Go to exploit server button on the blog's home page.
In the File field, we enter /resources and in the Body field, we enter alert(document.cookie). Then we click the Store button.
Now we need to make a change to our request in Burp Repeater. To do this, we enter the address of our exploit server in the Host header of our second request. The request should look like this.
We now send this request to the application a few times. As we can see, we receive an HTTP/2 302 Found response, which contains a redirection to the exploit server.
If we now send this request again and wait 10 seconds, the exercise will be successfully completed.
Video solution
Last updated