hackingpath
learn/phase-3/p3-w11/lesson 06
Milestone 11 · lesson 6

CSRF: Tricking a User Into Doing Something

Hands-on. Craft a request that executes in the victim's browser under their own credentials, without their knowledge.
Lab: Silent Admin Change

Craft a CSRF payload that tricks an admin into changing a setting without their knowledge.

What you'll learn

  • Understand why CSRF works: the browser automatically includes authentication cookies.
  • Recognise CSRF vulnerabilities (no CSRF tokens or weak validation).
  • Craft a malicious link or form that performs an action as the logged-in user.
  • Explain why GET requests for state-changing actions are dangerous.

CSRF: Tricking a User Into Doing Something

Cross-Site Request Forgery is an attack where an attacker tricks you into performing an action on a different website while you're logged in. Your browser automatically includes your authentication cookies, so the server thinks the request is legitimate.

The attack

You're logged into your bank with the tab open. You then visit a malicious site containing:

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

Your browser loads the image and automatically includes your bank's session cookie. The bank processes the transfer. The attacker stole money using your browser.

Why it works

The browser trusts the user's identity (the cookie), not the request source. It has no way to tell if the request came from the bank's own pages or a malicious site.

GET requests are especially dangerous

State-changing actions should NEVER be GET requests. An attacker can trigger them silently via images, links, or frames.

The fix: CSRF tokens

Include a random, unique token in forms. Validate it on submission. An attacker can't forge a request without knowing the token.

<form method="POST" action="/transfer">
  <input type="hidden" name="csrf_token" value="random123">
  <input name="amount" type="number">
</form>

Check your understanding

3 questions

Type an answer and press Check. Grading is keyword-based and forgiving, so short answers are fine.

  1. 1

    You're logged in to your bank, then you visit a malicious site. The malicious site makes your browser send GET /transfer?to=attacker&amount=1000 to your bank. Why does your bank process it?

  2. 2

    A blog's 'like' endpoint is GET /post/42/like. Why is GET dangerous for state changes?

  3. 3

    What is a CSRF token and how does it prevent the attack?

Previous
Next