EXERCISE 1 — A breakout payload for each injection point
=========================================================
(a)
HERE
(HTML body context)
PAYLOAD:
(or, more reliably:
)
BREAKOUT: introduce a new TAG. The < character starts a new element the
browser parses and runs. Relies on the dangerous character: < (and >).
FIX: HTML-entity encode < > & -> < > &
(b) (quoted HTML attribute context)
PAYLOAD: ">
(or stay in the tag: " onmouseover="alert(1) )
BREAKOUT: close the quoted value with a " then either close the tag and
add a new element, or add an event-handler attribute. Relies on: the
QUOTE character " (to escape the attribute), plus < > if opening a tag.
FIX: keep the value quoted AND attribute-encode the data, encoding " (and
') to " / ' so it can't break out.
(c) (UNQUOTED attribute context)
PAYLOAD: x onmouseover=alert(1)
(a leading space ends the value: value=x then onmouseover=alert(1))
BREAKOUT: no quote needed -- a SPACE (or tab/newline) terminates the
unquoted value, letting you add an event-handler attribute. Relies on:
WHITESPACE (and =). Far more dangerous because the breakout set is huge.
FIX: ALWAYS QUOTE attribute values, then attribute-encode as in (b).
(d) (URL attribute context)
PAYLOAD: javascript:alert(document.cookie)
BREAKOUT: no HTML special characters at all -- supply a dangerous URL
SCHEME. When the link is followed, javascript: executes. Relies on: the
"javascript:" (or data:, vbscript:) SCHEME, not on quotes.
FIX: validate the scheme against an allowlist (http/https/mailto only),
reject javascript:/data:/vbscript:, then URL-encode. Attribute-encoding
alone does NOT stop this, since javascript: has no special HTML chars.
KEY POINT:
Each context has a DIFFERENT breakout: a tag (a), a quote (b), whitespace
(c), a scheme (d). One "escape everything the same way" approach cannot
cover all four -- you must encode/validate for the specific context.