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

Lab: HTTP request smuggling, basic TE.CL vulnerability

Sidharthan | Last updated: Oct 20, 2020 09:02AM UTC

The solution for the challenge provided is: POST / HTTP/1.1 Host: your-lab-id.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-length: 4 Transfer-Encoding: chunked 5c GPOST / HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length: 15 x=1 0 How was the value 5c calculated ? And how do i calculate when i am sending different content.

Ben, PortSwigger Agent | Last updated: Oct 22, 2020 07:38AM UTC

Hi, 5c is the size of the first chunk in bytes expressed as hexadecimal, this in binary is 92. The size of the following text is 92 bytes, (The > at the end represents the carriage return to finish the chunk at the start of the next line which contains 0, which is the size of the next chunk in bytes): 5c GPOST / HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length: 15 x=1 > This is why 5c is used here.

Sidharthan | Last updated: Oct 22, 2020 08:03AM UTC

Thanks Ben for the explanation it cleared my doubt. Does "encode as" "Hex" option available in Burp Decoder meant for this conversion? Also does hackvector extender support byte to hex conversion ?

Ben, PortSwigger Agent | Last updated: Oct 23, 2020 08:55AM UTC

Hi, Yes, you can use the Burp Decoder to perform various types of encoding and decoding.

LOKE, | Last updated: Jan 21, 2021 08:24AM UTC

Hi, would like to ask what is the reason for having "x=1" at the end of the body message?

Ben, PortSwigger Agent | Last updated: Jan 22, 2021 12:19PM UTC

Hi, This is just used as an example to illustrate the HTTP request smuggling process in the learning materials and labs.

Joshuwa | Last updated: Nov 07, 2022 12:17PM UTC

why using hex instead of bytes? and why using '>' instead of '0'?

Ben, PortSwigger Agent | Last updated: Nov 07, 2022 05:41PM UTC

Hi, The length of the current chunk is required to be expressed in hexadecimal format: https://en.wikipedia.org/wiki/Chunked_transfer_encoding We were using the '>' character in the example in this forum thread in order to demonstrate that all characters up to and including the '1' are included in the first chunk (this equates to 92 bytes or 5c in hex). You then have a newline (which we were representing with the '>') before then including the terminating zero sized chunk. Have you read the learning material for this topic, as below: https://portswigger.net/web-security/request-smuggling

Marco3008 | Last updated: Dec 03, 2022 02:26PM UTC

hey why the second content-lenght have to be minimum 11(in your example 15)... its 10 bytes big, so 10 should be enough, but it isnt working with 10. Can u explain, why it have to be 11, so one more byte as should be? Thanks in advance

Ben, PortSwigger Agent | Last updated: Dec 05, 2022 01:32PM UTC

Hi, Just to clarify, you are still referring to the example in the 'HTTP request smuggling, basic TE.CL vulnerability' lab solution or something else?

Marco3008 | Last updated: Dec 06, 2022 03:15PM UTC

Yes exactly, I am referring to the TE.CL vulnerability' lab solution. There, the "second" header works with Content-Length: 15. I have tried a few things and the solution works up to Content-Length: 11. With Content-Length:10, however, it no longer works, although the body underneath is actually only 10 bytes long and should therefore work. Is it perhaps because something from the next request still has to be processed for it to work?

Marco3008 | Last updated: Dec 06, 2022 03:16PM UTC

So my question in summary: Why does the content length of the "second" header have to be longer than the body itself?

Ben, PortSwigger Agent | Last updated: Dec 08, 2022 07:46AM UTC