Research Academy Daily Swig
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Login to post

Help with H2.CL request smuggling lab

Jonathan | Last updated: Mar 22, 2022 10:24PM UTC

I am attempting to solve the "H2.CL request smuggling" lab. I verified that I can trigger the JavaScript alert when I simulate a victim user myself (e.g. I visit the home page in a separate session, then send the malicious request in the Repeater and observe the alert fire in the victim browser session). However I haven't triggered the "Lab solved" after sending the malicious request over 30 times (with at least 10 seconds between requests). I compared my solution with the published solution and I don't see anything missing. I'd appreciate any help identifying what I might be missing or why the "Lab solved" isn't triggering. Thanks!

Michelle, PortSwigger Agent | Last updated: Mar 23, 2022 10:08AM UTC

Thanks for getting in touch. We've just checked through this lab and were able to solve it following the solution. If you work through the lab again are you still seeing the same problems?

Cesar | Last updated: Mar 23, 2022 07:32PM UTC

Hi, I worked on this lab earlier in the month and today as well and can confirm that I have the same problem. Following the solution, it does not trigger or run the payload in javascript, it shows a page with the text "alert(document.cookie)", but it can run javascript if I adjust the head and body to: Head HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Body <script>alert(document.cookie)</script> But with either solutions, it does not mark the lab as completed/solved for me as well. thanks

Cesar | Last updated: Mar 23, 2022 08:59PM UTC

It does trigger the javascript if I add ";" at the end of alert(document.cookie) following the solution but does not trigger the solved.

Michelle, PortSwigger Agent | Last updated: Mar 24, 2022 10:21AM UTC

Thanks for your message. Can you send a screen-recording of the steps you're taking to support@portswigger.net so we can take a closer look, please?

Jonathan | Last updated: Mar 24, 2022 11:46PM UTC

I tried again today and am still having the same issue. I just sent a screen-recording showing the steps I'm taking. Thanks for the help!

Michelle, PortSwigger Agent | Last updated: Mar 25, 2022 08:25AM UTC

Thanks we'll take a look through and be in touch

Axel | Last updated: Mar 27, 2022 12:17PM UTC

Also failing to solve this lab. Tried the supplied solution and also experimented with a text/html response. Lab definitely seems broken.

Michelle, PortSwigger Agent | Last updated: Mar 28, 2022 09:33AM UTC

Thanks for getting in touch. I've run through the lab solution this morning and was able to solve it using the steps given in the solution. If you're still having issues can you send a screen recording to support@portswigger.net of you following the steps in the solution so we can compare the steps you're taking with the steps I've taken this morning, please?

Cesar | Last updated: Mar 28, 2022 11:13PM UTC

Hi, I just tried again today, it worked. Thanks

Axel | Last updated: Mar 30, 2022 08:46AM UTC

I've also successfully tried again. This time it worked but the lab is quite undeterministic. Had to resend quite a few times before solving.

AllMight | Last updated: May 03, 2022 05:09AM UTC

Hello, I was just wondering if the lab is potentially busted again. I cannot seem to get it to work despite following the intended solution and with the information provided in this thread. Are you able to provide any guidance on this?

Michelle, PortSwigger Agent | Last updated: May 04, 2022 01:54PM UTC

The timing for sending the requests so the victim is affected can be tricky and require some patience. Are you still having issues?

Kairos | Last updated: Jun 09, 2022 04:38PM UTC

Hi, I'm having the same problem that those people talked about earlier. No way of having the lab solved.

Michelle, PortSwigger Agent | Last updated: Jun 10, 2022 08:20AM UTC

Thanks for your message. It is possible to solve this lab but it can require some patience to time the requests so that they are successfully smuggled. Keep trying, I'm sure you'll get there :)

halfluke | Last updated: Jun 19, 2022 10:21PM UTC

I was able to solve it once after trying for an hour, and I was NOT able to solve it a second time after trying for more than an hour. Something is not ok with this lab, it can't be only a matter of timing. Especially as the access log shows that the victim successfully accesses the /resources endpoint.

Liam, PortSwigger Agent | Last updated: Jun 20, 2022 05:22AM UTC

Thanks for letting us know, halfluke.

halfluke | Last updated: Jun 21, 2022 09:32PM UTC

Would you be able to check why it is not marked as solved 99% of the time, even if the Access Log of the exploit server is full of 200 OK access to /resources from the IP of the victim?

Liam, PortSwigger Agent | Last updated: Jun 22, 2022 09:49AM UTC

The lab is passing our testing. It can require some patience to time the requests so that they are successfully smuggled

halfluke | Last updated: Jun 22, 2022 11:54AM UTC

Well, it doesn't make much sense to me, because the exploit server access log shows that the requests ARE smuggled, but the lab is still not marked as solved 99% of the time. When I see a call from the victim to /resources in the access log, with a 200 OK, I expect to see the lab solved, instead I can have hundreds of calls from the victim and the lab still Not Solved. Then maybe if you are lucky once in a while it gets solved. Of course I am not sure how "Solved" is triggered, but it doesn't seem to correspond to the victim accessing alert(document.cookie) on our exploit server.

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