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

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?

kairosdev | 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 :)

Luca | 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.

Luca | 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

Luca | 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.

jumptozero | Last updated: Jul 22, 2022 07:31AM UTC

``` POST / HTTP/2 Host: YOUR-LAB-ID.web-security-academy.net Content-Length: 0 GET /resources HTTP/1.1 Host: foo Content-Length: 5 x=1 ``` 6.Send the request a few times. Notice that smuggling this prefix past the front-end allows you to redirect the subsequent request on the connection to an arbitrary host ---------------- I solved it, when do Step 6 from 1 to 10 times then do step by step in the solution . I think qw should follow step by step of the solutions ! You'll get solved !

Carhackpils | Last updated: Sep 06, 2022 11:19AM UTC

I've been trying the given solution for 30 minutes (every 10 seconds). I can't solve it.

Ben, PortSwigger Agent | Last updated: Sep 06, 2022 05:22PM UTC

Hi, I have just run through this lab and been able to solve it using the solution provided so the lab does appear to be working as expected. If you want to send us an email and include a screenshot of the request that you are sending in Repeater and what you have configured in the exploit server then we can take a look at this for you. Please feel free to send the email to support@portswigger.net.

Michael | Last updated: Nov 25, 2022 11:56PM UTC

Hello, guys, I feel your pain, let me try to share what I've figured out: when you loaded the lab, this script (analyticsFetcher.js) will load "/resources/js/analytics.js" for you (for victim as well, actually). But only in 5 seconds after you loaded the page (and thus the script with timer): ... script.src = '/resources/js/analytics.js?uid=' + uid; }, 5000); I achieved some level of consistency by loading the main page, and immediately sending 4-5 "smuggling requests" (until I see "HTTP/2 200 OK", knowing the next request will have "smuggled" response), so by the moment the fetcher loads, the smuggling happened. So, you loaded the page, you have 5 seconds to make sure the server will smuggle response (at least to serve you). Something like that must be true for "emulated victim" as well. A moment before "victim" makes request, you must smuggle, so the current request for the victim will have the "smuggled" response. You'll see an "alert" If you see in History: Request> /resources/js/analytics.js Response> HTTP/1.1 302 Found Location: https://exploit-%your_server_here%.exploit-server.net/resources/ Connection: close Content-Length: 0 PS: If you ever played games like Sekiro, it is "Sekiro level timing".

Gurpartap | Last updated: Jun 11, 2023 04:36PM UTC

Try changing browser, I was having same issue in Firefox but burp's inbuilt browser worked fine.

Jan | Last updated: Aug 22, 2023 08:54AM UTC

I finally got the lab working after removing any line breaks after x=1 .

Joshua | Last updated: Sep 03, 2024 10:58PM UTC

Yeah this lab design with the timing is unnecessary. The check should just solve the lab after the victim IP does a GET on the /resources endpoint of the exploit server. I've waisted so much time on this lab, which does not benefit anyone really.

Joshua | Last updated: Sep 04, 2024 12:00AM UTC