EXERCISE 2 — Bypassing a naive blocklist filter
================================================

THE FILTER:
  - Removes the literal string "<script>" (CASE-SENSITIVE, SINGLE PASS).
  - Removes the literal string "javascript:".

BYPASS 1 -- defeat the "<script>" removal:

  Technique A: CASE VARIATION.
    Payload:  <ScRiPt>alert(1)</ScRiPt>
    The filter matches only the exact lowercase "<script>", but HTML tag names
    are CASE-INSENSITIVE, so the browser still runs <ScRiPt>. Filter misses it.

  Technique B: BROKEN-UP KEYWORD (defeats single-pass strip).
    Payload:  <scr<script>ipt>alert(1)</scr</script>ipt>
    The filter finds the inner "<script>" and removes it ONCE. After removal,
    the surrounding fragments JOIN into a fresh "<script>...". Because the
    filter runs only a SINGLE PASS, it doesn't re-scan the result, so a valid
    <script> reassembles and executes.

  Technique C (simplest): NO-SCRIPT VECTOR.
    Payload:  <img src=x onerror=alert(1)>
    Contains no "<script>" at all, so the filter is irrelevant.

BYPASS 2 -- defeat the "javascript:" removal:

  Technique A: CASE VARIATION.
    Payload (in href):  JaVaScRiPt:alert(1)
    Schemes are case-insensitive; the exact-lowercase filter misses it.

  Technique B: HTML ENTITIES / control chars.
    Payload:  &#106;avascript:alert(1)   (&#106; = 'j')
       or:    java&Tab;script:alert(1)  / embedded newline or \t inside
    The browser DECODES the entity / tolerates the whitespace and still sees
    "javascript:", but the literal-string filter (matching the exact bytes
    "javascript:") does not. Filter misses it.

WHY THIS PROVES BLOCKLIST FILTERING IS THE WRONG MODEL:
  - A blocklist must enumerate EVERY dangerous pattern. But the browser's
    parser is extremely tolerant: case-insensitive tags/schemes, HTML-entity
    decoding, whitespace/control-character tolerance, hundreds of elements and
    event handlers, and multiple layered encodings. That yields effectively
    INFINITE equivalent variants of any "bad" string.
  - For the filter to win it must block all of them, forever, including ones
    not yet discovered; for the attacker to win they need ONE variant the
    filter missed. The economics are hopeless -- and history (including
    browsers' own now-removed XSS Auditor/filter) confirms every blocklist
    gets bypassed.
  - The correct model is POSITIVE/allowlist: don't try to recognise bad input
    -- ensure untrusted data is only ever emitted as DATA (context-aware
    output encoding, Chapter 6), or, when HTML is required, pass it through an
    allowlist sanitizer that keeps only known-safe elements/attributes
    (Chapter 7). Then no variant matters, because nothing is interpreted as
    code.