📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
🧪 DVWA LAB SERIES
FREE
Part of the DVWA Lab Series — 30 Labs
Lab 20 of 30 · 67% complete
⚠️ Authorised Lab Environment Only. All CSRF bypass and token extraction techniques in this lab must be practised exclusively on your own local DVWA installation or authorised platforms. Testing these techniques against production applications without explicit written permission violates computer misuse legislation. Every exercise in this lab targets http://localhost/dvwa/ only.
DVWA CSRF Advanced Lab for 2026 :— Developers add CSRF tokens and believe the problem is solved. It often isn’t. The token prevents a naïve forged form submission because the attacker doesn’t know the token value. But when the same application also has a stored XSS vulnerability — even on a completely unrelated page — that XSS can fetch the CSRF-protected page, read the token out of the HTML, and include it in the forged submission. The CSRF protection is cryptographically sound. The XSS is the bypass. This is why application security cannot be evaluated one vulnerability at a time. Individually, a medium-severity stored XSS and a high-severity CSRF are two separate findings. Chained together, they are a one-click account takeover that a skilled attacker will exploit before the security team’s next sprint review.
🎯 What You’ll Master in Lab 20
Understand how CSRF tokens work and precisely why XSS on the same domain defeats them
Build and deliver a working no-token CSRF attack at Low security
Extract a live CSRF token via XSS fetch and use it in a forged request at Medium security
Identify and exploit Referer header validation flaws at High security
Chain stored XSS with CSRF token bypass for a fully automated account takeover payload
Document the attack chain in a format suitable for a penetration test or bug bounty report
⏱️ 55 min lab · 3 terminal exercises · Localhost DVWA only #### 📋 Prerequisites — Complete Before Lab 20 - Lab 4: DVWA CSRF Basics — understand how a basic CSRF attack without any token protection works before attempting token bypass - Lab 8: DVWA XSS Reflected — the XSS execution context used for token extraction in this lab builds on Lab 8’s techniques - Lab 19: DVWA XSS Cookie Theft — same-domain XSS used to exfiltrate data; Lab 20 applies the same XSS execution to extract CSRF tokens instead of session cookies ### 📋 DVWA CSRF Advanced Lab 2026 — Table of Contents 1. Why CSRF Tokens Are Bypassed When Same-Domain XSS Exists 2. Low Security — Basic CSRF Without Token Protection 3. Understanding the DVWA Anti-CSRF Token 4. Medium Security — Token Extraction via XSS Fetch 5. High Security — Referer Header Validation and Its Bypass 6. Stored XSS + CSRF Chain — Automated Account Takeover 7. Reporting the XSS+CSRF Chain in a Bug Bounty or Pentest Report Lab 4 established basic CSRF where no token exists and a forged form submits freely. Lab 19 established XSS execution context on the same DVWA domain, showing how JavaScript running inside the victim’s browser can exfiltrate data. Lab 20 connects both: XSS provides the same-origin execution needed to read a CSRF token that cross-origin requests cannot access. Completing this lab completes the client-side attack chain. The DVWA Lab Series then moves to Lab 21’s SQL Injection High Security — a different attack class where security level escalation requires increasingly sophisticated query techniques.
Why CSRF Tokens Are Bypassed When Same-Domain XSS Exists
The CSRF token defence relies on one assumption: that an attacker’s page, loaded in the victim’s browser from a different origin, cannot read the content of the protected application’s pages. This is the Same-Origin Policy at work — cross-origin JavaScript cannot read the response body from a different domain. A forged form on attacker.com cannot fetch victim-app.com/change-password and read the CSRF token from the HTML response because the Same-Origin Policy blocks that cross-origin read.
XSS on the same domain destroys this assumption. When an attacker injects JavaScript into a page on victim-app.com itself — through any XSS vulnerability on any page of the application — that script runs in the victim-app.com origin. It is no longer cross-origin. It can freely make XMLHttpRequest or fetch calls to any other page on victim-app.com and read the full response body, including any CSRF token embedded in a hidden form field. The attacker’s injected script extracts the token, constructs the forged request including the token, and submits it — all within the same trusted origin. From the server’s perspective, the token is valid. The request appears legitimate. The CSRF protection is completely defeated.
This is the core insight of the XSS+CSRF chain: CSRF tokens protect against cross-origin forged requests. They do not protect against forged requests constructed within the same origin by injected JavaScript. If any XSS vulnerability exists anywhere on the application — even on a low-traffic, seemingly unimportant page — it can be weaponised to bypass CSRF protection on any other page of the same application.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)