Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Lab: HTTP request smuggling, basic CL.TE vulnerability

John | Last updated: Oct 10, 2021 09:35AM UTC

Hi everyone, I has followed the solution of this lab : "Using Burp Repeater, issue the following request twice". Why we must send the same request twice to solve lab ? What actually happened behind the scene ? Please help !

Ben, PortSwigger Agent | Last updated: Oct 11, 2021 11:42AM UTC

Hi John, As noted in the lab description, this lab involves a front-end and back-end server, and the front-end server does not support chunked encoding. The front-end server processes the Content-Length header and determines that the request body is 6 bytes long, up to the end of G. This request is forwarded on to the back-end server. The back-end server processes the Transfer-Encoding header, and so treats the message body as using chunked encoding. It processes the first chunk, which is stated to be zero length, and so is treated as terminating the request. The G is left unprocessed and the back-end server will treat this as being the start of the next request in the sequence. When you then send the second request this gets processed by the front-end server in the same way as before. However, the unprocessed byte from the first request (representing the character G) gets prefixed to the second request that is being forwarded to the back-end server. This results in the 'Unrecognized method GPOST' error that you should receive.

John | Last updated: Oct 12, 2021 12:46AM UTC

I am grateful to you for explaining very clearly. Thanks to it I can understand this lab completely. Thank you so much !!!

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.