Burp Suite User Forum

Login to post

HTTP request smuggling, confirming a TE.CL vulnerability via differential responses

picka | Last updated: Nov 21, 2020 06:05AM UTC

Hi I understood the principle of the lab and planned to test it. This lab environment should theoretically be TE.CL. First, I used this detection packet ...... Transfer-Encoding: chunked Content-Length: 4 1 Z Q It back "error":"Invalid request" And then I use this detection request ...... Transfer-Encoding: chunked Content-Length: 6 0 X But strangely, the response still return "error":"Invalid request". Then I try to use the request content in the solution, it back "error":"Read timeout after 10000ms" Not sure what I am missing, or is there a bug in the lab environment?

Ben, PortSwigger Agent | Last updated: Nov 23, 2020 10:05AM UTC

Hi, To confirm, are you switching off the Update Content-Length setting from under the Repeater menu within Burp? I have just attempted this lab and was able to solve it using the solution provided so the lab is functioning as expected.

picka | Last updated: Nov 26, 2020 01:54PM UTC

Thank you for your reply I tried again yesterday and made sure to turn off the content-Length setting, and using the solution provided, it works normally. However, when I used TE.CL detection request, there was still a problem. But today everything is working, so it's a bit strange :|

picka | Last updated: Nov 26, 2020 02:04PM UTC

Sorry, I missed something, now the TE.CL detection request works normally. But after that when I use the solution provided by lab, the server's response becomes Read timeout after 10000ms

Ben, PortSwigger Agent | Last updated: Nov 26, 2020 02:31PM UTC

Hi, Are you adding the trailing sequence \r\n\r\n following the final 0 (in essence hitting the Enter key twice to add two blank lines)?

picka | Last updated: Nov 27, 2020 06:50AM UTC

Oh! Thank you so much. It's my mistake, I forgot it. Now everything is right. :)

You need to Log in to post a reply. Or register here, for free.