14.7 Lab: 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 | Karthikeyan Nagaraj
Published in
2 min readJun 27, 2024
Description
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:petercarlos:montoya
Solution
- Open Burp’s browser and log in to your account. Submit the “Update email” form, and intercept the resulting request.
- Make a note of the value of the CSRF token, then drop the request.
- Open a private/incognito browser window, log in to your other account, and send the update email request into Burp Repeater.
- Observe that if you swap the CSRF token with the value from the other account, then the request is accepted.
- Create and host a proof of concept exploit as described in the solution to the CSRF vulnerability with no defenses lab. Note that the CSRF tokens are single-use, so you’ll need to include a fresh one.
- Change the email address in your exploit so that it doesn’t match your own.
- Store the exploit, then click “Deliver to victim” to solve the lab.
A YouTube Channel for Cybersecurity Lab’s Poc and Write-ups
Telegram Channel for Free Ethical Hacking Dumps
Thank you for Reading!
Happy Ethical Hacking ~
Author: Karthikeyan Nagaraj ~ Cyberw1ng
