Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Lab: CSRF vulnerability with no defenses

Name | Last updated: Jul 15, 2020 06:59PM UTC

Hey all, I am working my way through your labs (which I must say are excellent) and am having trouble completing the CSRF with no defenses lab. In the exploit server, I am using the following code in the body (with "https://aca81f141fcc70dc80ee07aa0033004c.web-security-academy.net" being changed to match the host as needed): <form action="https://aca81f141fcc70dc80ee07aa0033004c.web-security-academy.net/email/change-email" method="POST"> <input type="hidden" name="email" value="valid@valid.com" /> <input type="submit" value="Submit" style="visibility:hidden" /> </form> <script> document.forms[0].submit(); </script> The head section remains unchanged. Using the proxy and comparer utilities, I validated that the POST request was successfully being issued by the exploit server when view exploit was used, and that the POST request being issued by the exploit server was identical to the POST request issued when attempting to change email using the change email function apart from the referrer field. I also tried formatting the form in different ways (eg removing the submit button); changing the JS used for event handling (eg assigning an id to the submit button and then using document.getElementById([id here]).click() ); and adding superfluous <html> and <body> tags in the body text input area following solution examples. None of these changes appeared to have an effect. Given that I am still a noob, I am sure I am making a stupid mistake here somewhere. Any help would be greatly appreciated.

Name | Last updated: Jul 15, 2020 08:27PM UTC

Edit: for clarity, I am storing all my payloads on the exploit server. I am not simply pressing view exploit.

Uthman, PortSwigger Agent | Last updated: Jul 16, 2020 09:18AM UTC

Hi, Glad you are enjoying the labs! Have you tried using the official solution? The below works for me: <form method="POST" action="https://<LAB-ID>.web-security-academy.net/email/change-email"> <input type="hidden" name="email" value="test&#64;test&#46;com"> </form> <script> document.forms[0].submit(); </script>

Name | Last updated: Jul 16, 2020 02:47PM UTC

I tried the official solution (sorry I should have mentioned that) and that also did not work. Please find the payload I used below. I have subbed in my lab ID (the URL from the vulnerable page, not the exploit server) as appropriate. <form method="POST" action="https://ac301f041ea3ca10808f02b4000c00a2.web-security-academy.net/email/change-email"> <input type="hidden" name="email" value="test&#64;test&#46;com"> </form> <script> document.forms[0].submit(); </script> I placed this payload into the body section on the exploit server page then pressed store. The lab did not complete. I also attempted to view exploit. Like the payload I created, the POST request generated by the form on the exploit server matched the POST request generated when attempting to change email using the change email function apart from the referrer field.

Uthman, PortSwigger Agent | Last updated: Jul 16, 2020 02:59PM UTC

Unfortunately, I still cannot replicate the issue and our tests are passing fine for the lab. It looks like you are already following the correct steps. Have you taken a look at any video solutions on YouTube?

nirmal | Last updated: May 23, 2021 03:23PM UTC

I have Same Issue

nirmal | Last updated: May 23, 2021 03:23PM UTC

I have Same Issue

Uthman, PortSwigger Agent | Last updated: May 24, 2021 10:51AM UTC

Hi Nirmal, I just used the payload in the solution and it works as intended. Can you please try again or send a screen recording of your attempt to support@portswigger.net?

xtherdtyx | Last updated: Jun 21, 2021 07:25AM UTC

I think you missed one thing, when performing the attack in the exploit server, you should be logged out because as a real attacker you would not be logged in the account. Once logged out, in the exploit server, change the email address and store.

adotvoid | Last updated: Jan 28, 2023 02:47PM UTC

I'm very new to this so really hope that I'm missing something obvious here. I'm having the same issues as the guys above on all of the CSRF labs and none of the exploit servers seem to be working.

Ben, PortSwigger Agent | Last updated: Jan 30, 2023 02:18PM UTC

Hi, I replied to the other forum post that you raised about the issues you were having with the CSRF labs - it might be worth sticking to a single post to communicate in so I will await your reply there.

Massimo | Last updated: Mar 09, 2023 06:11PM UTC

Hi, i have the same issue, i think. The exploit works fine, but the lab does not change its status to solved. It also happens with the other CSRF labs. If you want, i can make screen recording, but i dont know where to upload.

Massimo | Last updated: Mar 09, 2023 06:18PM UTC

ok, wtf :D I got it. -> The major problem was, that after i stored it in the server and viewed it, i did not logout. So i tried it with storing, than viewing the exploit and after that sending it to the victim, so the exploit also works properly but i needed to logout before sending it to the victim. It might be clever, if someone can report it (i would, but dont know where and how). I think it would make sense to add this fact, that you must be logged out before you can exploit it correctly, into the official solution and might be added as a quote into the youtube video solutions.

Ben, PortSwigger Agent | Last updated: Mar 10, 2023 09:55AM UTC

Hi Massimo, I have replied to your other forum posts about this situation but, for completeness, I will repeat what I said here. We made a recent change to the Web Academy environment that means that two users cannot have the same email address in the same lab instance. When you use the 'View the exploit' functionality you are changing the email address of your user (the 'wiener' user) to the value in your exploit. If you then 'Deliver exploit to victim' you will then be trying to get the 'victim' user to change their address to the same email address as your user now has, which is now no longer allowed. We have updated all of the labs that are affected by this change so that there is a hint box in the description to explain this - you would just need to adjust the email address that is being used in your exploit when you come to 'Deliver exploit to the victim'.

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