The lab
here is how portswigger describes it
This lab's email change functionality is vulnerable to CSRF.
To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer's email address.
the last lab only checked the token on certain methods, and this one has an even simpler slip, it only checks the token when the token is actually there so we do not switch methods or forge anything clever we just leave the token out.
The idea#
this is one of the first things worth trying on any csrf token, because the flaw is so common a server is supposed to reject a request that has no valid token, but plenty of them are written as if a token is present then check it, and never stop to handle the case where there is no token at all. under that logic sending the token wrong gets you rejected, but sending no token slips straight through because there is nothing there to check. so the whole test is take the real request and delete the token entirely.
Step 1 - Log in and find the token#
logging in with the provided credentials and submitting an email change, the request carries a csrf token as expected

Step 2 - Remove the token and resend#
i sent that request to burp repeater deleted the csrf parameter completely, not just blanked it, and sent it again on the same post method


the email changes. so the server only validates the token when one is supplied and a request with no token is waved through which is exactly the broken pattern this lab is built around.
Step 3 - Build the poc and deliver it#
from here it is the same routine, wrap the request in an auto submitting page with no csrf field at all and host it on the exploit server
<html>
<body>
<form action="https://your-lab-id.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="[email protected]" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/')
document.forms[0].submit()
</script>
</body>
</html>

with this, the lab is solved!
