🕷️ Exploiting CSRF with No Defenses – PortSwigger Lab Walkthrough

❄️ Yeti’s back, sharpened claws ready, and today we’re hijacking trust itself — one forged request at a time.

We’re taking on a classic yet devastating vulnerability from the PortSwigger Web Security Academy:

🔥 Cross-Site Request Forgery (CSRF) — with zero defenses.

Let’s break the internet... respectfully. 🧊

What is CSRF?

Cross-Site Request Forgery (CSRF) is like social engineering for browsers.

You’re logged into your bank. Then, you visit a sketchy site filled with cat memes and crypto promises. BAM! That site silently fires off a POST request that transfers your funds — using your session cookie.

That’s CSRF: weaponizing a user's trust in a website by hijacking their authenticated session without them knowing.

Lab Objective

Our frosty mission:
Forge a CSRF attack that changes the victim’s email address — all without any clicks from them.

We’ll craft a sneaky form, auto-submit it, and host it on the Exploit Server to trigger the exploit

The CSRF Exploit – Step-by-Step

Log in with valid credentials

This lets us access the Change Email functionality. We need to mimic a legitimate request to fool the system.

Change your email manually

Trigger the POST request so we can catch it in BurpSuite. This is your blueprint

Intercept the request with Burp

• Turn on Proxy
• Change the email
• Send the captured POST to Repeater

Build your evil form

Time to forge a CSRF payload in raw HTML. It looks innocent, but beneath it lies betrayal:

📌 Replace the action URL and parameters with what you captured in Burp.

Store and trigger the payload

• Click “Go to Exploit Server”
• Paste your HTML

Hit Store, then View Exploit

Click Submit

Boom 💥 — once the victim (who’s still logged in) loads the page, their email is changed.

CVSS v3.1 Breakdown – Let’s Score the Ice

🔐 Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:H/A:N

Final Score: 8.2 — High

Why This is So Dangerous

The victim didn’t click anything.
They didn’t enter a password.
They didn’t even know they got hit.

The attack abused their session cookies, silently forging actions in their name.

In a real-world scenario, this could:

• Change the email to the attacker’s
• Trigger a password reset
• Let the attacker fully hijack the account

Why This Attack Still Matters (Even in 2025)

While modern frameworks try to defend against CSRF, plenty of apps:

• Misconfigure or omit CSRF tokens
• Use GET requests for state-changing actions (yikes)
• Fail to enforce SameSite cookies
• Don’t validate Origin or Referer headers

It’s 2025, but CSRF still shows up on bounty boards and pentests all the time.

Yeti’s Frozen Pro Tips

For Hackers:

• Look for CSRF-prone forms: profile changes, password resets, anything POST-based
• Use Burp’s “Generate CSRF PoC” feature to speed things up
• Always test against logged-in sessions to see effects

For Devs:

• Implement anti-CSRF tokens (per-form, per-session)
• Set cookies to SameSite=Strict (or Lax at minimum)
• Validate Origin headers for sensitive actions

For Users:

• Don’t stay logged into sensitive sites
• Be cautious of weird links or iframes
• Use browser extensions that isolate cookies (e.g., Firefox Containers)

Final Thoughts from the Iceberg

CSRF might not involve payloads with fire and explosions — but it's stealthy, reliable, and perfect for account manipulation and privilege escalation. ❄️💥

“When you don’t need a password to change an account — you’ve got a problem colder than the Arctic.”

Stay frosty, stay curious, and don’t forget: Yeti’s always watching... and fuzzing.
Until next time — Yeti out. 🐾