CSRF where token validation depends on request method

Description

This lab’s email change functionality is vulnerable to CSRF. It attempts to block CSRF attacks, but only applies defenses to certain types of requests.

Reproduction and proof of concept

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

  2. Send the request to Burp Repeater and observe that if you change the value of the csrf parameter then the request is rejected.

  3. Use “Change request method” on the context menu to convert it into a GET request and observe that the CSRF token is no longer verified.

  4. If you’re 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”.

Alternatively, if you’re using Burp Suite Community Edition, use the following HTML template. You can get the request URL by right-clicking and selecting “Copy URL”.

<form action="https://YOUR-LAB-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>

  1. Go to the exploit server, paste your exploit HTML into the Body field, and click Store.

  2. To verify if the exploit will work, try it out by clicking View exploit and checking the resulting HTTP request and response.

  3. Click Deliver to victim.

Exploitability

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.