564706 - E4X and HTML parser conspire to make <script<b></b> an XSS

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Mario Heiderich]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3

The test string below should demonstrate the problem:

Sample: <b><script<b></b>,alert(1)</script </b>

Result: Execution of JS code alert(1)


 * <b> tag
 * <script tag
  * <b></b> an E4X object
  * , delimiter followed by alert(1)
 * </script </b> closing tags for <script> and <b>

Note that the parser a) considers the <script tag as legitimately closed and b) the E4X object is created in the JS scope as well. 

Reproducible: Always

Comment 1

[Boris Zbarsky [:bzbarsky]]

> the parser a) considers the <script tag as legitimately closed

There's an existing bug on this; it's fixed in the HTML5 parser.

> b) the E4X object is created in the JS scope as well. 

That seems to be correct behavior given the DOM the HTML5 parser produces, though it boggles me that e4x defaults to on for web script....

Comment 2

[Jesse Ruderman]

With the HTML5 parser, you get a tag whose name is "SCRIPT<B".  I'm having trouble finding another bug on this exact topic (bug 560927 and bug 226495 aren't it).

E4X just turns scripts that are syntax errors into scripts that are not syntax errors, so except for XSS it isn't a problem for it to be enabled for scripts that don't use it.

I suppose we could reject scripts that start with an E4X literal, by expanding the fix for bug 375250, making it cover XSS in addition to the attack covered by that bug.

What server-side logic would lead to "<b><script<b></b>,alert(1)</script </b>" being allowed or output while other XSS vectors are rejected?