The lab

here is how portswigger describes it

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.

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 idea#

a csrf token only protects you if the server checks it on every request that can perform the action. a common mistake is to wire the check to the method the developer had in mind, usually post and forget that the same endpoint might quietly accept a get too. if it does then a get version of the request slips by without the token ever being looked at and our forgery is back on the table. so the plan is simple confirm the token is enforced on post, then see whether the endpoint answers a get without one.

Step 1 - Log in and inspect the request#

logging in with the provided credentials and submitting an email change i caught the request in burp.

this time there is a csrf token sitting in the post body alongside the email, so unlike the previous lab there is a real defence here to get around

Step 2 - Confirm the token is enforced on post#

first i wanted to know how serious that check is, so i kept the request as a post but stripped the csrf token out and sent it

the server rejects it with a missing parameter csrf error. so on post the token is genuinely required, and simply dropping it does not work

Step 3 - Try the same request as a get#

now the actual test. i changed the method to get and moved the email into the query string, and since a get has no body i left the token off entirely.

GET /my-account/change-email?email=admin%40logicbreaker.sh

it goes through, the email changes. that is the flaw ,the token check is tied to the post method and the get path was never given the same guard so as a get request the whole thing is unprotected exactly like the first lab.

Step 4 - Build the get based poc and deliver it#

now we just wrap that get request in an auto submitting page and host it on the exploit server, the same one from the previous lab. the trick in the html is that a form with no method attribute defaults to get so we simply leave the method off

<html>
  <body>
    <form action="https://your-lab-id.web-security-academy.net/my-account/change-email">
      <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>

because the form has no method set, the browser submits it as a get, putting the email in the query string and carrying no token, which is precisely the request the server forgot to protect. the <script> auto submits it the moment the victim loads the page, and their browser attaches their session cookie on its own, so the change is accepted as them.

with this, the lab is solved!