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.