How to Exploit CSRF: Step-by-Step (DVWA Lab)

In one line

CSRF tricks your logged-in browser into secretly submitting a request you did not mean to send, because the site trusts your session cookie and does not check that you actually meant to do it.

What this is, for a beginner

Cross-site request forgery abuses the fact that browsers automatically attach your cookies to requests for a site, even when those requests are triggered from a different site. If an application performs a sensitive action based only on the presence of a valid session cookie, an attacker can craft a page that quietly submits that action, and the victim's browser sends it authenticated.

The classic target is a state-changing request with predictable parameters, such as changing a password or email. If there is no unpredictable anti-CSRF token tying the request to a real user interaction, the attacker just needs the victim to visit a malicious page while logged in, and the action executes as them.

The legal lab we use: DVWA

DVWA has a dedicated CSRF page (change password). Run it locally and host your attack page locally too, so nothing touches a system you do not own.

DVWA project page →

Full walkthrough: exploiting it step by step

Step 1 — Open the DVWA CSRF page on Low

Set DVWA Security to Low and open the CSRF page, which lets a logged-in user change their password with a simple GET request.

Expected result: A password-change form that submits the new password via the URL parameters.

Step 2 — Capture the legitimate request

Change the password normally and observe the request, either in the address bar or in Burp. Note that it is a simple GET with the new password in the query string and no unpredictable token.

legitimate request

GET /vulnerabilities/csrf/?password_new=abc123&password_conf=abc123&Change=Change

Expected result: The password changes using only the session cookie and predictable parameters, with no anti-CSRF token present.

Step 3 — Build the malicious page

Create a local HTML file that auto-submits the same request. Because the browser attaches the DVWA session cookie automatically, the request is authenticated as the victim.

attacker.html (served locally)

<html>
  <body onload="document.forms[0].submit()">
    <form action="http://localhost/vulnerabilities/csrf/" method="GET">
      <input type="hidden" name="password_new" value="hacked123">
      <input type="hidden" name="password_conf" value="hacked123">
      <input type="hidden" name="Change" value="Change">
    </form>
  </body>
</html>

Expected result: When opened in the same browser where DVWA is logged in, the form submits automatically.

Step 4 — Fire the attack

With DVWA logged in, open your local attacker.html in the same browser. The forged request executes and the password changes without the victim knowingly doing it.

Expected result: DVWA reports the password changed to the attacker-chosen value, proving the request was forged through the victim's session.

Step 5 — See the defence on higher levels

Set security to Medium and High. Higher levels add referer checks and an anti-CSRF token, so your static attack page stops working. This shows exactly what a correct defence looks like.

Expected result: The forged request is now rejected because it lacks the valid, unpredictable token tied to the user session.

Free resource

Get the free 35-week ethical hacking roadmap

The exact order I'd learn this in, every vulnerability and tool, week by week, with the labs to practise each one. Enter your email and I'll send it over, plus one practical lesson each week.

How to detect and fix this

How to detect it

For each state-changing action, check whether the request includes an unpredictable, per-session anti-CSRF token that the server validates; if it works without one, it is likely vulnerable.
Try replaying a sensitive request from a different origin or with the token removed; if it still succeeds, CSRF protection is missing or broken.
Note that requests relying only on cookies for authentication, with no token and no SameSite protection, are the prime candidates.

How to fix it

Use anti-CSRF tokens: a per-session, unpredictable token included in every state-changing request and validated server-side.
Set SameSite=Lax or Strict on session cookies so the browser does not attach them to cross-site requests, which blocks most CSRF by default.
Require re-authentication or a second factor for the most sensitive actions such as password or email changes.
Avoid performing state changes on GET requests, which are especially easy to forge.

Common beginner mistakes

Confusing CSRF with XSS; CSRF forges requests using the victim's session, while XSS runs script in their browser. They are different bugs with different fixes.
Testing on High first and concluding the app is safe, when Low demonstrates the concept clearly before defences are added.
Forgetting that the victim must be logged in for CSRF to work, then wondering why the attack does nothing.
Hosting the attack page somewhere public or aiming it at a site you do not own; keep everything local and authorized.

FAQ

What is the difference between CSRF and XSS?

CSRF tricks the victim's browser into sending a forged, authenticated request to a site, exploiting automatic cookie attachment. XSS runs attacker JavaScript in the victim's browser. CSRF does not require injecting script into the target; it only requires the victim to be logged in and to trigger the request.

Does SameSite cookie protection stop CSRF?

SameSite=Lax or Strict prevents the browser from sending session cookies on most cross-site requests, which blocks the common CSRF paths. It is a strong default, though anti-CSRF tokens remain the explicit, complete defence.

Why does CSRF only work when the victim is logged in?

Because the attack relies on the victim's existing authenticated session. The forged request carries the victim's cookies automatically, so without an active session there is nothing for the server to trust and the action fails.

Where to go from here

You just exploited one vulnerability in a lab. Here's the structured path.

Scattered tutorials teach you tricks; they don't make you a pentester. My mentorship is 35 weeks of exactly this, every vulnerability and tool in a deliberate order, on real labs, with one-on-one feedback on your work so your mistakes get caught early instead of becoming habits.

See the mentorship

Keep practising

How to Exploit XSS How to Exploit Broken Authentication How to Use Burp Suite