CSRF in DVWA (for learning/demo)

CSRF: An attack where a logged-in user is tricked into sending unwanted requests to a web application, causing actions to be performed without their consent.

DVWA (Damn Vulnerable Web Application) is meant for cybersecurity training.
So demonstrating CSRF there is safe and expected in a lab.

Only perform this inside DVWA or your own lab.

Objective in DVWA CSRF lab

You will try to change a user’s password without them clicking the form, using a forged request.

Step-by-step (safe lab demo)

1. Open DVWA

DVWA Security → Low

Go to:

DVWA → CSRF

You will see a password change form.

2. Observe the request

Fill password fields and click change once.

Now check the URL:

http://localhost/dvwa/vulnerabilities/csrf/?password_new=123&password_conf=123&Change=Change

Notice:

Password change happens via GET request
No token validation
No CSRF protection

This is vulnerable.

3. Create a CSRF attack page (attacker page)

Create a simple HTML file:

<html>
<body>
<h3>Loading...</h3>

<img src="http://localhost/dvwa/vulnerabilities/csrf/?password_new=hacked123&password_conf=hacked123&Change=Change" />

</body>
</html>

Save as:

attack.html

4. Perform the attack

Stay logged in to DVWA
Open attack.html in browser
The image request automatically loads
Password gets changed without clicking anything

That is CSRF.

Why it worked?

Because DVWA (low security):

Did not verify request origin
No CSRF token
Trusted session cookie
Used GET request

So browser sent authenticated request automatically.

DVWA Medium/High levels

If you increase DVWA security:

Security → Medium / High\

You will see:

CSRF tokens added
Requests rejected without token
Attack fails

This demonstrates protection.

Real-world prevention methods

1. CSRF Token (most important)

Each form must include random token:

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

Server validates it.

2. Use POST instead of GET

Sensitive actions should never use GET.

3. SameSite cookies

Set-Cookie: session=abc; SameSite=Strict

Prevents cross-site requests.

4. Re-authentication

Ask password again before sensitive action.

5. Origin/Referer checking

Server checks request source domain.

Real cybercrime example (India context)

Attackers send phishing links like:

“Click to view exam result”

If user is logged into university portal and clicks malicious page →
Request changes email/password silently.

This is how CSRF is used in real incidents.

CSRF in DVWA (for learning/demo)