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

CSRF labs exploit server delivery doesn't work

Teodor | Last updated: Apr 15, 2023 08:10PM UTC

Hello, In the past i solved these labs without any issue. Now i can't even "Solve" the easiest one, CSRF vulnerability with no defenses. If i view the exploit the mail updates. Delivering the exploit doesn't work, does the simulated user changed in some way? Tried every lab and this issue applies. I double checked every input. Thanks, T

Ben, PortSwigger Agent | Last updated: Apr 17, 2023 09:21AM UTC

Hi Teodor, To confirm, is your payload using the same email address when you both view the exploit (which works for you) and then attempt to deliver it to the victim user (which does not work for you)? If so, we recently altered the way that the Web Academy environment works - two users cannot now have the same email address in a single lab instance. When you perform the 'view exploit' functionality on your user, you are changing the email address associated with the 'wiener' user. When you then come to try and deliver the exploit to the victim user you are then attempting to assign the same email address to the 'carlos' user, which will now no longer work due to the aforementioned change. You would need to alter the email address before you use the 'deliver exploit' functionality so that a unique email is being used. We have added some text within a 'Hint' box on each of the labs affected by this change to explain this to the user.

Teodor | Last updated: Apr 17, 2023 08:10PM UTC

Hi Ben, The payload is not using the same email address. I checked again, there must be something with the Exploit server. Your email is: test@test.com Payload: (i also used burp pro poc generator in other tests) <form method="POST" action="https://ID.web-security-academy.net/my-account/change-email"> <input type="hidden" name="email" value="anything%40web-security-academy.net"> </form> <script> document.forms[0].submit(); </script> I store the payload then deliver it to victim. As mentioned, i already completed the labs before, the issue is not only with this CSRF lab but with all of them, i choosed this one because it's easy to reproduce.

Ben, PortSwigger Agent | Last updated: Apr 18, 2023 04:29PM UTC

Hi Teodor, Actually, if you use anything@web-security-academy.net rather than anything%40web-security-academy.net in your payload (so remove the encoding for the @ character) - does this allow you to solve this particular lab?

Teodor | Last updated: Apr 18, 2023 06:19PM UTC

Hi Ben, Just tried without encoding. Still not getting the lab solved after delivery. T

Ben, PortSwigger Agent | Last updated: Apr 19, 2023 10:37AM UTC

Hi Teodor, Out of interest, what browser are you using to carry out this particular lab? I have just gone through this lab again, as of now, and simply delivering the following payload in the Exploit Server will solve the lab for me so I am somewhat perplexed as to why this does not work for you: <form method="POST" action="https://0a9500990464c01c80ee17aa0011004e.web-security-academy.net/my-account/change-email"> <input type="hidden" name="email" value="test@test.com"> </form> <script> document.forms[0].submit(); </script>

Bro | Last updated: Jul 27, 2023 01:07PM UTC

Hi Ben I had the same problem. What helped for me was to switch from Chrome to Firefox. Once I clicked Deliver to Victim using Firefox, then lab marked itself as solved.

Esa | Last updated: Jun 19, 2024 02:08PM UTC

Hi Ben I switched from Chrome to Firefox, but still not getting the lab solved after delivery. Please help

Ben, PortSwigger Agent | Last updated: Jun 20, 2024 06:59AM UTC

Hi Esa, Were you using a standard version of Chrome or the embedded browser when you attempted this lab? Are you also able to confirm what your exploit looks like?

ghostofthenorth | Last updated: Jun 24, 2024 10:52AM UTC

Hi i found a solution, that's first the email must be different for the view and exploit server and also, do each time store the payload, its will work. Have a nice day.

Carlos | Last updated: Jul 30, 2024 06:45PM UTC

Hi, Im using the embedded browser when I attempted the lab and I can confirm that is not working the CSRF POCs. My poc is working bc using the CSRF Poc utility on Burp Pro worked and also using the funcionality "view exploit" on the exploit server; but the problem arise when im trying to delivering to the victim that the lab is not properly finished. Im using on every attemp "free emails" so it cannot be a colision, im also using the last version of burp pro avalible v2024.5.5 and im on MacOS. I tried also on google chrome and firefox and im getting the same errors. Deliver to the victim funcionality is not working on the labs. Anithing I can help? This is one of my pocs: ``` <html> <!-- CSRF PoC - generated by Burp Suite Professional --> <body> <form action="https://0a2d0039045b08f489fe36f800e0002a.web-security-academy.net/my-account/change-email" method="POST"> <input type="hidden" name="email" value="exploit&#64;carlos&#46;com" /> <input type="hidden" name="csrf" value="NEbI0wBDRR6iCJGdTJ9SYotDKq8nJuxH" /> <input type="submit" value="Submit request" /> </form> <script> history.pushState('', '', '/'); document.forms[0].submit(); </script> </body> </html> ``` I also tested with the poc of the solution sections of the lab

Michelle, PortSwigger Agent | Last updated: Jul 31, 2024 01:45PM UTC

Hi Thanks for getting in touch. I just tried this lab using the slightly shorter HTML template listed in the solution and was able to solve the lab. If you try again now, are you still seeing the same issue?

Eiad | Last updated: Aug 01, 2024 08:58AM UTC

Hi, I had the same issue Deliver to the victim funcionality is not working on the labs. <style> iframe{ position:relative width:1000px; height:700px; opacity:0.2 x-index:2; } div{ position:absolute; left:125px; top:440px; x-index:1; } </style> <div>Click me</div> <iframe src="https://0a8f006a0456904480293fec003300b8.web-security-academy.net/my-account/?id=wiener&email=abbddd@gmail.com"></iframe> the victim is changing but it dosen't solves these labs: Lab: Basic clickjacking with CSRF token protection Lab: Clickjacking with form input data prefilled from a URL parameter pls help

Michelle, PortSwigger Agent | Last updated: Aug 01, 2024 02:17PM UTC

Hi As you're working on the Clickjacking labs are you using Burp's embedded browser or are you using normal Chrome?

Eiad | Last updated: Aug 01, 2024 03:00PM UTC

i'm using chrome

Michelle, PortSwigger Agent | Last updated: Aug 02, 2024 10:54AM UTC

Thanks for the update. Were the details you posted previously the ones you used on the exploit server for the 'Basic clickjacking with CSRF token protection' lab? If so, if you changes the iframe src to just be src="https://YOUR-LAB-ID.web-security-academy.net/my-account" does that help? Or were they the details you used on the other lab?

Ocx | Last updated: Sep 06, 2024 06:58AM UTC

I'm also facing the issue with csrf and oauth labs. Tried everything mentioned above on firefox.

Ben, PortSwigger Agent | Last updated: Sep 06, 2024 07:23AM UTC

Hi, Are you able to provide some detailed steps of how you are trying to solve one specific lab so that we can take a look at this for you?

Wong | Last updated: Sep 08, 2024 01:51PM UTC

It is not working for me either. I had completed this lab before few months ago and i attempted again. I have tried other CSRF labs and cant get it solved. Something is wrong with deliver to victim. when i try view exploit i can see that it brings me to a page with the button and later email was changed. I have tried using 1) Firefox 2) Chrome 3) burpsuite browser None of these work. This is my code (generate CSRF PoC): <html> <!-- CSRF PoC - generated by Burp Suite Professional --> <body> <form action="https://0ac300a00449230f81b27ac100ca001a.web-security-academy.net/my-account/change-email" method="POST"> <input type="hidden" name="email" value="hello@gmail.com" /> <input type="submit" value="Submit request" /> </form> <script> history.pushState('', '', '/'); document.forms[0].submit(); </script> </body> </html>

Ben, PortSwigger Agent | Last updated: Sep 09, 2024 08:56AM UTC

Hi, I have just run through this particular lab using Firefox and your solution worked first time for me - if you try this again are you still having issues as of right now?

Janox | Last updated: Sep 09, 2024 03:07PM UTC

Same issue with me, Tried Brave, Chrome, Firefox, Edge here is the code, I view exploit and it's working, I change the e-mail, store and deliver, but lab is not solved for some reason. Help. <html> <body> <form id="emailChangeForm" method="POST" action="https://0a3800b904b61339818b9349001e00b4.web-security-academy.net/my-account/change-email"> <input type="hidden" name="email" value="carlos2@test.com" /> </form> <script> window.addEventListener('load', function() { setTimeout(function() { document.getElementById('emailChangeForm').submit(); }, 1000); }); </script> </body> </html>

Ben, PortSwigger Agent | Last updated: Sep 10, 2024 07:11AM UTC

Hi Janox, Your exploit works for me first time using Firefox. We have experienced some performance issues with the Web Academy environment over the last week or so that might be impacting the reliability of the solving of the labs - if you attempt this multiple times in different lab instances does it always fail to solve?

Dusan | Last updated: Sep 12, 2024 03:18PM UTC

I'm also having issues with CSRF labs. I've tried several browsers and even copied the exact same payload from people who successfully solved some of the labs on YouTube, but I still can't solve the lab. The payload can change my email address, but when it comes to delivering it to the target (victim), it doesn't work. By the way, I used to solve these labs in the past.

Ben, PortSwigger Agent | Last updated: Sep 13, 2024 07:39AM UTC

Hi, Are you having this issue with all of those particular labs? Are you able to provide details from one specific lab so that we can take a look?

Matt | Last updated: Sep 13, 2024 06:42PM UTC

I am also hitting this issue. When I hit the "Deliver exploit to victim" I can tell in the logs that the victim's browser never hits the /exploit/ endpoint. Here are the logs 195.252.237.205 2024-09-13 18:29:49 +0000 "GET /deliver-to-victim HTTP/1.1" 302 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.6533.100 Safari/537.36" 195.252.237.205 2024-09-13 18:29:54 +0000 "GET / HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.6533.100 Safari/537.36" 195.252.237.205 2024-09-13 18:29:55 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.6533.100 Safari/537.36" 195.252.237.205 2024-09-13 18:29:55 +0000 "GET /resources/css/labsDark.css.map HTTP/1.1" 404 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.6533.100 Safari/537.36" 195.252.237.205 2024-09-13 18:30:00 +0000 "GET /log HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.6533.100 Safari/537.36" 195.252.237.205 2024-09-13 18:30:00 +0000 "GET /resources/css/labsDark.css HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.6533.100 Safari/537.36" There should be a GET /exploit/ from a the victim's 10.x IP but it's not happening. I am using the latest Burp Suite Pro version 2024.7.5 builtin Chrome browser.

Matt | Last updated: Sep 13, 2024 07:13PM UTC

Here's a screen capture for you Ben or whoever is debugging this, in case that helps. https://www.dropbox.com/scl/fi/9d1xcbvjzc3kgfyoq3n29/Screen-Recording-2024-09-13-at-2.06.50-PM.mov?rlkey=0hai57h4b0yqbtir7xl886wg7&dl=0

Matt | Last updated: Sep 13, 2024 07:16PM UTC

The behavior in the screen capture is slightly different from the behavior in the logs from my prior post, but both appear not be working as expected.

Ben, PortSwigger Agent | Last updated: Sep 18, 2024 07:13AM UTC

Hi Matt, I am actually seeing similar things to you when I attempt this lab - I need to carry out some further checks but it might be a lab that needs to be investigated by the team that handles the Web Academy.

Alex | Last updated: Sep 27, 2024 01:34PM UTC

Hi Ben, I also experienced similar problems with some of the labs (you can see that I solved all of them) including mystery labs (for example right now I attempted a CSRF where Referer validation depends on header being present and even though I had a right payload the lab wasn't marked as solved). I debugged these issues a bit and here is some info for you: * I assume a right payload for the issue and all exploitation steps are the ones needed * GET request to /deliver-to-victim is sent and acknowledged by a server * There are no internal IP addresses found in GET request to /log * I tried 3 different browsers (Firefox, Chrome, and built-in Burp Chromium). It didn't work for all of them * Such issues come up inconsistently (sometimes happens). * The only thing that helped me solve such issues is waiting for the lab to shutdown and restart a new instance I believe the problem is on your back-end where either the server doesn't send a job to a "victim" browser, or "victim" browser process is not being initialized properly, or there is another error that prevents the "victim" to visit an exploit server Hope you could solve the problem for others and I hope there won't be similar issues during an exam

Ben, PortSwigger Agent | Last updated: Sep 30, 2024 10:09AM UTC