Why is this a security issue? You need to already be running script on the site to dynamically insert a <script> element, and if the site is blindly inserting HTML into itself without sanitizing it then that's the site's problem, as things currently stand. You can create a <script> object using createElement and dynamically set it's src, that's just expected behavior. This is just another way of achieving the same goal. I say this is INVALID.
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
Anyway this inconsistent behaviour.
For background, see: * Bug 214874 * Bug 147581 * Bug 127016 * http://www.whatwg.org/specs/web-apps/current-work/#innerhtml0, which says "Note: script elements inserted using innerHTML do not execute when they are inserted." * http://www.whatwg.org/specs/web-apps/current-work/#script0, which talks about an "already executed" flag. I don't know whether HTML5 specifies this either way. I'll ask Hixie.
Severity: critical → normal
Not a security hole. If a site is sticking untrusted markup into a document using innerHTML, it's screwed even if Firefox's <script> behavior changes. For example, an attacker could use <img onload> instead. Use "document.createTextNode(s)" or ".textContent=s" if you're just trying to insert text.
<Hixie> the spec does cover it <Hixie> jruderman: search for "If the parser was originally created for the HTML fragment parsing algorithm, then mark the script element as "already executed"" http://www.whatwg.org/specs/web-apps/current-work/#scriptTag So this is a bug in Gecko, assuming our goal is to comply with HTML5.
Or a bug in HTML5. In any case, what we do right now is disable script execution during innerHTML setting. But scripts not in the DOM never try to execute, so never discover this and never flag themselves as "tried to execute". We could change that if that's really what we want, but is it really what we want? In any case, is this really related to bug 301375? If our goal is to comply with HTML5, by the way, at some point we will need to go though the (CR) spec with a fine-toothed comb and file bugs on all the places where we deviate from it. Do we have a tracker?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: <script> created by innerHTML setter on element not in the document, followed by adding the element to the document, executes the script → <script> created by innerHTML setter on element not in the document, followed by adding the element to the document, executes the script, unlike html5 spec
HTML5 can change to whatever you need to achieve compat with the Web. Just let me know.
Does anything on the web depend on the Opera/IE behavior? Or just on the behavior of not running script during the innerHTML set?
Maybe a better question to ask is what is the rational behind the HTML5 WG's "no excuting script tags in innerHTML tree inserts"?
sample code is (no longer) interpreted in Mozilla/5.0 (X11; Linux x86_64; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre
Is this (the fact that Gecko ignores "innerHTML tree inserts") the reason why the script on http://www.oele.net/innerhtmljs.html won't execute in FF4? It works on Opera 11, Chrome 8 & FF 3.6. This is the reason why the "now playing" list on http://www.radioparadise.com/ won't load. Just wanted to make sure that this is indeed considered the "desired behaviour". It does seem to break at least one website that works in other browsers.
Hmm. That looks like a regression from the HTML5 parser (effectively due to it fixing this bug). Could you please file a separate bug on that?
This bug has been fixed. Comment 14 asks for part of the fix to be reversed. http://www.oele.net/innerhtmljs.html doesn't run the alert in IE9, either, so I think Firefox 4 and HTML5 are doing OK as far as interop goes.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]
Filed bug 632869.
You need to log in before you can comment on or make changes to this bug.