Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

HTTPRQ Lab - Exploiting HTTP request smuggling to deliver reflected XSS

Joshua | Last updated: Jan 27, 2021 06:14AM UTC

Hey guys, I hope you're all well today. This seems to be a pretty interesting bug! I have no idea what is going on, but while trying to solve this lab, something seems to have broken in the back-end, and now every time I load the web root, only an image is loaded. Interestingly, it's a DIFFERENT image every time, and the body of the request seems to be encoded for some strange reason. The beginning of the responses look like the following: HTTP/1.1 200 OK Content-Type: image/jpeg Cache-Control: public, max-age=3600 Content-Encoding: gzip Keep-Alive: timeout=0 X-XSS-Protection: 0 Connection: close Content-Length: 270485 ÿØÿáExif (The rest of the 270k response is all jumbled)

Joshua | Last updated: Jan 27, 2021 06:16AM UTC

Update: There is one thing in common with all the responses - they all seem to have something to do with Adobe (often including xmp:CreatorTool="Adobe Photoshop CC 2018" - but not always). But other than the start of the response body which includes this, it seems to still always be encoded in some way. Thanks :)

Uthman, PortSwigger Agent | Last updated: Jan 27, 2021 11:54AM UTC

Hi Joshua, Thanks for reporting this. I am having some issues replicating your issue. Does it occur on the homepage? Can you please provide some replication steps? If you have any extensions enabled, can you please disable these and try again? The lab should reset after ~15 minutes so please wait for this first. If the issue persists, please send a screen recording to support@portswigger.net

Joshua | Last updated: Jan 28, 2021 02:00AM UTC

Hey Uthman, It's no problem for me - I knew the lab would reset on its own after a while. I only really wanted to let you know in case it might have been something you would want to look into. But if not, then I guess we're done here :) Thanks again

Alec | Last updated: Sep 05, 2021 01:14AM UTC

I ran into this as well, spent some time messing with it. As far as I can tell: Reproduction: Tested w/ Lab: https://portswigger.net/web-security/request-smuggling/exploiting/lab-deliver-reflected-xss As far as I can tell, this occurs when Content-Length is not properly defined. Note here it is set to 93 instead of 91 (proper CL.TE length). Send this request to Intruder and send with null payloads. You may need to start/stop it a couple times, but you should be able to corrupt your instance of the lab such that refreshes of the home page result in a random page being displayed. Note that this Content-Length is similar to what would happen if you tried to send CL.TE requests in Repeater without disabling the "Update Content Length" setting, so it's reasonable this is a possible cause for a lot of people. ------- START REQUEST --------- POST / HTTP/1.1 Host: ac231f491feb99a4807c00a50038000f.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 95 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1§§ Host: ac8f1f7b1eaa69e780ec723a005d00e9.web-security-academy.net ------- END REQUEST --------- I also tested with fixing it. It seems sending this request can fix the issue. DO NOT LET BURP UPDATE THE "Content-Length" HEADER!!! Sending this a few times in Repeater should resolve the issue, sometimes I find sending it to Intruder and sending with null payloads helps, but overall sending manually seems more consistent. After sending this request a few times, the response should hand for a few seconds while I assume the back end is catching up in the processing of requests and resetting the state of requests to a proper baseline with respect to content-length/transfer-encoding headers. ------- START REQUEST --------- POST / HTTP/1.1 Host: ac231f491feb99a4807c00a50038000f.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 3 Transfer-Encoding: chunked 0 ------- END REQUEST --------- I'd be curious to hear if anyone else tests and confirms/rejects this solution. I've tested in two separate instances of the app and it seems consistent. It seems like the more bad requests that are sent, the harder it is to return to normal, but it should eventually get there.. I think?

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