CSRF vulnerability with no defenses – PortSwigger Write Up

In this post, we’re going to be solving the lab: “CSRF vulnerability with no defenses”.

CSRF vulnerability with no defenses lab start screen

In this case, the lab indicates that there’s a CSRF vulnerability in the email change functionality. To solve the lab, we must create an HTML page that exploits the CSRF to change the email of whoever visits our website. Finally, we’re provided with credentials to access an account.

Knowing all this, we start the lab and navigate to “My account” to log in:

My account button to access user panel

Once we’ve logged in, we’re redirected to our profile:

User profile panel with email update field

Here, as the statement mentioned, we find a functionality to change our account’s email, so we prepare Burp Suite to intercept the change request:

Proxy configuration in the browser

Burp Suite interceptor activated and waiting

With Burp Suite ready, we enter a random email and click on Update email:

Email change form with new value

As soon as we click, Burp Suite receives the request:

POST request intercepted in Burp Suite showing email parameter

And as we can observe, the only parameter sent in the request body is email. There’s no other parameter whose value is random and impossible to predict, making it possible to create a malicious template that generates a request like the one shown above, keeping in mind that a site’s cookies are included in any request the browser makes to that site.

If we let this request be sent, the email will change without issues:

Successful email update confirmation

We now know all the necessary information and everything works as expected, so we disable the proxy and navigate to the exploit server:

Button to access the exploit server

Exploit server interface in PortSwigger

Once inside, we have the following fields:

Exploit server fields to configure the attack

This is where we create the malicious HTML template that will generate the request we saw above when the victim visits the page:

CSRF exploit HTML code in the server

The HTML code is as follows:

<html>
    <body>
        <form action='<URL where the email change is made>' method='<HTTP METHOD>'>
            <input name="email" value="<new value, in this case the email>" type="hidden"/>  
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

If we click to view the exploit, we ourselves will visit the malicious page:

Exploit preview before sending it

Since we have the session saved in the browser with the cookies, when visiting it, the request is generated correctly and the email is changed, all from just visiting the malicious website:

Email automatically updated after visiting the exploit

So, what happened is:

The malicious website generates a specially crafted request when visited.
If the user is logged in to the vulnerable website (in this case), the browser will automatically include the session cookie in the request (assuming the SameSite attribute of the cookie is not enabled, which is not the case here)
The malicious website will process the request, since it’s impossible to differentiate whether it was made by the victim themselves or not, so it will process it without issues and the email address will be changed.

Since we’ve observed that the exploit works perfectly, we can simply send it to the victim:

Button to deliver the exploit to the victim

And this way, we solve the lab:

Lab solved successfully message

Final confirmation of lab success