Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Lab: HTTP request smuggling, basic TE.CL vulnerability

Scott | Last updated: Sep 20, 2024 09:15AM UTC

I am running through the labs again in prep to take the test. I think this lab has stopped working. Regardless of what I do, it does not seem like the backend is honoring the Content-Length header. I've tried multiple solutions and I have failed to get any kind of desync response from the backend. It seems like the Content-Length header is just flat ignored across the board. For my payload, I am making sure the entire payload is constructed per TE: chunked spec. If it deviates, the frontend (assumed) lets me know by throwing an "invalid request". This includes all of the trailing \r\n chars. Inspector set to HTTP/1 for the Protocol Update Content-Length disabled Thanks!

Ben, PortSwigger Agent | Last updated: Sep 20, 2024 10:25AM UTC

Hi Scott, I have just run through this particular lab and been able to solve it using the solution provided so it does appear to be working as expected. Are you able to provide us with a screenshot of what your request looks like and what response(s) you are receiving? Are you using any extensions that might be impacting the requests that you are sending out (if you find the relevant Repeater requests in the Logger section of Burp - do the requests shown here match what you configured and sent in Repeater)? If it is easier to provide this information via email (you cannot directly add attachments to forum posts) then please feel free to email us at support@portswigger.net and we can take a look from there.

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