fix: fix XSS bypass via split </script payload across function bodies

[okuryu]

Summary

Fixes a variant of the XSS vulnerability reported in #220 that remained after the earlier fix (738a8e9).

Problem

escapeFunctionBody() only escaped a complete </script...> tag when it appeared within a single serialized value. So the tag could be split across two values to bypass it:

serialize({
  a: function(){ /* </script */ },                          // no closing '>'
  b: function(){ /* > <img src=x onerror=alert(1)> */ }     // supplies '>' and markup
});

Per the WHATWG HTML tokenizer's script data end tag name state, an HTML parser only needs </script followed by TAB/LF/FF/CR/SPACE///> to start parsing an end tag — it doesn't need the > in the same value.

Fix

• SCRIPT_CLOSE_REGEXP now also matches a bare </script prefix followed by one of those delimiter characters, so it's escaped even without a closing > in the same value.
• Escaping is lexically aware: the function source is first scanned for string/template/regex literals and comments. Inside those, characters are unicode-escaped as before. In plain code, <// may be real tokens (comparison, regex delimiter, division), so unicode-escaping them would break syntax — a space is inserted instead, which is a no-op for JS but still breaks up </script.
• Known limitation: a template literal is treated as one opaque span including any ${...} inside it, so a </script-like sequence in a substitution (real code) can still be misclassified. Accepted trade-off to keep the scan simple.
• Span lookup uses a single forward cursor (O(n)) rather than a per-match scan, since matches and spans are both in increasing offset order.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

index.js:64

• The template-literal branch in STRING_OR_COMMENT_REGEXP treats an entire template (backtick-to-backtick) as a single opaque span. As the comment notes, this can misclassify </script sequences that occur inside ${ ... } substitutions (which are code) as “string content”, causing unicode-escaping of <// in plain code and potentially producing a SyntaxError for otherwise-valid functions. If this is an accepted limitation, it may still be worth narrowing the template handling so ${...} regions are scanned as code (e.g., split a template literal into raw-text spans and substitution spans with a small brace-depth scanner) to avoid introducing new serialization breakages.

This issue also appears on line 81 of the same file.

// - A whole template literal (backtick to backtick) is treated as one
//   opaque span, including any `${...}` substitutions inside it. Known
//   limitation: if a `</script` sequence appears *inside* such a
//   substitution (which is actual code, e.g. `` `${ x</script/.test(x) }` ``),
//   it will be misidentified as string/template content and

index.js:81

• STRING_OR_COMMENT_REGEXP's line-comment branch (\/\/[^ ]*) doesn't stop at all JavaScript line terminators. In JS, // comments terminate at \r, \n, \u2028, or \u2029; if a function source contains // ... \u2028 (or \u2029), this pattern will incorrectly treat the following code as part of the comment span, which can misclassify later </script matches and lead to incorrect escaping (including potential SyntaxErrors). Consider updating the branch to something like \/\/[^ \n\u2028\u2029]*.

var STRING_OR_COMMENT_REGEXP = /\/\*[\s\S]*?\*\/|\/\/[^\n]*|'(?:\\.|[^'\\])*'|"(?:\\.|[^"\\])*"|`(?:\\.|[^`\\])*`|\/(?:\\.|\[(?:\\.|[^\]\\\n])*\]|[^\/\\\n])+\//g;