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

Question regarding HTTP Request Smuggling

Lukas | Last updated: Jun 12, 2020 12:51PM UTC

Hello everyone! I have a question regarding the HTTP Request Smuggling blog post (and scan feature), as I had a weird occurance with a customer. They had a web application running on /XXX, and there was an internal user management application running on /YYY, which was blocked for external IPs. BurpSuite spotted a possible HTTP Request Smuggling vulnerability, and I managed to exploit it, accessing /YYY. However, none of the HTTP Request Smuggling scenarios mentioned in your blog post really fit this one. I thought it was a CL.TE vulnerability, but the Content-Length had to be set to the amount of characters until (and including) the 0 from the chunk lengths. The Transfer-Encoding header which had to be set was "Transfer-Encoding : chunked", so with a space between the name and the colon. Now for an internal write-up of how to exploit these in practice (as we haven't had a case where it was possible, or at least noone managed), I revisited your post, and realised that the content length for CL.TE would have to be the the amount of characters until the end of the smuggled request. In my scenario, this didn't work though. Any longer or shorter than what I had, and I got an error 405, or the second request was simply dropped. Leaving the TE header out completely would result in losing the second request for some reason (although it should technically then be splitted into two regular requests, considering that's an HTTP feature). Does anyone have any idea what kind of vulnerability this could be, or if it can even be considered HTTP Request Smuggling? Thanks in advance! Cheers, Lukas

Uthman, PortSwigger Agent | Last updated: Jun 15, 2020 10:03AM UTC