Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

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. :)

picka | Last updated: Dec 02, 2020 04:50AM UTC

Wait a minute, why is it that sometimes the response is slow when you send a normal request, especially after the confirmation request has been sent

picka | Last updated: Dec 02, 2020 05:21AM UTC

CL.TE solution The confirmation packet That I'm using looks like this, Transfer-Encoding: chunked Content-Length: 28 0\r\n \r\n GET /index HTTP/1.1\r\n \r\n \r\n This works normally, but the solution provided request used X-ignore header. This should be a non-standard head, did the lab programme process it in the background? And after I tried many times, I found that after sending a confirmation request, I had to send a regular request several times to trigger a 404 response. And as the number of attempts increased, the number of requests I need to send has also increased. The logic behind this seemed a little weird.

kyrillos | Last updated: Mar 25, 2022 11:48AM UTC