489704 - Parser bug enables breaking quoted attributes without quotes (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.0.8) Gecko/2009033100 Ubuntu/9.04 (jaunty) Firefox/3.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.8) Gecko/2009033100 Ubuntu/9.04 (jaunty) Firefox/3.0.8

JavaScript can be executed from within attributes without using quotes to break them by just using spaces to separate the injected attribute from the value of the former attribute. Also working are horizontal and vertical tabs.

A Doctype doesn't affect this behavior. Tested were FF3.1b3, FF 3.0.9 and FF 2.0.0.20. 

The attachment contains an example file. 

Short example vector: <img src="foo.jpg onerror=alert(1)//

Reproducible: Always

Comment 1

[Mario Heiderich]

Attachment: Shows the unwanted behavior via an image tag with quoted source and error handler

Comment 2

[Jeff Walden [:Waldo]]

I'm guessing the HTML5 parser would fix this, since if I skimmed to the right place in the spec data inside a double-quoted attribute value is snarfed until EOF or the closing quote.

http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#attribute-value-%28double-quoted%29-state

If it's decided this isn't something that the HTML sanitizer that allows this input should fix, that of course wouldn't be an acceptable fix.

Comment 3

[Jeff Walden [:Waldo]]

(for general use, that is, not merely for trunk use, would need different fixes for each place)

Comment 4

[Mario Heiderich]

<embed src="foo onerror=alert(1)//

<a href="foo onclick=alert(1)//

<iframe src="foo onload=alert(1)//

Those are also tested and work. I had difficulties to get this technique working with forms - but will try later when having returned from work. Most pages have no protection against vectors utilizing whitespace like this - the ones I tested didn't.

Comment 5

[Daniel Veditz [:dveditz]]

If there's a matching quote in the page anywhere past the injection point this attack will fail, but it's conceivable a simple page with an injection near the end might fit the bill. Or if the quote is part of the injection then the attacker could use a single-quote on a double-quote heavy page (though watch out for text with apostrophes).

The page under attack already has an XSS hole in it (not our bug), but this quirk in our parsing could be used to evade XSS filters.

Comment 6

[Mario Heiderich]

Yep - but still a lot of (web)servers stop serving markup when fed with control characters like null-bytes. In that case a simple vector could look like:

<code> onerror=location=name%00</code>


Nevertheless this is a combination of problems. Trouble can also be caused with filenames of uploaded images - in case the file name is not being changed and reflected in the markup. Files with control characters also work here.

Comment 7

[Henri Sivonen (:hsivonen)]

(In reply to comment #2)
> I'm guessing the HTML5 parser would fix this, since if I skimmed to the right
> place in the spec data inside a double-quoted attribute value is snarfed until
> EOF or the closing quote.

With the HTML5 parser, there's an src attribute whose value contains everything up to EOF (including </html>).

Note that HTML5 doesn't mark event handlers unexecutable if EOF happens within a real event handler attribute.

Comment 8

[Josh Aas]

Henri, can you look into this and decide if we still need to do anything? Can we open this bug up and/or resolve it?

Comment 9

[Henri Sivonen (:hsivonen)]

Fixed by the HTML5 parser.

I think we should keep this secret until 3.6 EOL.