Last Comment Bug 489704 - Parser bug enables breaking quoted attributes without quotes (XSS)
: Parser bug enables breaking quoted attributes without quotes (XSS)
Status: RESOLVED FIXED
[sg:low] XSS filter evasion? [fixed b...
: html4, xhtml
Product: Core
Classification: Components
Component: HTML: Parser (show other bugs)
: 1.9.0 Branch
: All All
: -- critical (vote)
: ---
Assigned To: Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
:
Mentors:
Depends on:
Blocks: xss
  Show dependency treegraph
 
Reported: 2009-04-22 17:48 PDT by Mario Heiderich
Modified: 2012-05-24 15:09 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
-
wontfix


Attachments
Shows the unwanted behavior via an image tag with quoted source and error handler (252 bytes, text/html)
2009-04-22 17:53 PDT, Mario Heiderich
no flags Details

Description Mario Heiderich 2009-04-22 17:48:35 PDT
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 2009-04-22 17:53:07 PDT
Created attachment 374186 [details]
Shows the unwanted behavior via an image tag with quoted source and error handler
Comment 2 Jeff Walden [:Waldo] (remove +bmo to email) 2009-04-22 18:02:28 PDT
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] (remove +bmo to email) 2009-04-22 18:03:19 PDT
(for general use, that is, not merely for trunk use, would need different fixes for each place)
Comment 4 Mario Heiderich 2009-04-23 03:51:50 PDT
<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] 2009-04-23 14:58:11 PDT
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 2009-04-23 15:46:19 PDT
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) (Not reading bugmail or doing reviews until 2016-09-26) 2009-04-24 03:04:50 PDT
(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 2012-03-06 12:25:56 PST
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) (Not reading bugmail or doing reviews until 2016-09-26) 2012-03-06 22:18:42 PST
Fixed by the HTML5 parser.

I think we should keep this secret until 3.6 EOL.

Note You need to log in before you can comment on or make changes to this bug.