Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

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

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

the solution provided request used X-ignore header. why we use it !?

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