The lab

here is how portswigger describes it

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

To solve the lab, craft some HTML that uses a CSRF attack to change the viewer's email address and upload it to your exploit server.

You can log in to your own account using the following credentials: wiener:peter

What CSRF actually is#

csrf, cross site request forgery is an attack that makes a victim's own browser send a request to a site they are logged into, carrying out an action they never meant to. the reason it works comes down to one browser habit whenever your browser sends a request to a site it automatically attaches that site's cookies, your session cookie included, even when the request was set off by a completely different website. so if you are logged into your bank in one tab and you open a malicious page in another, that page can quietly make your browser fire a request at the bank and the bank sees your session cookie riding along and treats the request as genuinely you.

for csrf to be possible three things usually have to line up. there needs to be an action worth forging, like changing an email or a password. the site has to track the session with cookies alone so that the browser attaching them automatically is enough to authenticate the request. and there must be no unpredictable value in the request that an attacker cannot guess, no csrf token. this lab is the textbook case with all three present, and the "no defenses" in the title means there is not even a token in the way

Step 1 - Log in and find the action#

i logged in with wiener:peter and landed on the account page where there is a change email feature

changing an email is a perfect csrf target because if we can force it as the victim, we can point their account at an address we control and go on to reset their password from there.

Step 2 - Intercept the request and check for defenses#

i submitted a change and caught the request in burp to see how it is built

the request is a post to /my-account/change-email with a single email parameter in the body and that is all. there is no csrf token no custom header, nothing unpredictable that we would have to reproduce. it is authenticated purely by the session cookie, which the browser sends on its own, so this request is completely forgeable.

Step 3 - Craft the auto submitting html and deliver it#

one thing to cover once for this whole csrf series, the exploit server. every csrf lab gives you one an attacker controlled server at its own address with a body field where you paste an html page, a store button to save it a view exploit button to preview it, and a deliver exploit to victim button that makes the simulated victim's browser open your page. it is how we get our forged request in front of a logged in victim and since it is the same tool every time, i will explain it here and just reach for it in the labs that follow.

for the payload itself if you have burp professional it can write it for you, right click the request and choose engagement tools then generate csrf poc, tick the option to include an auto submit script, and regenerate. on community edition you write the same html by hand. either way it comes out like this

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

reading it through. the <form> recreates the exact change email request, a post to the endpoint with the email field set to the address we want, [email protected]. the little <script> at the bottom submits that form the instant the page loads with document.forms[0].submit(), so the victim never has to touch anything, and history.pushState just rewrites the address bar to / to keep things looking innocent. when the victim opens this page, their browser posts the form to the target and automatically attaches their session cookie, so the site accepts it as a real request from them and changes their email.

paste it into the exploit server's body field store it, and deliver it to the victim.

with this, the lab is solved!