TL;DR
Identify the update mail request, delete the csrf parameter and replay it. Notice the request is validated by the server when you send it as is. We can now use a form with a simple change mail request and solve the lab.
Learning Material
Some applications correctly validate the token when it is present but skip the validation if the token is omitted.
In this situation, the attacker can remove the entire parameter containing the token (not just its value) to bypass the validation and deliver a CSRF attack:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
email=pwned@evil-user.netLab
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.
You can log in to your own account using the following credentials: wiener:peter
Hint
You cannot register an email address that is already taken by another user. If you change your own email address while testing your exploit, make sure you use a different email address for the final exploit you deliver to the victim.
Write-up
As I tried in the csrf where token validation depends on request method, this time we can repeat the process by purely deleting the csrf token parameter and it will validate the request sent. Trying to use GET request returns a 405 Method Not Allowed response.
The redirection gives us a successful request and updated email value. We can repeat the same process by using the following payload to deliver to the target.
This solves the challenge and might be the most easy “bypass” possible, since it’s basically the same process ass csrf vulnerability with no defenses.