Research Academy Daily Swig
My account Customers Account and subscription management About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Login to post

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

thekalaiyom | Last updated: Mar 18, 2023 09:06AM UTC

i am on the lab trying to understand how this request happens to work and when i change anything from the payload it returns 'HTTP/1.1 400 Bad Request' even the length of the byte, from Content-length: 4 to Content-length: 5 and adding another e on the body its a bad request. i have changed settings for Content length update and still not getting it My second question is how does the smuggler extension add to this? i am doing everything by hand Any clarification would be appreciated. Thanks

Ben, PortSwigger Agent | Last updated: Mar 20, 2023 05:23PM UTC

Hi, Have you read the associated learning materials for the Request Smuggling topic (the 'TE.CL vulnerabilities' section here - https://portswigger.net/web-security/request-smuggling - explains this quite nicely)? To walk through this particular lab. The front-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 94 bytes long (the 5e value is 94 in hex), up to the start of the line following 'x=1'. It processes the second chunk, which is stated to be zero length (the 0), and so is treated as terminating the request. This request is forwarded on to the back-end server. The back-end server processes the Content-Length header and determines that the request body is 4 bytes long, up to the start of the line following '5e'. The following bytes, starting with POST, are left unprocessed, and the back-end server will treat these as being the start of the next request in the sequence.

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