Cross-Site Request Forgery (CSRF)
CSRF attacks trick authenticated users into unknowingly submitting malicious requests to web applications they are logged into. You will learn how CSRF exploits the browser's automatic cookie-sending behavior and how to craft CSRF proof-of-concept exploits. Understanding CSRF is important for testing authentication flows and state-changing operations in web applications.
Learning Objectives — Deep Dive
Each objective below is broken down into plain English so you know exactly what you are learning, why it matters, and what you will be able to do when you are done. Mark each one complete as you work through the lesson.
Identify CSRF-vulnerable endpoints
Log into DVWA and navigate to the CSRF module. Inspect the 'Change Password' form using your browser's developer tools — look at the form action URL, the HTTP method (GET or POST), and whether any anti-CSRF token is present in the form fields or request headers. A form that changes state (password, email, settings) using GET is especially vulnerable because GET requests can be triggered by a simple image tag. The absence of a CSRF token means the server cannot distinguish a legitimate user action from a forged cross-site request.
Create the CSRF PoC page
Create an HTML file on your Kali machine that automatically submits a forged request to the DVWA change-password endpoint. For a GET-based form, a simple <img src='http://target/dvwa/vulnerabilities/csrf/?password_new=hacked&password_conf=hacked&Change=Change'> tag is sufficient — the browser will make the request when loading the image. For a POST-based form, use a hidden auto-submitting form with JavaScript. Save the file as csrf-poc.html and serve it with 'python3 -m http.server 9090' so you can access it from the victim's browser.
Test the PoC
While logged into DVWA as the victim in one browser tab, open a new tab and navigate to your CSRF PoC page at http://<kali-ip>:9090/csrf-poc.html. The PoC page will automatically trigger the forged request to DVWA using the victim's active session cookie. Return to the DVWA tab and attempt to log in with the original password — if the login fails, the password was successfully changed by the CSRF attack. The victim had no indication that anything happened while viewing your PoC page, which is what makes CSRF attacks so effective.
Verify the impact
Confirm the attack succeeded by logging into DVWA with the new password you set in the CSRF payload. Check the DVWA database or user profile to verify the password change was recorded. In a real application, this attack could change a victim's email address (enabling account takeover), transfer funds, delete data, or perform any other action the victim is authorized to do. The impact of CSRF is directly proportional to the privileges of the targeted user — a CSRF attack against an admin account is far more damaging than one against a regular user.
Document the finding
Write up the CSRF finding with the following components: vulnerability name (Cross-Site Request Forgery), affected endpoint (the change-password URL), HTTP method, evidence (screenshot of the PoC page and the successful password change), CVSS score (typically Medium to High depending on the action), and remediation. The standard remediation for CSRF is to implement synchronizer tokens — a unique, unpredictable value embedded in every state-changing form that the server validates on submission. Also recommend setting the SameSite=Strict or SameSite=Lax attribute on session cookies, which prevents them from being sent with cross-site requests in modern browsers.