User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:18.104.22.168) Gecko/2009033100 Ubuntu/9.04 (jaunty) Firefox/3.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:22.214.171.124) Gecko/2009033100 Ubuntu/9.04 (jaunty) Firefox/3.0.8
A Doctype doesn't affect this behavior. Tested were FF3.1b3, FF 3.0.9 and FF 126.96.36.199.
The attachment contains an example file.
Short example vector: <img src="foo.jpg onerror=alert(1)//
Created attachment 374186 [details]
Shows the unwanted behavior via an image tag with quoted source and error handler
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.
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.
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:
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.
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?
Fixed by the HTML5 parser.
I think we should keep this secret until 3.6 EOL.