W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2015

[whatwg] Script parsing mode within SVG sections in HTML documents

From: Niels Keurentjes <niels.keurentjes@omines.com>
Date: Sun, 21 Jun 2015 07:13:26 +0000
To: "whatwg@whatwg.org" <whatwg@whatwg.org>
Message-ID: <5bd2198af5094abda512e2f98bf1cfd9@omines-srv-002.omines.corp>
I ran into a discussion on Stack Overflow in this topic: http://stackoverflow.com/q/30952737/1729885, regarding embedding the following code snippet in an HTML document:


The character references translate to "alert(1)". I have confirmed that, in all the latest versions of IE, Chrome and Firefox, this code is executed, whilst it is not if the <svg> container is omitted. I neither think this is intentional nor wanted behavior, as HTML5 explicitly defines a separate script parsing mode which handles character references as plain text.
HTML5 however also explicitly defines that "the semantics of SVG elements are defined by the SVG specification", and SVG also defines the script element, without the script parsing mode (as it is XML itself it would be impossible nor necessary to enforce that). Therefore it seems that all browsers are correct in executing this code in this context, according to current standards. It does leave a potentially giant loophole though to embed malevolent code in HTML documents which is not scanned or detected by na´ve scanners assuming script tags cannot work like this in HTML.

I think the HTML specification on the SVG element (http://www.w3.org/TR/html5/embedded-content-0.html#svg), or the more general section on embedded content at http://www.w3.org/TR/html5/dom.html#embedded-content-2, should be expanded to state that either, if an SVG document is embedded in HTML, it inherits its limitations with regards to the parsing mode of elements defined in both standards, or more generically something to the effect of that active content in any section of the document must adhere to limitations imposed by all of its containing documents.
Received on Sunday, 21 June 2015 07:15:36 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:33 UTC