Cross-Site Scripting (XSS)
XSS tests whether attacker-controlled input reaches an HTML or JavaScript execution sink without context-correct encoding. The exam expects you to identify reflected, stored, and DOM-based variants and to choose a payload that fits the exact injection context.
Core rules and concepts
- Reflected XSS returns in the immediate response; stored XSS persists server-side; DOM XSS flows from a source (
location.hash,location.search,document.referrer,postMessage) to a sink (innerHTML,document.write,eval,setTimeout(string),locationassignment). - Context dictates syntax: HTML text needs a tag such as
<img src=x onerror=alert(1)>; attribute context needs quote breakout plus an event handler; JavaScript string context needs';alert(1)//; URL context may acceptjavascript:. - Defences are per-context output encoding, CSP, Trusted Types, and HttpOnly cookies. HttpOnly only blocks cookie theft; it does not stop script execution.
- Modern frameworks auto-escape text but expose explicit raw-HTML sinks that reintroduce the issue.
Worked example
A search term reflects inside <input value="TERM">. Submitting "><script>alert(1)</script> returns with angle brackets encoded, so the tag fails. Instead submit " autofocus onfocus="alert(1) - the double quote closes the value attribute, autofocus focuses the element automatically, and onfocus executes. Reasoning: this is attribute context, so no angle brackets are required; the payload stays inside the existing tag and uses an event handler. If CSP blocks inline handlers, look for a JSON endpoint reflected into a script block or a DOM sink that processes the hash.
Traps that cost marks
- Testing only
<script>alert(1)</script>and concluding the parameter is safe. - Assuming HttpOnly prevents XSS.
- Missing DOM XSS because the payload never appears in the server response.
- Not retesting with case variation, HTML entities, double encoding, or alternate handlers after a filter blocks you.
- Confusing a blocked
alert()with a non-exploitable bug under CSP.