CSRF where token validation depends on token being present


This lab’s email change functionality is vulnerable to CSRF.

Reproduction and proof of concept

  1. Open Burp’s browser and log in to the wiener account. Submit the “Update email” form, and find the resulting request in Proxy history.

  2. Send the request to Burp Repeater and check that when changing the value of the csrf parameter, the request is rejected.

  3. Delete the csrf parameter entirely to check that the request is now accepted.

  4. When using Burp Suite Professional, right-click on the request, and from the context menu select Engagement tools -> Generate CSRF PoC. Enable the option to include an auto-submit script and click Regenerate.

When using Burp Suite Community Edition, use the following HTML template, and get the request URL by right-clicking and selecting Copy URL.

<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
    <input type="hidden" name="$param1name" value="$param1value">
  1. Go to the exploit server, paste the exploit HTML into the Body field, and click Store.

  2. Try it out by clicking View exploit and check the resulting HTTP request and response.

  3. Click Deliver to victim.


An attacker needs to use the exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address. There is an accounts on the application that can be used to design the attack. The credentials arewiener:peter.