# Learn Ethical Hacking (#15) - XSS Advanced - Bypassing Filters and CSP ![leh-banner.jpg](https://images.hive.blog/DQmc2LpoeHUPesc4Dy8haRKLJgfuDY6UBKdc3sED8Dz3JH9/leh-banner.jpg) ### What will I learn - **Filter bypass** techniques: encoding, tag alternatives, event handlers; - **CSP bypass**: dangling markup, script gadgets, JSONP endpoints; - **XSS polyglots**: single payloads that work in multiple injection contexts; - **Mutation XSS (mXSS)**: exploiting browser HTML parser differences; - Using **Burp Suite** and **XSS Hunter** for advanced XSS discovery; - Testing XSS on DVWA at Medium and High security levels. ### Requirements - A working modern computer running macOS, Windows or Ubuntu; - Your hacking lab from Episode 2 (Kali + DVWA); - Burp Suite Community Edition; - Knowledge from Episode 14 (XSS fundamentals); - The ambition to learn ethical hacking and security research. ### Difficulty - Intermediate ### 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) - [Learn Ethical Hacking (#15) - XSS Advanced - Bypassing Filters and CSP](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-15-xss-advanced-bypassing-filters-and-csp) (this post) ### Solutions to Episode 14 Exercises **Exercise 1 -- Full XSS session hijacking chain:** ``` 1. Reflected XSS on DVWA: injected in the name parameter -- alert showed PHPSESSID and security level. 2. Stored XSS in guestbook: injected cookie-stealing Image() payload. Every visitor to the guestbook page triggers the cookie exfiltration. 3. Session hijacking: captured victim's PHPSESSID from cookie catcher, then used curl with that cookie to access DVWA: curl -b "PHPSESSID=stolen_value; security=low" http://target/dvwa/ -> Logged in as victim. Full account access without credentials. The complete chain: XSS -> cookie theft -> session hijacking takes under 60 seconds from injection to account takeover. ``` The key insight: XSS is not just "popup alerts" -- it's a direct path to account takeover. The cookie IS the identity. Steal the cookie, become the user. **Exercise 2 -- XSS scanner:** ```python import requests, sys from urllib.parse import urlparse, parse_qs, urlencode PAYLOADS = [ '', '">

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

``` Try `

` on DVWA Medium. It works. The filter catches ` alert(1) %253Cscript%253Ealert(1)%253C/script%253E

``` The HTML entity bypass (`alert`) is particularly effective. The server-side filter sees `ale...` -- which doesn't match the string `alert`. But when the browser parses the HTML, it decodes the entities to `alert` and executes it. The filter checked the wire format; the browser interprets the decoded format. Two different parsers, two diferent views of the same data -- and that gap is exploitable. Double encoding works when an application URL-decodes the input, then passes it through a filter, then URL-decodes it _again_ (or passes it to another layer that decodes). `%253C` decodes to `%3C` in the first pass (still looks harmless), then `%3C` decodes to `<` in the second pass. If the filter runs between the two decode steps, it never sees the `<` character. This is why defense-in-depth matters: decode once, validate once, encode at output. Anything more complex creates opportunities for parser differential attacks. ### XSS in Different Injection Contexts The bypass technique depends entirely on WHERE your input lands in the HTML. This is the context problem we introduced in episode 14 -- now we go deeper: **Inside an HTML tag attribute:** ```html " onmouseover="alert(1)" x=" ``` **Inside a JavaScript string:** ```html "; alert(1); var x=" ``` That second one -- closing the `` tag -- is worth dwelling on. The HTML parser operates at a HIGHER priority than the JavaScript parser. When the HTML parser sees ``, it closes the script block regardless of what the JavaScript parser thinks is happening. You could be inside a JavaScript string, a comment, a template literal -- doesn't matter. The HTML parser wins. This is a fundamental parser hierarchy issue that trips up even experienced developers who think "but the input is inside a JavaScript string, so HTML tags shouldn't matter." They do. The HTML parser sees `` first and ends the script block, then the next ` ``` Understanding injection context is the single most important skill for advanced XSS. A payload that works in one context is dead text in another. This is also why automated scanners test dozens of payloads per parameter -- they're covering multiple possible contexts because they can't always determine context from the outside. ### Content Security Policy Bypass CSP is the strongest browser-side defense against XSS. When properly deployed, it blocks inline scripts, inline event handlers, `javascript:` URLs, and `eval()`. A perfect CSP makes XSS exploitation extremely difficult even when the vulnerability exists. But CSP is rarely deployed perfectly. Here's what goes wrong: **CSP with 'unsafe-inline':** ``` Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' ``` The `unsafe-inline` keyword defeats the entire purpose of CSP for XSS prevention. Inline scripts execute. Inline event handlers fire. Many applications add this because their own code uses inline scripts scattered throughout the HTML, and refactoring all of those to external `.js` files feels like too much work. So they deploy CSP with the one keyword that makes it useless against XSS. _Schitterend._ **CSP with JSONP endpoints:** If `script-src` includes a domain that has JSONP endpoints, you can use those endpoints to execute arbitrary code from an "allowed" origin: ```html ``` The JSONP endpoint returns `alert(1)//({...})` -- your code, from an allowed domain. The `//` comments out the rest so it doesn't cause a syntax error. CSP sees a script loaded from a whitelisted domain and allows it. Google's CSP Evaluator tool (csp-evaluator.withgoogle.com) specifically checks for known JSONP endpoints on whitelisted domains -- it's that common a bypass. **CSP with 'unsafe-eval':** ``` Content-Security-Policy: script-src 'self' 'unsafe-eval' ``` `unsafe-eval` allows `eval()`, `setTimeout('code')`, `new Function('code')`, and similar dynamic code execution. If you can inject a string that reaches any of these functions, you bypass CSP entirely. Some frameworks (particularly older Angular.js versions) require `unsafe-eval` to function, which means any application using those frameworks with CSP has this hole. **Dangling markup injection:** When you can inject HTML but CSP blocks all script execution, you can still exfiltrate data using **dangling markup**: ```html

Amaiya Jade vs Katie Forbes CSP Women Title match 11-07-15

Watch Amaiya Jade vs Katie Forbes CSP Women Title match 11-07-15 video on DTube