Solving Portswigger Academy: CSRF where token is not tied to user session
This lab’s email change functionality is vulnerable to CSRF. It uses tokens to try to prevent CSRF attacks, but they aren’t integrated into the site’s session handling system.
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.
You have two accounts on the application that you can use to help design your attack. The credentials are as follows:
wiener:peter
carlos:montoya
In this lab we can use the CSRF token of another user as the session token and CSRF token are not tied to each other. That means attacker can use his token and perform CSRF attack.
Access the lab and login with provided username and password. Make sure here you will need to use incognito mode of a browser to login with second user.
In normal browser I logged in as user wiener and in incognito mode logged in as carlos.
Let’s capture the request to update the email address of the wiener yser first and test it with
1. Without CSRF token
2. Tampered CSRF token
3. Changing the request method from POST to GET.
As you can see we are not allowed to update email when we tried to by-pass CSRF protection. Now let’s use CSRF token from wiener to update email of carlos. So capture the request in burp
Now replace the CSRF token in above request with that of wiener.
Now we need to create a PoC and use that. Remember to include the valid CSRF token.
As soon as you store the exploit on exploit server and deliver it to victim, the lab get solved.
