Closed Bug 489704 Opened 15 years ago Closed 12 years ago

Parser bug enables breaking quoted attributes without quotes (XSS)

Categories

(Core :: DOM: HTML Parser, defect)

1.9.0 Branch
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr10 --- unaffected
blocking1.9.2 --- -
status1.9.2 --- wontfix

People

(Reporter: mario, Assigned: hsivonen)

References

Details

(Keywords: html4, xhtml, Whiteboard: [sg:low] XSS filter evasion? [fixed by the html5 parser])

Attachments

(1 file)

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
Blocks: xss
Severity: major → critical
Keywords: html4, xhtml
Component: Security → HTML: Parser
Product: Firefox → Core
QA Contact: firefox → parser
Version: unspecified → 1.9.0 Branch
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.
(for general use, that is, not merely for trunk use, would need different fixes for each place)
<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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:low] XSS filter evasion?
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.
(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.
CC list accessible: false
Not accessible to reporter
CC list accessible: true
Accessible to reporter
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?
Assignee: nobody → hsivonen
Fixed by the HTML5 parser.

I think we should keep this secret until 3.6 EOL.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [sg:low] XSS filter evasion? → [sg:low] XSS filter evasion? [fixed by the html5 parser]
blocking1.9.2: --- → -
Group: core-security
You need to log in before you can comment on or make changes to this bug.