DVWA XSS Cookie Theft Lab 2026 — Steal Session Cookies and Hijack Accounts | Hacking Lab 19

Labs 8, 9, and 10 established how XSS payloads inject and execute across reflected, stored, and DOM contexts. Lab 8’s reflected XSS showed that user input reaches the browser unescaped. Lab 9’s stored XSS showed that payloads persist and hit every visitor. Lab 19 completes the XSS attack chain by weaponising those injection points for the most impactful outcome: stealing the authenticated session of anyone who loads the vulnerable page. Once you complete this lab, the DVWA Lab Series moves to Lab 20’s CSRF Advanced — where XSS and CSRF chain together for an even more powerful combined attack.

Why Session Cookies Are the Target — Account Takeover Without a Password

Web applications maintain authentication state through session cookies. When you log in, the server creates a unique session identifier — typically stored in a cookie named PHPSESSID, JSESSIONID, session_id, or similar — and sends it to your browser. Every subsequent request your browser makes to the server includes this cookie in the header. The server checks the cookie against its session store and knows who you are. The session cookie is your authentication credential for the duration of the session.

This architecture has a critical implication for XSS: if an attacker can execute JavaScript in your browser’s context on the target application’s domain, they can read your session cookie using document.cookie and send it to any server they control. The attacker then injects that cookie value into their own browser and — from the server’s perspective — they are now you. No password required. No MFA bypass required. No account recovery needed. They have your session token, and that token grants full access to your account for as long as the session remains valid.

This is precisely why XSS vulnerabilities on authenticated pages are rated Critical in most vulnerability assessment frameworks. The theoretical “attacker could execute arbitrary JavaScript” becomes concrete the moment you demonstrate session cookie theft and account takeover. In bug bounty programmes, an XSS finding with a working cookie theft PoC earns dramatically higher payouts than an XSS finding with only an alert box demonstration — because the impact chain is undeniable.

Setting Up the Cookie Listener on Kali

Before injecting any payload, you need a server running on your Kali machine that can receive the stolen cookie. When the XSS payload fires in the victim’s browser, it makes an HTTP request to your listener with the cookie value as a URL parameter. Your listener logs that request, you extract the cookie value, and you replay it. The listener is the simplest component of the attack — a single Python or Netcat command — but it must be running before you inject, because the payload fires the moment the victim loads the page.

Two options work well for this lab: Python’s built-in HTTP server and Netcat. The Python server provides cleaner output and automatically URL-decodes the request parameters, making the cookie value immediately readable. Netcat gives you raw request data and is more representative of how you’d receive exfiltrated data in a real scenario where the victim’s browser might send more complex cookie strings. For DVWA’s simple PHPSESSID, both work equally well.

Low Security — Cookie Exfiltration Payload

At DVWA Low security, there is no filtering of any kind on the name parameter. Any JavaScript you inject executes directly. The cookie exfiltration payload redirects the victim’s browser to your listener with the cookie value as a URL parameter. When the browser follows the redirect, your listener receives an HTTP GET request containing the full cookie string as part of the URL. The payload uses document.location for the redirect — this is equivalent to navigating the browser programmatically and triggers the GET request automatically without any alert box or visible indicator to the victim.

The anatomy of the payload is worth understanding in detail. document.location sets the browser’s current URL to whatever value you assign. By setting it to your listener’s URL with document.cookie appended as a query parameter, the browser makes a GET request to your server that includes the full cookie string. The + operator concatenates the base URL with the cookie value. The result is a clean, reliable exfiltration that works across all modern browsers and does not produce any visible effect in the page — the victim’s view flickers briefly as the page redirects, but from a social engineering perspective, that page can be designed to redirect back to a convincing landing page immediately after the theft completes.

Session Replay — Logging In as the Victim

You have the PHPSESSID. Now you need to inject it into your browser so the server treats your requests as coming from the victim’s authenticated session. The browser sends cookies automatically based on the values stored in its cookie store for a given domain. If you replace your own PHPSESSID with the stolen one, the next request you make to DVWA will include the victim’s session token — and the server will grant you the victim’s access level.

The most reliable method for cookie injection in a testing environment is browser developer tools. Every modern browser provides a cookies panel in the Application or Storage inspector where you can directly edit cookie values without needing any extensions. For more advanced scenarios — automated session replay, integration with Burp Suite, or scripted account takeover demonstrations — you can set cookies programmatically via JavaScript in the console or use Burp’s cookie jar management.

Medium Security — Bypassing Script Tag Filters

DVWA Medium security applies basic input filtering that strips or encodes <script> tags. The filter checks for the literal string “<script” and removes it from input. This approach is fundamentally flawed because JavaScript can execute through many HTML elements beyond script tags. Event handlers — the JavaScript attributes attached to HTML elements — execute code when triggered by user or browser events, with no script tag required.

The most reliable event handlers for XSS injection bypass are: onerror on an image element with an invalid src (the error fires immediately without any user interaction), onload on an img, body, or svg element, and onfocus with autofocus attribute. The onerror handler is particularly effective because it fires automatically when the browser tries to load an image and fails — making it a zero-interaction payload that fires the moment the page loads, exactly like a script tag would.

High Security — Advanced Bypass Techniques

DVWA High security applies stricter input filtering, typically using a combination of htmlspecialchars() and more aggressive pattern matching that blocks common event handler attributes. The reflected XSS page at High security in DVWA is significantly harder to bypass than Medium — in many DVWA versions, the reflected XSS is effectively patched at High, and the lesson shifts to understanding why the stored XSS page may still be vulnerable even when reflected is secured. This is a realistic model of real applications, which often patch specific injection points without a consistent application-wide security model.

At High security, if input filtering is applied properly, your approach shifts to DOM-based XSS sources and sinks, or to exploiting any stored input paths that may use different sanitisation logic. The DVWA High security XSS Stored page is often still vulnerable to payloads that bypass the character limit by editing the HTML directly in DevTools — changing the maxlength attribute of the input field to allow longer payloads, then injecting an SVG onload or a carefully crafted DOM manipulation payload.

Stored XSS Cookie Theft — Zero Interaction Required

The most impactful variant of XSS cookie theft combines the exfiltration payload with a stored XSS injection point. When a cookie theft payload is injected into a persistent storage location — a guestbook, a message board, a user profile field, a product review — every user who loads the page containing that payload automatically fires the theft without any additional interaction beyond loading the page. No phishing link. No social engineering. Just a stored payload that silently exfiltrates every visitor’s session token to your listener.

In DVWA’s XSS Stored lab (Lab 9), you injected persistent payloads into the guestbook’s message field. The same guestbook is accessible here. By injecting a cookie theft payload into the message field — with the maxlength restriction bypassed via DevTools — you create a persistent trap that fires for every subsequent visitor who loads the guestbook page. In a real application, this is the difference between finding a bug and demonstrating a mass account takeover scenario that affects every user simultaneously.