// THECYBERARYAN — VULNERABILITY SERIES

CSRF — CROSS-SITE REQUEST FORGERY

When websites trust your browser a little *too* much, and attackers take advantage of that.

🎯 TRICKING YOUR BROWSER INTO ATTACKING YOU

CSRF is the vulnerability where a website thinks:

“If this request comes from the user’s browser, it must be legit!”

Meanwhile an attacker is sitting behind the screen like:

“Perfect. Let's weaponize that trust.”

definition

Cross-Site Request Forgery (CSRF) forces a victim’s browser to send unwanted, authenticated requests to a website — without the victim realizing it.

Your browser automatically sends cookies. The website automatically trusts them. The attacker automatically smiles.

HOW CSRF WORKS (IN THE SIMPLEST POSSIBLE WAY)

Let’s say you’re logged into:

Your bank
Your social media
Your admin panel

You visit a malicious website while still logged in.

The attacker can make your browser auto-submit a hidden request:

<img src="https://bank.com/transfer?to=attacker&amount=5000">

The browser sends your cookies because… that’s what browsers do.

result

Congratulations, you just “donated” money without clicking anything.

REALISTIC EXAMPLE — PASSWORD CHANGE CSRF

Victim is logged in. Normal request:

POST /change-password
password=newpass123

Attacker hosts a page with this:

<form action="https://website.com/change-password" method="POST">
  <input type="hidden" name="password" value="hacked123">
</form>

<script>document.forms[0].submit();</script>

Victim opens attacker’s webpage → browser instantly submits the form.

impact

The victim’s password gets changed to the attacker’s chosen value without the victim doing anything.

WHERE CSRF OCCURS MOST OFTEN

Any action that changes something:

Change password
Update email
Send money / transfer funds
Delete account
Change user roles
Submit support tickets
Approve / reject actions in admin dashboards

hint

If an action is important and the app doesn’t ask for confirmation… assume CSRF is probably possible.

THE MOST POWERFUL CSRF TEST

Here’s your one-size-fits-all test:

<img src="https://target.com/sensitive-action?param=value">

Place it in a self-controlled website. If the request succeeds while the victim is logged in → **Vulnerable**.

CSRF WITH FORMS (THE CLASSIC)

<form action="https://target.com/update" method="POST">
  <input type="hidden" name="email" value="attacker@evil.com">
</form>

<script>document.forms[0].submit();</script>

pro tip

Add autoplaying JavaScript, hidden iframes, or clickjacking to make the attack even smoother.

HOW DEVELOPERS SHOULD FIX CSRF

Implement **CSRF tokens** on every state-changing action
Use **SameSite=Lax** or **SameSite=Strict** cookies
Use **POST** for sensitive actions
Re-authenticate critical operations (like password change)
Require CAPTCHA for dangerous actions

golden rule

If the browser is automatically trusted, an attacker can weaponize it.

FAST HACKER CHECKLIST

Check if the action uses GET (bad)
Check if the action works without a CSRF token
Check if CSRF token is missing or predictable
Test sensitive actions inside an `<img>` or `<form>`
Check for SameSite=None + Secure cookies

A single successful forged request = full CSRF.